Wichtigste Erkenntnisse
- Automatische Updates sind wichtig, Neustarts benötigen Nachprüfungen.
- Überwacht nicht nur, ob der Dienst läuft, sondern ob er funktioniert.
- Gewohnheit macht Warnsysteme blind — bleibt wachsam.
Was passiert war
Um kurz nach sechs Uhr morgens hatte das System automatische Sicherheitsupdates eingespielt. Darunter ein neuer Kernel, und ein neuer Kernel heißt Neustart.
Der Neustart lief sauber. Der Server kam hoch, die Container starteten, alles meldete sich betriebsbereit. Nur Mail funktionierte nicht.
Die Ursache war eine einzelne fehlende Zeile in der Netzwerkkonfiguration: die Regel, die den Containern den Weg nach draußen freigibt. Diese Regel wird beim Aufbau des Container-Netzes normalerweise mitgesetzt. Nach diesem Neustart war sie nicht da.
Die Folge ist tückisch, weil sie halb funktioniert:
- Eingehende Mails kamen an — von außen ist der Weg ein anderer
- Ausgehende gingen nicht raus, weil der Server keine fremden Mailserver erreichte
- Die Weboberfläche antwortete, alle Container zeigten „gesund”
- Kein Absturz, kein Fehler, keine Meldung
Ein Dienst, der zur Hälfte funktioniert, ist schwerer zu bemerken als einer, der aus ist. Bei „aus” ruft irgendwann jemand an. Bei „halb” wundert man sich zwei Tage lang über Kleinigkeiten.
Warum meine Überwachung nichts gesagt hat
Ich habe Überwachung. Sie prüft, ob Container laufen und ob sie sich gesund melden.
Beides war erfüllt. Die Container liefen. Sie meldeten sich gesund. Sie kamen nur nicht ins Internet.
Das ist der Kern des Problems, und er hat mich mehr beschäftigt als der eigentliche Fehler: Ich hatte Verfügbarkeit überwacht, nicht Funktion. Ein Behälter, der läuft, sagt nichts darüber aus, ob das Programm darin seine Aufgabe erfüllt.
Und dass die Meldung ausgerechnet aus Apple Mail kam — aus einem Programm, das mit meiner Infrastruktur nichts zu tun hat und mich nur nebenbei informierte — ist der unangenehmste Teil der Geschichte. Wer mehr über meine Erfahrungen mit Mailservern lesen will, findet einen ausführlichen Bericht in Mein Eigener Mail-Server.
Der schnelle Weg zurück
Die Regel manuell nachgesetzt, Mail lief wieder. Das dauerte, nachdem ich die Ursache hatte, keine zwei Minuten.
Der ganze Aufwand steckte davor: verstehen, dass eingehend geht und ausgehend nicht. Von dort auf die Netzwerkebene kommen statt auf die Anwendung. Und dann sehen, dass eine Regel fehlt, die eigentlich immer da ist. Das Problem mit einem Kernel-Update, das die Infrastruktur aushebelt, ist nicht neu, wie ich in Wenn ein Container-Update den Kernel überholt beschrieben habe.
Der eigentliche Fix: dass es nicht wieder passiert
Eine Regel von Hand nachzutragen ist keine Lösung, das ist eine Erste Hilfe. Der nächste Kernel kommt bestimmt.
Also ein kleines Skript, das genau das prüft und im Zweifel setzt. Drei Details daran waren wichtiger, als sie klingen:
Es läuft nach dem Container-Dienst, nicht davor. Startet es zu früh, existiert das Netz noch gar nicht, und es setzt eine Regel für etwas, das es nicht gibt.
Es läuft zusätzlich regelmäßig. Nicht nur beim Start. Denn die Regel kann auch im laufenden Betrieb verschwinden, wenn das Container-Netz neu aufgebaut wird — und dann wäre der Start-Automatismus längst gelaufen.
Es wartet auf die Sperre. Bei Änderungen an Netzwerkregeln kann ein anderer Prozess gerade dabei sein. Ohne Wartezeit bricht der Versuch ab, und zwar still. Ein Parameter, eine Sekunde Geduld, und aus einem gelegentlich stillen Fehlschlag wird ein zuverlässiger Ablauf.
Dazu eine Benachrichtigung nach jedem Neustart. Nicht weil sie den Fehler verhindert, sondern weil sie mich daran erinnert, dass gerade neu gestartet wurde — und ich dann hinschaue.
Was ich mitgenommen habe
Automatische Updates sind richtig. Automatische Neustarts brauchen eine Prüfung danach. Ich lasse Sicherheitsupdates weiterhin automatisch einspielen, das ist bei einem Server im Netz nicht verhandelbar. Aber jeder Neustart ist ein Moment, in dem etwas nicht wiederkommen kann, das vorher lief.
Überwacht, was der Dienst tut, nicht ob er läuft. Bei einem Mailserver ist die richtige Frage nicht „läuft der Container”, sondern „ist in den letzten Stunden eine Mail rausgegangen”. Bei einem Webserver nicht „antwortet er”, sondern „antwortet er mit dem richtigen Inhalt”.
Und der unangenehmste Punkt: Ich habe die erste Meldung weggeklickt. Nicht aus Nachlässigkeit, sondern weil sie in einem Zusammenhang auftauchte, in dem sie hundertmal vorher belanglos war. Genau deshalb sind fremde Programme schlechte Warnsysteme — man gewöhnt sich an ihre Fehlalarme, und dann hat man den einen echten auch weggeklickt.
Der Fehler hat mich zwei Tage Mailversand gekostet. Die Lehre daraus baue ich seitdem in jede Überwachung ein, die ich anfasse: Nicht fragen, ob es läuft. Fragen, ob es funktioniert. Wer sich für verschiedene Container-Ansätze im Homelab interessiert, findet in Proxmox-LXC-vs-Docker: Welcher Container-Ansatz ist optimal für Ihr Homelab? eine hilfreiche Gegenüberstellung.
FAQ
Welche Schritte sollte ich unternehmen, um meinen Mailserver nach einem Update zu überprüfen?
- Prüf die Netzwerkkonfiguration und den Zustand der Container.
- Stell sicher, dass die Dienste nicht nur laufen, sondern ihre eigentliche Aufgabe auch erledigen.
- Notier dir jede Fehlermeldung, auch die, die überflüssig aussieht.
Wie kann ich meine Überwachung verbessern?
- Bau Funktionstests ein, die eine konkrete Aufgabe durchspielen — beim Mailserver also: verschick testweise eine Mail nach draußen.
- Lass diese Tests regelmäßig laufen, nicht nur nach einem Update.
- Lass dir das Ergebnis pushen, sonst merkst du es wieder erst am zweiten Tag.
Was kann ich tun, wenn ich eine Fehlermeldung erhalte?
- Sieh dir erst den Zusammenhang an, bevor du etwas änderst.
- Zieh Daten aus mehreren Quellen, um die Ursache einzugrenzen.
- Und schreib auf, was du gemacht hast — beim nächsten Mal bist du schneller.
