Kategorie: Technik

  • Pesky error message during Plesk Updates “Warning: install PAM module not successed” (PAMConfig.confset.PAMServiceError: system-auth)

    Pesky error message during Plesk Updates “Warning: install PAM module not successed” (PAMConfig.confset.PAMServiceError: system-auth)

    Problem

    For the longest time Plesk updates have been showing the error “Warning: install PAM module not successed” on one of my Plesk installations. While this message is a bit scary to read, the installer always claimed that all changes had been executed successfully. And I never experienced any negative effects, indeed. So I got used to ignoring the error a while ago.

    Today I stepped over it once more and I finally took the time to investigate it further.

    FYI: this is Plesk Obsidian 18.0.61 on Ubuntu 20.04 LTS.

    This is the message appearing in the installation log:
    CRITICAL:3:a programming/runtime error (PAMConfig.confset.PAMServiceError: system-auth)
    Trying to install PAM module… PAM configuration loaded from (directory="/etc/pam.d", file="/etc/pam.conf"). Configuration contains 29 file(s)
    3:a programming/runtime error (PAMConfig.confset.PAMServiceError: system-auth)
    Warning: install PAM module not successed

    Investigation

    Google wasn’t very helpful as I found exactly one result complaining about the same error, but without any solution. The Plesk forum didn’t have anything good to tell either at this point. Even though there is no clear indication which (.deb) package exactly is causing the issue, its pretty obvious that it must be PAM related. `libpam-plesk` seems to be a good candidate. So I grabbed it from `/var/cache/apt` to have a look at its content.

    $# ar -x ../libpam-plesk_18.0-v.ubuntu.20.04+p18.0.61.0+t240426.1307_amd64.deb
    $# tar xJf control.tar.xz
    $# tar xJf data.tar.xz

    This got me a bunch of files and directories to look at.

    Unfortunately the message “install PAM module” can’t be found inside any of them, but there is a “uninstall PAM module” message, so I considered myself being on the right track.
    After some more digging I found that postinst calls /opt/psa/bootstrapper/components/libpam-plesk.sh which contains “install PAM module”. Yay!

    This bootstrapper script finally calls the binary /opt/psa/pam_plesk_config/pam_plesk_install. Uuuh, a binary?

    Remember the plesk forum? This time a search there gave me 2 hints: a) people have been calling pam_plesk_install multiple times without doing any futher harm and b) pam_plesk_install supports -v for more verbosity.

    # /usr/local/psa/pam_plesk_config/pam_plesk_install -v
    DEBUG:Loading PAM configuration from (directory="/etc/pam.d", file="/etc/pam.conf")
    INFO:PAM configuration loaded from (directory="/etc/pam.d", file="/etc/pam.conf"). Configuration contains 29 file(s)
    DEBUG:calculating changes for 'auth' stacks
    DEBUG:S3:Traceback (most recent call last):
    File "pam_plesk_install.py", line 351, in main
    File "pam_plesk_install.py", line 35, in getAuthChanges
    File "PAMConfig/analyzers.py", line 130, in selectServices
    shared = confSet.getCommonServiceNames(self.facility)
    File "PAMConfig/confset.py", line 958, in getCommonServiceNames
    if self.getConf(c, facility):
    File "PAMConfig/confset.py", line 980, in getConf
    raise PAMServiceError(service)
    PAMConfig.confset.PAMServiceError: system-auth
    
    CRITICAL:3:a programming/runtime error (PAMConfig.confset.PAMServiceError: system-auth)

    Not too helpful, but there are references to .py files? Ok… so this “binary” might be just a collection of Python scripts, stitched together with something like pyinstaller.

    Thankfully theres a python script pyinstextractor.py available at https://github.com/extremecoders-re/pyinstxtractor to extract whatever might be hidden in such a binary. Spoiler Alert: THIS is not a pyinstaller binary. Dead end.

    Sooo… back to the binary: the first two bytes of the file header read PK… maybe its a simple ZIP file?

    $# unzip pam_plesk_install
    Archive: pam_plesk_install
    inflating: .bootstrap/init.py
    inflating: .bootstrap/_markerlib/init.py
    [...]

    Indeed! Now we’re talking…

    Crawling the source code was challenging and I will not claim to understand everything or even try to document the steps, but my summary is: pam_plesk_install verifies/analyzes all files in pam.d, regardsless if it needs to touch them or not. So this might be something completely unrelated to plesk.

    BTW:

    # FIXME: the entire aproach is somewhat sick. I just don’t
    # have a better one at the moment…

    PAMConfig/analyzers.py

    Well… yeah, by now I think I know what you mean!

    Conclusion

    And heres the root cause: a completely different service (Acronis Backup Manager) referenced `system-auth` in one of its own `pam.d` files. Appearantly `system-auth` is not available in Ubuntu 20.04 (anymore?) and `pam_plesk_install` can’t get any details about it. That ultimately crashed the script!

    #%PAM-1.0
    auth include system-auth
    auth required pam_listfile.so item=user sense=allow file=/etc/security/acronisagent.conf onerr=fail
    account include system-auth

    acronisagent.system

    Since I didn’t use Acronis for a long time, my fix was easy: just get rid of BackupManager. Or: So I thought… but thats another story which will be told another day.
    Hint: Don’t trust Acronis’ uninstaller to not touch files in /usr/sbin it doesn’t own!

    Anyways, the takeaway is: The error described here is gone for good after removing any invalid/outdated entries from pam.d files.

    Plese let me know if you found this to be helpful!

    I posted a copy of this to the plesk forums here: https://talk.plesk.com/threads/error-message-during-plesk-updates-warning-install-pam-module-not-successed-pamconfig-confset-pamserviceerror-system-auth.374405/

  • Synology DiskStation auf Steroiden

    Synology DiskStation auf Steroiden

    Die Tage klagte ein Kollege das Backups zu seinem Synology NAS DS216+II schleppend langsam liefen und auch gern abbrachen. Auch die nächtliche Synchronisation der Daten mit einem anderen Synology Gerät (an einem anderen Standort) funktionierte seit einer ganzen Weile nicht mehr zuverlässig.

    Die Situation stellte sich beim Versuch eines lokalen Backups zum NAS (unter Verwendung von Synology Active Backup for Business) folgendermassen dar: Anfangs zeigten sich zwar keine herausragenden aber noch akzeptable Datenübertragungsraten von 7 MB/s. Doch über die Zeit sank diese Übertragungsrate auf unterirdische Werte weniger KB/s.

    Während die Verwaltungsoberfläche abgesehen von einer hohen Auslastung keine hilfreichen Hinweise auf die Ursache des Problems gab, konnte ein schneller Blick in die Konsole und das Tool htop einen ersten Verdacht aufzeigen.

    Während die arme kleine Intel Celeron N3060 (Dual Core) CPU des Geräts unter der Last des Backups ohnehin vollkommen ausgelastet war, wurde auch das mit 1 GB sehr knapp bemessene RAM ordentlich belastet. Der mit knapp 3 GB grosszügig bewessene Swap Space erlaubt im Normalfall dennoch einen recht performanten Betrieb, zB einiger kleiner Container wie Nextcloud, wird aber in dieser Situation zum echten Problem.

    Offenbar genehmigt sich der Backup Task relativ viel RAM, mutmasslich zum Caching – etwa um bei kleinen Aufgaben die Ausführung performanter erscheinen zu lassen als es der IO Bus bzw. die HDDs eigentlich zulassen.

    Das führt aber bei grossen Datenmengen und voll augelasteten IO zu einem Stau, denn es kommen ja immer neue Daten nach. Das System kommt nie dazu den Cache zu leeren, füllt ihn sogar immer weiter auf. Aus lauter Verzweiflung beginnt das System dann damit den RAM Inhalt in den grosszügigen Swap Space auszulagern (daran zu sehen das dieser sich kaum merklich aber stetig füllte). Was widerum, man ahnt es schon, den IO noch weiter belastet – ein Teufelskreis.

    Glücklicherweise lässt sich das RAM der DiskStation mit relativ wenig Aufwand aufrüsten, zudem hatte ich hier noch einen 4GB SO-DIMM Riegel aus einem alten McBook Pro herumliegen. 1,60 € Porto und 24h später war dieser dann auch bereits am Ort des Geschehens. Der Umbau ist in hunderten von YouTube Videos hinreichend beschrieben, exemplarisch verlinke ich hier mal eines davon.

    Die Ergebnisse sprechen für sich selbst! Ein Backup das vorher den halben Tag dauerte – wenn es überhaupt abgeschlossen wurde – ist nun innerhalb einer Stunde erledigt.

    „DS216+II on steroids!“

  • E-Mail Zustellung an T-Online…

    E-Mail Zustellung an T-Online…

    …oder: wie alles nichts nützt wenn eine IP bereits „eine schlechte Reputation“ hat.

    Ich gebe zu es sind (im Verhältnis) nicht viele Mails die so täglich über meine Server laufen, vor allem nicht viele die kein Spam sind. Letztere sind vorzugsweise eingehende EMails, obwohl es Situationen gab in denen auch ich unbeabsichtig zum Mittäter wurde.

    Doch zunächst: Warum das ganze? Und warum jetzt?

    Gestern bemerkte ich das leise weinen eines meiner Server, die Mailserver von t-online.de würden nicht mit ihm reden wollen.

    May 14 05:45:12 ********** postfix/smtp[******]: ************: host mx02.t-online.de[194.25.134.9] refused to talk to me: 554 IP=xxx.xxx.xxx.xxx - Dialup/transient IP not allowed. Use a mailgateway or contact ****@**.t-online.de if obsolete. (DIAL)

    Ehrlich gesagt hatte ich diese Meldung schon in der Vergangenheit ab und zu gesehen aber nicht wirklich wahrgenommen. Wer muss schon dringend jemanden bei T-Online erreichen?

    Aus Fehlern soll man bekanntlich lernen und vor allem sollte man sie bei sich niemals von vorne herein ausschliessen. Auch wenn die Meldung oben darauf hindeutet das meine IP fälschlicherweise als DialUp/dynamisch vergebene IP eingestuft wird, wollte ich zunächst sicher gehen das bei mir alles korrekt ist.

    Daraus ergab sich eine durchaus positive Lernkurve, und ich habe mir vorgenommen hierzu einen möglichst umfassenden Guide für Leidensgenossen zu erstellen. Jetzt aber soll es genügen zu sagen: es war nicht alles Perfekt, aber ich habe auch bis jetzt schon alle Bedingungen erfüllt die https://postmaster.t-online.de/ für eine erfolgreiche Zustellung erfordert. (für einige, nicht alle meiner Domains!)

    Es sei auch erwähnt das ich bei anderen grossen Maildiensten (zB Google, web.de, GMX, UnitedDomains/UDAG) zur gleichen Zeit keinerlei Probleme hatte.

    Dennoch habe ich die letzten 24h in grossen Teilen damit zugebracht auch alles andere „gerade zu ziehen“, und hin und wieder mit den überraschend gut verfügbaren und kommunikativen Admins von T-Online zu kommunizieren. Vornehmlich kamen von dort aber eher irreführende Hinweise, denn mein Kontakt hatte offenbar den eigentlichen Grund für sich von vorne herein ausgeschlossen: Das nützt alles nichts wenn die IP bereits „eine schlechte Reputation“ bei T-Online hat.

    Nachdem ich nun also sicher war das bei mir alles (wieder*) korrekt sein muss – weil ein anderer Server (für andere Domains) mit einer äquivalenten Konfiguration problemlos von T-Online akzeptiert wurde – war erstmal einige Stunden Funkstille auf der Seite von T-Online.

    Schlussendlich kam dann heute im frühen Nachmittag die durchaus schmallippige und erlösende Antwort:

    Wir werden veranlassen, dass die Reputation dieser IP-Adresse bei unserem System resettet wird.

    Und siehe da: nur wenige Minuten später funktioniert die Zustellung tadellos!

    Ich persönlich vermute ja das der Pool von IP Adressen in dem sich mein Server befindet irgendwann einmal „en gros“ geblockt wurde, da in ihm viele billige und schnell verfügbarte V-Server existieren – die gerne oft von Spammern genutzt werden.

    *) „wieder“ weil ich – im Zuge der Bemühungen den Hinweisen von T-Online nachzukommen – es tatsächlich erstmal verschlimmert habe!