Admin-Wochenende… Diesmal: Mailserver-Umzug

Eigentlich ist’s ja gar nicht sooo kompliziert, aber trotzdem ist es meistens eine Sache, um die ich mich gerne ein wenig drücke. Theoretisch ist alles nach 1-2h geschehen, aber dann kommen da immer noch die Details und Feinheiten, denn die Basiskonfiguration ist doch immer eine leicht andere.

Auf Facebook kam auf meinen „Richte Mailserver ein“-Post einstimmig als Feedback zurück, dass die Freizeit dafür zu schade sei, und man lieber auf fertige Mailserver/-Dienste zurückgreifen solle. Dennoch mache ich es auch diesmal wieder selbst 🙂 Zum einen für den Lerneffekt und zum anderen vertraue ich einem selbst eingerichteten Server sogar mittlerweile tatsächlich mehr als einem gekauften Service.

In diesem Artikel möchte ich über die Highlights und Downs des Umzugs reden. Woran ich diesmal so hing, und wie ich es dann letztendlich gelöst habe. Vielleicht hilft mir das beim nächsten Mal (wenn ich schon wieder alles vergessen habe), und vielleicht stolpert ja auch zufällig mal ein anderer Hobby-Admin darüber, der mit den Infos etwas anfangen kann.

Serviceunterbrechung?

Wie kann ich eine Service-Unterbrechung beim Umzug verhindern? Bei den normalen DNS-Einstellungen kann es bis zu 48h (Die Erfahrung hat gezeigt, dass es meist nur bei 12-24h liegt) dauern, bis alle Clients den IP-Wechsel der zugehörigen Domain registriert haben. Das heißt man muss grundsätzlich damit rechnen, dass in diesem Zeitraum Mails an den alten und an den neuen Server gehen, und dass sich die Kunden auf beiden Servern einloggen.

Zwar hätte ich die Möglichkeit meine TTL runtersetzen zu lassen, damit der Wechsel auf die neue IP möglichst schnell klappt, aber das ist immer ein ziemlicher Zusatzaufwand, da ich hierfür keine eigene Option bei meinem Domainanbieter habe. Da müsste ich dann anrufen/mail schreiben usw… Und eigentlich ist es gar nicht notwendig. So wirklich „echte“ Kunden habe ich auf dem Server nicht, von daher ist eine „am Samstag kann es zu kurzen Problemen kommen, es gehen keine Mails verloren, am Sonntag ist wieder alles lauffähig“-Mail völlig ausreichend.

Man lässt einfach beide Mailserver weiter laufen, migriert die ganzen Mails von dem alten auf den neuen Server (hier reicht es, die jeweiligen virtuellen Maildir-Verzeichnisse zu kopieren) und synchronisiert diese einfach nach Ablauf der Zeitspanne noch einmal. Fertig. Hierbei gab es bislang noch nie Probleme, der User kann trotzdem jeder zeit Emails schicken und empfangen, empfängt aber einige Mails dann unter Umständen etwas später (nach dem Synch).

Postfix

Das Herzstück meines Mailservers… Die Basiskonfiguration geht mittlerweile eigentlich recht flüssig von der Hand, und es gibt viele hilfreiche Tutorials. Diesmal habe ich mich an Folgendem orientiert: HowTo

Leider ist der Artikel noch nicht ganz vollständig, aber das was vorhanden ist funktioniert in großen Teilen auch so. Der Vorteil diesmal: Anstelle einer von Hand aufgesetzten MySQL-Konfiguration wird hier gleich eine zu „postfixadmin“ kompatible verwendet. Bei meinen bisherigen Servern habe ich die Mailadressen immer per Hand über den Mysql-Client eingetragen (so viel ändert sich da bei mir auf dem Server auch nicht, von daher nicht weiter schlimm). Postfixadmin bietet jedoch hierfür ein komplettes Webinterface, was die Sache dann doch um einiges bequemer macht. Eines meiner Highlights bei diesem Umzug.

MailQuota

Postfix unterstützt leider von Haus aus keine Quotas für die Mailboxen oder -Verzeichnisse. Da ich virtuelle Mailboxen verwende (die alle dem selben User gehören) helfen auch die Unix-Haustools für Quotas nicht.

