Spaß mit Server-Upgrades: heute Debian Stretch vs. manitu

Zwei Dinge sind passiert:

1. Es gab ein paar Jahre kein Update mehr in dem Blog.
2. Es gab schon länger kein größeres System-Update mehr auf unserem Server.

Da musste unweigerlich was passieren.

Zunächst die gute Nachricht: inzwischen sind Debian-Updates im Regelfall recht pflegeleicht geworden.

Ein Server-Update von Debian Wheezy auf Debian Jessie läuft weitestgehend sang und klanglos innerhalb von 20 Minuten durch (trotz Umstellung auf systemd als Init-System!).

Heiter wird es dann allerdings, wenn der Kernel im Rahmen des Umstiegs auf Debian Stretch auf eine 4er Version aktualisiert wird und wir den finalen Server-Reboot wagen und es passiert: nichts.

Jetzt gibt es ja mehrere Möglichkeiten, woran das liegen könnte:

1. Die Maschine macht nach einigen Jahren uptime ihren wohlverdienten Plattencheck und möchte die nächsten Stunden / Tage nicht gestört werden.
2. Beim Bootloader Update ist was schiefgegangen und das Ding bootet gar nicht mehr.
3. Die Kiste ist sehr wohl gebootet, hat nur bei der Netzwerkeinrichtung Probleme.

Jetzt würde man die Fälle ja gerne unterscheiden können. Könnte man auch, wenn der Provider eine serielle Konsole anbieten würde – was er nicht tut, trotz allgemeinem Wunsch und eigenem Bekunden das doch sinnvollerweise zu tun 🙁

Nach einem beherzten Reboot die Erkenntnis:

Die Netzwerkkarte bekommt keine korrekte MAC-Adresse und wird daher auch unter neuem Device-Namen geführt:

Apr 13 13:26:28 manitu kernel: [ 1.413929] r8169 0000:03:00.0 (unregistered n
et_device): rtl_chipcmd_cond == 1 (loop: 100, delay: 100).
Apr 13 13:26:28 manitu kernel: [ 1.413996] r8169 0000:03:00.0: irq 44 for MSI
/MSI-X
Apr 13 13:26:28 manitu kernel: [ 1.414177] r8169 0000:03:00.0 eth0: RTL8168b/8111b at 0xffffc90001b38000, ff:ff:ff:ff:ff:ff, XID 9cf0f8ff IRQ 44
Apr 13 13:26:28 manitu kernel: [ 1.414180] r8169 0000:03:00.0 eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko]

Nach einigen Experimenten stellt sich raus: nicht nur die MAC-Adresse ist futsch, die die Onboard-Netzwerkkarte funktioniert so gar nicht.

Tausend und ein Reboot später: es handelt sich um ein Problem in Linux Version 4.0.0 bis einschließlich 4.9, weil irgendein Trottel bei Gigabyte nicht in der Lage war korrekte ACPI-Tabellen im BIOS zu hinterlegen und neuere Kernel-Versionen (größer >= 4) anfälliger wurden. (Siehe ähnliches aber nicht gleiches Problem hier)

Fix dann zumindest in der Backports-Kernel Version 4.18, da ist das Problem gelöst.

Bis dahin allerdings eine heitere Reboot-Orgie mit Rettungssystem und regelmäßigen Plattenchecks (wenn die Partition clean war, hat der Boot gar nicht geklappt, fsck als Boot-Detector, weil, genau: keine serielle Konsole 🙁 ).

Und zusätzliche Freude:

Nachdem dann das Hauptsystem uns wieder mochte (zumindest so halbwegs): nächste Clown-Nummer: die DNS-Optionen in /etc/network/interfaces sind inzwischen nicht nur obsolet, sondern verhindern zuverlässig die Konfiguration der Schnittstelle.

Selbst wenn man das irgendwann einsieht (hatte ich schon erwähnt wie beschissen Fehlerlogs lesen mit systemd eigentlich ist?) kommt die nächste Heiterkeit:

Die Container-Infrastruktur bootet nicht mehr.

Weil: naja, irgendein Clown in Linux 4.18 (Debian Stretch Backports-Kernel) nicht rückwärtskompatible Änderungen an der Namespace-Infrastruktur gemacht hat, die sich auf alle LXC-Versionen auswirken, die richtig: älter sind als die bei Debian Stretch mitgelieferte Version 2.X…

Es gibt ja noch Kernel aus der 3er-Serie, die sich gut mit Debian Stretch verstehen :-/ …

Jetzt gab es dabei auch die ein oder andere WordPress Aktualisierung (so wie dieses Blog z.B. 🙂 ).

Dabei kann man auch viel Freude haben, selbst wenn man brav die Distributionspakete verwendet, um zumindest halbwegs mit Sicherheitsaktualisierungen rechtzeitig beglückt zu werden.

Zwei wichtige Erkenntnisse:

1. Eine fehlerhafte SSL-Konfiguration hinter einem Reverse-Proxy lassen alte Versionen noch klaglos über sich ergehen, das aktuelle WordPress empfindet es als kompletten Afront und begrüßt angemeldete Benutzer mit einer nichtssagenden “Sorry, you are not allowed to access this page”. Jetzt bin ich nicht der einzige, der diese Fehlermeldung schonmal gesehen hat. Eine fehlerhafte SSL-Konfiguration steht jetzt aber nicht unbedingt auf den einschlägigen Seiten zu der Fehlermeldung, was da denn so schiefgegangen sein könnte… Für alle, die auch WordPress hinter nginx betreiben. Es gibt ja Lösungen für das Problem, wenn man weiß, wonach man suchen muss.
2. Ein Apache-Upgrade verändert durchaus auch mal, wie Verzeichnisrechte zu konfigurieren sind… Well, das ist dann doch mehr der alltägliche Wahnsinn und schnell gelöst.