Normalerweise, so denkt man sich, ist ein im Internet gemieteter Root-Server relativ sicher.
- es ist ein Unternehmen, das genau dieses Geschäftsmodell hat: Root-Server vermieten
- die Festplatten laufen im RAID-1
- monatlich werden die Kosten abgebucht, Routine
Das Unternehmen, um das es hier jetzt speziell gehen soll, wird nicht genannt – weil ich im Grunde bei mehreren Anbietern immer wieder das gleiche erlebt habe.
Somit soll hier der Schwerpunkt liegen auf: Wie geht man vor und „rettet“ die Daten?
Die Ausgangslage:
- der Server ist auf einmal nur noch sporadisch erreichbar
- der Kunde bemerkt, daß E-Mails nur noch verzögert zugestellt werden
- es kommen seltsame Nachrichten von „munin“ (Lock-Dateien können nicht gelöscht werden)
- man kann sich per „ssh“ nicht mehr einwählen.
Gut, im ersten Moment denkt man sich, Netzwerkproblem. Dies wird bestätigt erst einmal, weil mehrere andere Server im gleichen IP-Bereich nicht auf „ping“ antworten.
Aber irgendwann wird der Kunde unruhig, man solle es sich doch genauer anschauen. Also eine E-Mail geschrieben an den Hosting-Service.
Es kommt die Antwort: „Der Server hat ein Lüfterproblem“.
Ich schreibe zurück: „Gut, dann den Lüfter bitte wechseln“.
Es kommt als Antwort „Wir haben keine Ersatzteile mehr, der Server ist schon so alt“.
Das hat mich etwas stutzig werden lassen, denn normalerweise sollte man diese Lüfter vorrätig haben. Oder wissen, wie man ihn wieder gängig machen kann, z.B. mit einem Tropfen Öl. Evtl. ist er auch nur komplett zugestaubt.
Ich schreibe also zurück, dieser Server ist für den Kunden sehr wichtig, es ist eine wichtige E-Mail-Adresse dort definiert, die nicht ausfallen darf. Sie sollen den Server bitte irgendwie genau mit dieser IP wieder zum Laufen bringen.
Nach einigen Stunden kommt: „Wir haben alles versucht, der Rechner startet nicht aufgrund von Festplattenfehlern“.
Das hat mich das zweite Mal stutzen lassen, denn eigentlich müßte der Server ja auch von einer Festplatte starten oder eben ins Rettungssystem. Ich frage zurück „vielen Dank, der Lüfter geht also wieder, können Sie bitte ins Rettungssystem starten?“ und es kommt als Antwort „der Lüfter geht nicht. Sie können einen anderen Server aus unserer Produktpalette mieten. Wir können dann die Festplatten an diesen anstecken“.
Ich schreibe dies deshalb so genau auf, weil es im Prinzip immer das gleiche ist und ich es schon mehrmals genau so erlebt habe – bei mehreren Hosting-Server-Anbietern.
Das schlimmste ist natürlich der damit verbundene IP-Wechsel, das ist jedem klar, der einen Root-Server mit DNS-Server, WWW-Server und Mail-Server professionell wartet.
Also gut, der Kunde drängt, einen neuen Server bestellt und mit „Debian Trixie“ installieren lassen.
Vorweg: Ohne Backup ist man absolut chancenlos. Sie müssen ein Backup haben.
Der Kunde hatte eines, somit die wichtigsten Verzeichnis aus der Sicherung hochgeladen.
Natürlich sind die letzten Änderungen aber nicht in dem Backup enthalten.
Und natürlich ist auch nur noch eine Festplatte überhaupt lesbar. Auch auf meine Nachfrage kam „es sind beide angeschlossen“. Was nicht stimmt, ich sehe es ja mit „lsusb“.
Und die noch laufende Festplatte hat Lesefehler und gibt generell nur sehr langsam die Dateien aus. Also sehr langsam.
Mit „rsync“ kann man die fehlenden Dateien übertragen.
Der WWW-Server lief auch relativ schnell wieder.
Die fehlenden Perl-Module konnten auch nachinstalliert werden.
dovecot – IMAP-Server
Ein großes Problem ist aber „dovecot“. Denn die Konfiguration hat sich geändert. Und zwar erheblich.
Es hat mehrere Stunden gedauert, bis die Konfiguration angepaßt war, die „Maildir“-Ordner kopiert waren, mit „rsync“ auf den letzten Stand gebracht wurden und die Zugriffsrechte angepaßt wurden.
Denn auch bei den Zugriffsrechten auf die einzelnen Dateien unter „Maildir“ scheint sich seit „Debian Bullseye“ etwas geändert zu haben.
Der größte Brocken war aber „exim4“.
Das Paket „exim4-daemon-heavy“
Hier kann ich nur immer wieder sagen: Testen, testen, testen.
Erst einmal den Port 25 eingehend oder alle SMTP-Ports über die Firewall sperren.
So kann man in Ruhe das Paket installieren und konfigurieren. „postfix“, was bei der Standard-Installation dabei war, habe ich natürlich noch vor der DNS-IP-Umstellung deinstalliert, damit auf keinen Fall die E-Mails ins Leere laufen und zurückgehen. Die sollen ruhig bei den Absendern erst einmal auflaufen und zwischengespeichert werden.
Trotz deinstallierten Postfix kam übrigens immer der Fehler:
- fatal: master_spawn: exec /usr/lib/postfix/sbin/pickup: No such file or directory
Erst, als das exim4-Paket installiert wurde, scheint hier noch eine Bereinigung stattgefunden zu haben.
In der Ruhe liegt die Kraft!
Es kam dann der Fehler: „exim4 TLS error on connection (recv): Error in the pull function.“ – aber die E-Mail wurde trotzdem zugestellt.
Es müssen natürlich alle E-Mails wieder genau so angelegt werden, wie sie in der „aliases.virtual“-Datei angelegt sind. Man muß also für alle Kundenadressen dies noch einmal einzeln prüfen.
Entscheidend ist hierbei der Befehl: „exim4 -bt info@test.de“ – hier wird genau ausgegeben, wie die E-Mail geroutet werden würde.
Erst wenn alles stimmt, doppelt und dreifach getestet wurde, „exim4“ starten und dann in die Logs schauen.
Die E-Mails müßten nach und nach zugestellt werden – das kann bis zu 24 Stunden dauern, je nachdem, mit welchem Intervall es der sendende E-Mail-Server versucht.
Eine Neuerung gegenüber früher gibt es: Der Absender erhält keine Nachricht über die verzögerte Zustellung. Früher war es so, daß nach 24 Stunden eine E-Mail an den Absender geschickt wurde mit „Die E-Mail konnte 24 Stunden nicht zugestellt werden, ich versuche es weiter“. Dies scheint nicht mehr der Fall zu sein. Jedenfalls erhielt ich auf meine Test-E-Mails keine entsprechende Rückantwort und diese werden nun nach und nach alle zugestellt.
Fazit
Der „Umzug“ – denn nichts anderes ist es – hat seine Tücken. Denn es ist kein ausgetretener „Upgrade“-Pfad. Meist muß man auf eine neue Distributions-Version umstellen und die Datensicherung ist noch von einer alten. Damit ändern sich Konfigurationsdateien, Vorgaben an Zugriffsrechten etc.
Es zeigte sich auch hier wieder, daß die Zwei-Faktor-Authentifizierung nicht zu Ende gedacht wurde. Bei vielen Diensten kann man sich nur noch nach der Eingabe eines „Tokens“ authentifizieren, der wird über E-Mail zugestellt, aber wenn die E-Mail nicht geht, ist das eine Sackgasse. Hier könnte man höchstens ganz kurz die E-Mail konfigurieren auf irgend einem Server, die MX-Adresse im DNS eintragen, den E-Mail-Server kurz starten, das Passwort entgegennehmen, dann den E-Mail-Server wieder beenden und die E-Mail sauber konfigurieren mit allen Kundenkonten und den DNS-MX-Eintrag dann erst final einstellen. Jeder Einzelfall ist anders. Ich habe viel mit Datenrettung zu tun und halte die Zwei-Faktor-Authentifizierung für einen Irrweg oder besser für eine Schönwetterlösung.
Mein dringender Rat ist: Sichern Sie Ihre Server! Und lassen Sie evtl. eine zweite Person darüberschauen, auch über die Sicherung. Wurde wirklich alles gesichert? Lassen sich die Dateien auch in einer vernünftigen Zeit wiederherstellen? Wer hat die PIN zum Safe für die Liste mit den Passwörtern? Ich habe schon alles erlebt, bei einem Kunden wußte der Chef die PIN zum Safe nicht und den zuständigen Mitarbeiter hatte er Monate vorher entlassen…