Was ist schlimmer – die Hölle oder Postfix-SASL-MySQL

Antwort: Courier IMAP. Der Mailserver läuft, BTW. wieder.

Das schönste an Unix/Linux sind wohldokumentierte, simple Programmchen wie Courier-IMAP*. Nicht nur, dass deren ausführbare Dateien und Libraries kreuz und quer über das Dateisytem verteilt sind, wodurch das Vorhandensein von mindestens drei konkurrierenden Versionen der selben Dateien gewährleistet wird, auch die Dokumentation ist eine wahre Freude. Wer etwa aus den Fehlermeldungen von courier-authdaemon schlau werden will (das Aas kennt im Normalfall nur eine Fehlermeldung “no such file or directory“ und die ist bestenfalls als “lakonisch” zu bewerten) wird nach der Lektüre der Dokumentation (man authlib – authdaemon selbst ist der Benutzerfreundlichkeit halber vollständig undokumentiert) mühelos herausfinden, dass die richtigen Fehlermeldungen angezeigt werden, wenn man die Zeile DEBUG_LOGIN=1 an die Datei /etc/courier/authdaemonrc anfügt. Ehrensache, dass davon nichts in /etc/courier/authdaemonrc steht, obwohl alle anderen Optionen dort dokumentiert sind. Mit den nun im Syslog erscheinenden Fehlermeldungen kommt man eventuell dem Fehler auf die Schliche. Zum Beispiel demjenigen, dass der authdaemon gar nicht läuft. no such file or directory – logisch, oder? sysadmin.go(‘BERSERCK’)…
Sollte das Problem mit Courier IMAP am Ende nach einem Reboot (und z.B. nach einer Uptime von einem dreiviertel Jahr) aufgetreten sein, wird jetzt, allen Verschleierungsversuchen der dreimal verteufelten Courier IMAP Suite zum Trotz, allmählich ein Schuh draus. Irgendwie wurde das Start-Script unter /etc/init.d/courier-authdaemon durch eine fehlerhafte Version ersetzt, die den Authdaemon unter /usr/lib/courier-imap/courier-auth/ anstatt unter /usr/lib/courier/courier-auth/authdaemon (besser noch mal nachsehen, wer weiss, wo es sich heute wieder versteckt) sucht. Haha, so einfach und man kommt doch nicht drauf… Insbesondere kommt man schon deshalb nicht drauf, weil eine vorher versuchte Neuinstallation von courier-authdaemon ebenfalls über das verbockte Startscript stolpert und dementsprechend scheitert. Erst wenn man in diesem Fall in der Datei /etc/init.d/courier-authdaemon ein beherztes exit 0 einsetzt (direkt in die Zeile nach ‘#!/bin/bash’, bevor das Skript Gelegenheit hat, Unheil zu stiften) und bei der nun möglich gewordenen Neuinstallation das vorhandene Startskript durch das im Installationspaket enthaltene ersetzen lässt, läuft der Re-Install problemlos durch.
Das mal nur so als bescheidene Antwort auf die oft gehörte Frage “was ist denn das Problem auf dem Mailserver und wann geht er wieder?”. Dass bei der gesamten Prozedur eingehende Mails ganz normal in den Postfächern gelandet und zuvor abgeschickte ganz normal versendet wurden, ist erstens Ehrensache, zweitens eine ganz andere Baustelle. Für das Senden und Empfangen von Mails ist nämlich ein richtig komplizierter -dafür aber halbwegs dokumentierter- Brocken Software zuständig…

*Softwarepaket, das für die Verwaltung von und den Zugang zu Postfächern, sowie die allgemeine Steigerung der Lebensfreude von Admins verantwortlich ist.