Permalink

0

Shit happens

Einen etwas in die Jahre gekommenen invis-Server auf aktuellen Stand zu bringen ist eigentlich kein Hexenwerk.

Im Idealfall sichern Sie das „/etc“ Verzeichnis, sämtliche Datenbanken und machen einen Snapshot des LDAP-Verzeichnisses. Ist der Server auf einem Software-RAID 1 aufgesetzt trennt man den Verbund auf und legt eine der beiden Festplatten erst mal auf die Seite.

Die verbleibende Festplatte ist mit den Smartmontools auf ihren Gesundheitszustand zu testen. Ist alles OK kann die Neuinstallation einer aktuellen openSUSE beginnen. Dabei wird die bestehende Partitionierung beibehalten und die Logical-Volumes „srv“ und „home“ ohne Formatierung aus der vorherigen Installation übernommen.

Danach „sine“ durchlaufen lassen, ein paar Konfigurationen wie SMTP-Relayhost und die DDNS-Keys aus der alten Installation übernehmen. Etwas knifflig ist die Übernahme der bestehenden Benutzerkonten und DHCP/DNS Objekte aus dem alten LDAP-Verzeichnis ins Neue, sowie die Anpassung der Samba-Domain-SID. …aber auch das ist keine große Kunst.

So geschehen jüngst in Bochum. Nach getaner Arbeit ein gutes türkisches Essen im „Side“ und ab ins Bett.

Der nächste Morgen beim Kunden begann mit einem „Ah Herr Schäfer, gut dass Sie kommen, es funktioniert gar nichts mehr.“ Diesen Moment sollte jeder Admin in seinem Leben mindestens ein Mal erlebt haben.

Fehlersuche. Hmm, der Server läuft (scheinbar) normal, trotzdem erhalten die Clients keine IP vom DHCP-Dienst. Dienst neu gestartet, Kabel, geprüft, Switch zurück gesetzt, kein Erfolg. Na, dann „reboot tut gut“. Beim Neustart blieb der Server aufgrund schwerwiegender Dateisystemfehler im var-Volume hängen. Erste Schweissperlen auf der Stirn…

Es zeigte sich, dass ein Kurztest (smartctl -t short /dev/sda) und nachfolgende Überprüfung des Ergebnisses einfach keinen Surface-Scan ersetzen. Für letzteren ist nur meistens keine Zeit.

Wie weiter? Neuer Versuch mit der verbleibenden Platte der alten Installation? Kommt nicht in Frage, der doppelte Boden wird nicht aufgegeben. Der Weg zurück darf erst abgebrochen werden, wenn alles funktioniert!

Der Ansatz: Etappenweises Klonen bzw. Kopieren der einzelenen Volumes bzw. Verzeichnisstrukturen auf eine intakte Platte. Dabei habe ich die Partitionierung manuell vorgenommen, die RAID-Verbünde mit der „missing“ Option erstellt und eine Volume-Group unter anderem Namen auf der neuen Platte angelegt. Das hat mit „ddrescue“ und der letzen aktuellen Datensicherung alles in allem gut funktioniert. Allein die Installation des Bootmanagers Grub2 wollte nicht gelingen. Nach ein wenig Bastelei, fand Stage-1 auch seinen Platz im MBR der Platte, doch beim Start des Systems wurde die Volume-Group des
Root-Dateisystems nicht gefunden. Stimmt, ihr Name lautete ja jetzt „system2“ statt „system“, also kurzerhand mit Hilfe des openSUSE Rettungssystems umbenannt Reboot und Feierabend… Murphy lässt grüßen, „Volumegroup system nicht gefunden“. ;-(

OK, openSUSE arbeitet mit UUIDs zur Kennzeichnung von Datenträgern, die können ja nicht stimmen, ergo müssen die „grub.cfg“, sowie am besten auch gleich die „initrd“ neu angelegt werden. Dazu wieder das Rettungssystem gestartet. Alle wichtigen Volumes zu einer chroot-Umgebung zusammen gebaut und dann noch „/proc“, „/dev“ und „/sys“ aus der
Rettungsumgebung in die chroot-Umgebung eingehängt, „grub2-mkconfig -o /boot/grub2/grub.cfg“ ausgeführt und festgestellt, dass es wohl ein langer Tag wird.

Um es hier kurz zu machen: Das geht nicht mit dem openSUSE Rettungssystem, da darin wichtige Einträge in „/dev“ mit Symlinks nach „/mounts“ zeigen und genau das lässt sich nicht in die chroot-Umgebung übernehmen. Symbolische Links die aus der chroot-Umgebung führen, sind innerhalb derselben schlicht „broken“. Es resultiert darin, dass „/dev/mapper/console“ fehlt. Sackgasse, zumindest, wenn man morgens um 4:00 Uhr von Stechmücken geweckt wurde und völlig übermüdet ist.

Mein Fehler war natürlich, dass ich „laaange“ versucht habe das Problem zu beheben. Alle mit Google auffindbaren Beschreibungen, lieferten genau die Schritte zu Tage, die ich bereits versucht hatte. Es war die reine Verzweiflung (und Ines, die mir am Telefon mit Nachdruck Hilfe anbot), die mich dazu trieb statt des Rettungssystems eine openSUSE Live Umgebung zu verwenden. Genau das führte zum Erfolg, die Live-Systeme kommen beim Aufbau im Unterschied zum Rettungssystem ohne Links nach „/mounts“ aus und die Sache funktioniert.

Eine Begründung für diesen nervenaufreibenden Unterschied hätte ich schon gerne.

Stefan

Schreibe einen Kommentar

Durch die weitere Nutzung der Seite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn Sie diese Website ohne Änderung der Cookie-Einstellungen verwenden oder auf "Akzeptieren" klicken, erklären Sie sich damit einverstanden. Genauere Informationen können Sie unseren Datenschutzbestimmungen entnehmen.

Schließen