Hallo Leute,
manchmal überkommt einen die Lust etwas neues auszuprobieren bzw. etwas umzusetzen. Bei mir führte das heute dazu, dass ich meinen Dedi @ Kimsufi im Rescue-Modus starten musste. Wie man sich in diesem zurecht findet und warum man nicht am Freitagabend „Sysadmin“-Arbeiten durchführen sollte, mag ich kurz erläutern.
Alles fing damit an, dass wir in der Uni an einem Semesterprojekt arbeiten und wir auf „vagrant“ setzen, um eine virtuelle Maschine auf fast allen Hosts „gleich“ aussehen zu lassen.
Da nächsten Montag die Vorstellung des Projekts ansteht, wollte ich eine „Live“-Version auf meinem Server starten. Nach ein wenig hin-und-her mit der korrekten Version von Vagrant (Repo < Gem < Offizieller Download), meldete sich bei der Installation von virtualbox die Installationsroutine mit der Nachricht, dass sie die Quelldateien fürs Kernel-Modul nicht finden könne, bzw. das sie das „vboxdrv“-Kernelmodul nicht laden könne.
Gleichzeitig wurde mir ein kompatibler 3.2-er Kernel mitinstalliert. Nach ein wenig Googlen im Kimsufi/OVH Forum kam ich zu dem Schluss, dass der Standard-OVH-Kernel nicht mit virtualbox läuft (da die Module fehlen).
Jeder, der nur 3.5 Stunden Schlaf in der letzten Nacht bekommen hat, wird einfach zu dem Schluss kommen den neuen Kernel im Grub auszuwählen und den Server neuzustarten. Genau das tat ich auch.
Nachdem sich mein Server verabschiedet hatte und die SSH-Verbindung versiegte, wartete ich 30 Sekunden bis eine Minute. Normalerweise war die kleine Box danach wieder online. Der Versuch sich per SSH zu verbinden scheiterte natürlich und ein Ping kam auch nicht wieder zurück. Ein ungutes Gefühl legte sich über mich und nach weiteren 2 Minuten gab es immer noch keine Reaktion.
Wir halten fest: Auf dem Server laufen einige gut besuchte Webseiten, sodass man die Downtime möglichst kurz halten sollte.
Nunja, dann bleibt einem nichts weiter übrig als sich im Kimsufi-Kundencenter einzuwählen und über „Netboot->Rescue“, sowie einem darauffolgendem Neustart, die Kiste in den Rescue-Modus zu versetzen.
Nach ein paar Minuten bekam ich dann auch schon eine (unverschlüsselte [sic!]) Email mit dem neuen Root-Passwort (sic!!!). Nach dem Einloggen auf dem Server sah ich mich etwas um und stellte fest, das man sich um alles selbst kümmern darf (was natürlich logisch ist ;)).
Im Gegensatz zur Rescue-Dokumentation von Kimsufi/OVH muss man die Mounts des Soft-RAIDs anders ausführen.
mount /dev/md1 /mnt
mount /dev/md2 /mnt/home„md1“ ist bzw. sollte in den meisten Fällen die Root-Partition (/) sein. Auf „md2“ befindet sich laut der Dokumentation die home-Partition (ehrlich gesagt, hab ich da nicht nochmal reingeschaut).
Bevor wir das Chrooting ausführen können, sollten wir noch ein paar benötigte Sachen in das Chroot-Directory mounten:
cd /mnt
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/Ist dieser Schritt getan, so können wir uns in ein Chroot begeben, um auf dem Server arbeiten zu können.
chroot /mnt/Nun kann man wie zuvor gehabt den alten Kernel im Grub wieder aktivieren, oder andere Sachen gerade biegen.
Ist man mit allen Rettungsmaßnahmen fertig, so darf man nicht vergessen im Kundencenter unter „Netboot->Festplatte“ die Bootoption zurückzustellen. Zuletzt führt man in der Rescue-Shell ein „/sbin/reboot“ aus.
Was lernen wir aus der Geschichte? Man sollte nicht übermüdet und leichtsinnig an einem Produktivsystem arbeiten. Zudem sollte dieser Zeitpunkt nicht auf einen Freitagabend fallen. Besser ist da wohl der Samstagmorgen, wenn man ausgeschlafen und mit klarem Kopf an die Sache ran geht.
~ Sebastian