Kernelupdate bei $KUNDE
$KUNDE ist mein ältester Begleiter: Er lässt sich inzwischen seit über fünf Jahren von mir betreuen und ist mir über drei Arbeitgeber treu gefolgt. Die Zusammenarbeit ist prima, und natürlich ist es mir extrapeinlich, wenn mal etwas nicht funktioniert. Auch wenn ich gar nicht schuld bin.
Das vorletzte Kernelupdate hat auf vier der fünf baugleichen Maschinen problemlos funktioniert. Nur die wichtigste, die äußere Firewall, kommt nicht wieder ans Netz. Ok, dann ist da wohl doch etwas nicht baugleich. Vorher hat es funktioniert, also rollen wir zurück: $KUNDE, bitte einmal auf $MASCHINE den alten Kernel wieder booten. Geht auch nicht. Mist. grml booten. Geht auch nicht. Was? Wir beginnen, das Netz zu debuggen. Nach dem Tausch des zum Intenet führenden Switches tut es wieder.
Beim letzten Kernelupdate der Zirkus wieder. Diesmal lasse ich den Fehler gleich im äußeren Netz suchen; nach Tausch der beiden On-Board-Interfaces untereinander und Einsatz eines neuen Patchkabels geht es wieder.
Heute waren wir vorsichtiger. Wir setzen ein extralanges Servicefenster an und natürlich kommt $MASCHINE nach dem Reboot nicht wieder ans Netz. Aber diesmal hilft kein wildes Hin- und Hertauschen irgendwelcher Komponenten. Irgendwann platzt mir der Kragen, und ich bitte den Kunden, den Rechner zu tauschen. Die neue Hardware kommt mit dem grml-System direkt und sofort ans Netz, und nach Eintragung der neuen MAC-Adressen ins Firewall-Setup war auch das
"richtige" System schnell wieder einsatzbereit.
Dann musste nur noch kurz am bind gedreht werden, weil neuerdings die Antworten an die von der IP-Adresse des "inneren" Interfaces nach drauße verschickten Queries zwar beim Host, nicht aber beim Prozess ankommen. Das ist wohl neue Kernel-Paranoia, der ich demnächst im Testlab mal zusammen mit den neuen Absonderlichkeiten beim Policy-Routing auf den Grund gehen muss.
Comments
Display comments as Linear | Threaded