Eine Alternative ist hier der VDA-Patch für Postfix. Leider ist hier aktuell nur eine Version für Postfix 2.9.5 zu bekommen, die aktuellen Ubuntu-Packages für Postfix sind aber schon bei 2.9.6. Nach kurzem Überlegen habe ich beschlossen für den Umzug doch erstmal bei der binary Variante von Postfix zu bleiben, anstatt mir die ältere Version zu ziehen und zu patchen. Insbesondere da in den letzten 5 Jahren bislang noch niemand ansatzweise die Quota überschritten hat (außer mir :)). Ich werde das aber in den nächsten Wochen noch nachziehen… Lieber auf Nummer sicher gehen, bevor eine Mailbox den ganzen Server blockiert :). Die Datenbankeinträge und Queries berücksichtigen die Quotas auf jeden Fall schon und die Parameter sind auch bereits gesetzt.

Smtpd Auth

Das Sorgenkind des Tages :(. Daran habe ich noch nie dermaßen viel Zeit verloren, aber irgendwie wollte es diesmal ums verrecken nicht. Via Auxprops/SQL wollte es einfach nicht funktionieren. Schließlich dann zu saslauthd gewechselt und mich mit pam/mysql abgemüht. Erst Probleme mit den crypt-Einstellungen gehabt (bei der jetzigen Datenbankkonfiguration sind die Passwortfelder mit crypt gehasht), dann nach einer gefühlten Ewigkeit endlich grünes Licht bei testsaslauthd. Smtpd-Auth aber immernoch am Fehlschlagen *seufz*.

Irgendwann dann zu „rimap“ gewechselt. Rimap ist ein Authentifizierungsmechanismus für Sasl, bei dem ein angegebener Imap-Server zur Überprüfung der Credentials genutzt wird. Kannte ich bis dato auch noch nicht. Eigentlich eine feine Sache. Mein Auth ging leider trotzdem nicht :(. Testsaslauthd nach wie vor grün, auth am smtpd: Fehlanzeige.

Sehr verwirrt haben mich auch immer wieder folgende Fehlermeldungen:

Da ich in meiner smtpd.conf eigentlich nur folgendes hatte…

…war das für mich sehr unverständlich. Der Saslauthd selbst hatte als MECHANISM ja „rimap“ eingetragen. In irgendeinem Forum bin ich dann schließlich fündig geworden, dass dieses Problem daher kommt, dass ich aus meinen vorherigen Versuchen die libsasl2-modules-sql noch installiert hatte. Ein einfaches apt-get remove hat mich dann von den lästigen Fehlermeldungen befreit (die auch keinerlei Einfluss darauf hatten, ob es nun funktioniert hat oder nicht – aber man ist ja immer misstrauisch, wenn man Fehlermeldungen sieht).

Mit der Zeit näherte ich mich dem Ziel… Es gab nicht mehr viel, was ich noch nicht probiert hatte. Ich war mir sicher, dass die Configs stimmten, es funktionierte aber immer noch nicht… Was tut man wenn nicht’s mehr geht? Richtig.

Vermutlich zählen manche Programme heimlich mit, wie oft bereits während der Installation und Konfiguration rebootet wurde und akzeptieren die richtige Config erst so nach 3-4 mal. Natürlich hatte ich die ganzen services restarted. Postfix, Saslauthd, … moment da war doch noch einer? Courier-authdaemon… Mist… Ich kann es jetzt leider nicht mehr nachvollziehen, aber ich glaube der war Schuld :). Jedenfalls ging die smtpd auth nach dem reboot wieder wie gewünscht.

Von seltsamen Runleveln…

Aus meinem vorherigen Problem gelernt habe ich jetzt gleich öfter mal zum Reboot gegriffen, wenn etwas nicht funktioniert hat. Das seltsame war – auf einmal hat wieder nichts mehr funktioniert. Richtig genervt durch diverse Logs gewühlt und schließlich festgestellt:

Huch? Amavis war doch installiert und konfiguriert und… lief nicht:

Großes Fragezeichen. Gut, kann ja mal passieren… also brav zu den Runleveln hinzugefügt, bzw. es versucht:

Hmmm muss eigentlich doch gehen? Nochmal rebooten und testen… Nichts… Schließlich dann amavis nochmal aus den runleveln entfernt (update-rc.d -f amavis remove) und nochmal manuell hinzugefügt:

Reboot und – es funktioniert. Seltsam, damit hatte ich in meiner bisherigen Linux-Erfahrung noch nie probleme gehabt o_O. Das selbe Problem hatte ich später übrigens noch einmal mit dem Apache2, aber da wusste ich ja dann wie’s zu beheben ist.

Nginx

Ja 🙂 Mit dem Serverumzug (den Großteil des Webkrams habe ich schon vor ein paar Wochen umgezogen) bin ich auch auf Nginx gewechselt. Zwar liebte ich meinen Apache bis dato immer heiß und innig, aber ich muss sagen der Nginx… Ist definitiv mein neuer Lieblingskandidat :). Ich werde hierüber dann noch einmal einen eigenen Blogartikel schreiben. Es gab auch (bis auf Mailman und Nagios) keine nennenswerten Probleme mit dem Nginx – aber es hat natürlich trotzdem alles ein wenig länger gedauert (muss halt doch noch ab und an mal nachblättern ob und wie man z.B. nested Locations nutzen kann und darf. Das mit den nested Locations funktioniert übrigens hervorragend :). So kann ich zum Beispiel für meinen mailadmin (postfixadmin) eine andere php5-fpm config nutzen, obwohl es nur in einem Unterverzeichnis liegt:

Mailman

Ohja das war Sorgenkind Nummer zwei :). Ich war der festen Überzeugung, dass ein Eintrag in meinen virtual_alias_maps reichen müsste (welche via SQL gefüttert wurden). Also schnell den mailman transport für die entsprechende Domain mit angelegt und… geht nicht.

Nachdem ich es gar nicht anders hinbekommen habe dann letztendlich in die normalen alias_maps eingetragen und siehe da -> works! Das hätte auch ruhig schneller gehen können. Da werde ich mich aber auch nochmal ransetzen. Bin so nicht ganz zufrieden. Das muss auch über die virtual_alias_maps gehen irgendwie.

Nächstes Problem: Das Webfrontend… „Achja wird ja nich so schlimm sein, schnell mal den Google anwerfen, wie die Nginx-CGI-Direktive lautet“ – Möööp. Nginx kann gar kein CGI *seufz*. Eigentlich mag ich CGI ja auch nicht, aber wenn das Programm es eben fordert… Naja erstmal auf die Suche nach alternativen z.B. in PHP gemacht. Nach einer Viertelstunde ernüchternd festgestellt, dass es da eigentlich gar nichts gibt (oder ich hab nix gefunden -> wer was weiß bitte Bescheid sagen). Ne Alternative in Perl gefunden (Sympa), aber da habe ich ja wieder das CGI Problem. Also lieber nach ner Alternative gesucht, wie ich CGI einbinden kann. Übergangsweise habe ich jetzt erstmal nen Apache für das CGI genommen, der vom Nginx via proxy_pass durchgereicht wird. Da weiß ich wenigstens wie ich den sinnvoll aufsetzen kann. So ganz glücklich bin ich aber nicht damit. Der Apache ist viel zu schwergewichtig für die paar mailman-cgis.

Nagios

Nagios ist das zweite Highlight meines Serverwechsels. Bislang habe ich das Server-Monitoring immer mit viel Hand-gefrickel gelöst, diesmal wollte ich es professioneller aufziehen. Nagios ist ein sehr umfangreiches aber freies Tool für das Server-Monitoring. Bislang bin ich äußerst zufrieden.

Wieder das CGI-Problem. Einfach auf selbe weise gelöst wie beim mailman. Web-Access funktioniert ohne Probleme und ich habe auch noch eine kleine Android-App gefunden, welche mich über meine Server-Services auf dem laufenden hält. Während meinen Recherchen bin ich auch mehrfach über Icinga gestolpert, ein Fork von Nagios, der wohl eine etwas ansprechendere Oberfläche haben soll. Das werde ich am nächsten Admin-Wochenende mal testen.

Fazit

Das war wieder ein äußerst spannendes Wochenende 🙂 Trotz der erneuten Probleme (ich glaube eine „perfekte“ Konfiguration, die auf Anhieb das tut was ich will ist einfach nicht möglich) bin ich äußerst zufrieden mit dem Ergebnis und bin auch weiterhin ein Verfechter eines eigenen Mailservers :).

Welche Mailserver nutzt ihr? Habt ihr auch Probleme bei dem Umzug oder beschränkt sich das auf mich? Was war das blödeste Problem dass ihr je hattet (siehe mein service restart fail) und warum betreibt ihr eure eigenen Mailserver (bzw. warum tut ihr das nicht?).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.