Januar 2017 - Auch bei Webtropia ist die sogenannte Rescue-Funktion ein gezielt abgemagertes Debian Hilfs-Image für

• Installation,
• Diagnose
• Reparatur und
• Datensicherung,

.

Der Entwickler Michael Prokop hat es sich zur Aufgabe gemacht, ein nahzu perfektes Rettungssystem zusammenzustellen. Das kennen wir bereits von Knoppix und auch von den verschiedenen UBCD Windows Varianten, welche alle nur in Richtung Systemadministratoren schielen. Der normale Anwender wird bewußt nicht adressiert, er ist damit überwiegend überfordert.

Die Hilfen auf der grml.org Website sind beachtlich, da das Team doch recht klein ist. Sinnvollerweise lädt man die aktuelle Version herunter und brennt sich davon erst mal eine CD zum Spielen.

Als nächsten Schritt versucht man, diese grml CD auf einen USB-Stick zu portieren, Das ist schon nicht mehr so einfach. Es dauert etwas, weil unbekannte Fehler auftauchen können.
.

Vorher muß man wissen, daß es auch beim grml Config-Skripte gibt, die vorab offline angepaßt werden können und dann zusammen mit dem ISO IMage in den RAM-Speicher des Zielsystems geladen werden.

Das passiert für diesen (unseren) Server über ein Web-Interface Kommando. Dabei kennt dieses Debian Linux zwar schon eventuell vorhandene (angelegte) Partitionen und Platten, auch RAID Systeme, hat aber noch keine von denen gemountet. Das ist ganz wichtig.

Mit "cat /etc/issue" und "uname -a" bekommt man die komischsten Versionen angezeigt,mit denen man auf der Debian Web-Seite nichts anfangen kann :
Linux grml 3.19.0-1-grml-amd64 #1 SMP Debian 3.19-1+grml.1 (2015-02-24) x86_64 GNU/Linux - oder in Kurzform : stretch/sid
In einer Webmin-Maske stand es dann, es ist ein debian 9.0 !!!!


Wie das mit dem Start dieses Rescue-Systems geht, steht hier :
.

Wenn der Server physikalisch noch läuft (also das Netzteil "on" ist), muß er gezielt "runter gefahren - schafen gelegt werden" werden, also unbedingt sauber runter gefahren werden.

Also ein "Hardware Reset" (per ZKM-Interface) kann (könnte) tödlich sein. Ein (gedankenloses) "shutdown now" ist aber genauso tödlich, das schaltet diesen MSI-Sever (den ganzen Server-PC) am Netzteil physikalisch aus. Ich habe es erfolgreich probiert. Sie bekommen diesen Server nicht mehr ferngesteuert hochgefahren !!!!!

Der Vorschlag vom Support lautet daher :

• Sie können mit dem Befehl shutdown -r -t 60 einen "reboot" Ihres Systems nach 60 Sek. veranlassen. Die Wahl der Sekundenzahl ist dabei beliebig. Starten Sie dann über das ZKM das Rescue-System.

.
Wichtig : Beim Klick auf den Button "Rescue Modus aktivieren" wird sowohl die Boot-Methode auf Rescue umgeschaltet wie auch ein Hardware-Reset ausgelöst. Man braucht also kein Extra-Reset anzuklicken.
.

Mit dem Befehl shutdown -r -t 60 wird ein Reboot des Systems nach 60 Sek. ausgelöst. Laut Handbuch werden vorher alle Programme und Dienste gekillt/terminiert und alle Platten ent"mounted".

Ich lasse zusätzlich - bis zum bitteren Ende der noch laufenden Version - auf der putty Konsole ein "htop" laufen und schaue gleichzeitig in einer DOS-Box mit "ping 213.202.xxx.yyy -n 10000", wann das System wirklich down geht, also auf die pings nicht mehr reagiert und bestätige dann erst !!! die finale Maske zum Start des Rescue Modus. Denn der Start des Rescue Systems bedeutet nämlich zwangläufig auch einen Hardware-Reset.

Nach erfolgtem Neustart (wenn also die pings wieder erfolgreich zurückkommen) - jetzt vom Rescue-Systems - muss ich bei meinem Firefox 46 Browser (mit der immer noch geladenen Webmaske des Servers) ein Reload anklicken, dann bekomme ich das aktuelle Passwort für den SSH/putty Zugang zum Rescue Modus angezeigt.
.

Das Webtropia Rescue-System ist vergleichbar mit dem Rescue- Minimal-System, das Sie vielleicht von den SuSE / Debian Installations CDs kennen. Hier stehen Ihnen nur grundlegende Linux Kommandos sowie ein paar wichtige Werkzeuge wie der "midnight commander" zur Verfügung.

Aktivieren können Sie das Rescue-System im zentralen Kundenmanagement ZKM. Ihr Server wird dann (auch !!) neu gebootet und lädt über das Netzwerk das Rescue-System (mit der vorkonfigurierten Haupt-IP Adresse) in den RAM Hauptspeicher.

Wichtig : Beim Klick auf den Button "Recue Modus aktivieren" wird sowohl die Boot-Methode auf Rescue umgeschaltet wie auch ein Hardware-Reset ausgelöst. Man braucht also kein Extra-Reset anzuklicken.
.

Ob es der Server bereits tut, also ob er (mindestens) von seiner Netz-Adresse antwortet, prüfen wir in der DOS-Box (von Windows) mit

ping 213.202.xxx.yyy -n 10000

und lassen es (im Zweifelsfalle) so lange laufen, bis dort eine Antwort mit der Antwortzeit kommt.

Sie erhalten (nach einiger Zeit des Bootens) auf der Webseite (aber erst nach einem "Reload" !!!!) ein "Zufalls-" Passwort für diese Session, das Sie sich unbedingt sichern / abspeichern sollten.

Sobald der Bootvorgang beendet ist, können Sie sich via SSH (putty) auf ihren Server verbinden (eventuell auftretende Fehlermeldungen Ihres SSH Clients können Sie ignorieren.) Sowohl der User = "root" und "immer das neue PW" !!! werden im Servermanagement ZKM angezeigt.
.

Das Rescue-System erkennt zwar die vorhandenen Festplatte(n) ihres Servers (also die Partitionen), bindet die aber ganz bewußt nicht automatisch ein. - Sie müssen diese Partitionen selbst gezielt mounten, damit Sie wissen, was Sie da tun.

Die für uns wichtige (System-) Partition der 1. Festplatte wäre eigentlich das Device /dev/sda2. Aber das geht bei RAID1 Systemen so nicht. Sie müssen nicht die physikalische Platte sondern die logische RAID1 Partition ansprechen und mounten. Bei uns liegt das (evtl. defekte ?) Betriebs-System auf der 2. oder 3. Partition der RAID1 Systems.

Achtung : Die ansprechbaren Partitionen eines Software Raid1 heißen also nicht "sda1" oder "sdb1", sondern "md1 oder md2" und die Partitionen 1 bis 3 sehen Sie in der Regel unter /dev/md0 bis md2. Deshalb schaun wir immer erst in /etc/fstab nach, wo welche Partitionen mit welchen Nummern zugeordnet werden. Das ist ab und zu bei jedem Neustart des Rescue-Sytems anders. (Warum ??)
.

Bei unseren XEN-Installationen haben wir für die DOM-0 (das XEN-Grundsystem - auch Hyppervisor genannt) absichtlich 3 primäre RAID1 Partitionen (wichtig für ganz neue Festplatten mit über 2 TB Größe oder für das LVM) - warum die aber ab und zu willkürlich rückwärts gezählt werden, ?? ist halt so.

md1 = swap
md2 = /boot
md3 = /  (unser root-System)

Hier ein Beispiel (dennoch immer vorher prüfen)

aus der /etc/fstab entnommen sieht das so aus:

# Added by GRML /dev/md0
/dev/md0 /media/md0 swap defaults 0 0 # /dev/md0
# Added by GRML /dev/md1
/dev/md1 /media/md1 ext4 noauto,user,dev,suid,exec 0 0 # /dev/md1
# Added by GRML /dev/md2
/dev/md2 /media/md2 ext4 noauto,user,dev,suid,exec 0 0 # /dev/md2

Um Verwirrungen oder Vertauschungen vorzubeugen, legen wir 2 Verzeichnisse an:

mkdir /mnt1
mkdir /mnt2

Bei unserer opensuse Installation (auf der Platte) muß im Rescue-System der Mount-Befehl für die jeweilige Partition zum Beispiel so lauten: 

"mount /dev/md1 /mnt1" oder
"mount /dev/md2 /mnt2" oder der aktuellen Info entsprechend.

Und das hatte bei mehreren Versuchen mehrmals funktioniert.
.

Der Inhalt der opensuse System-Festplatte im "root" Bereich "/" ist danach unter "/mnt2" erreichbar. - Sie können jetzt Korrektur- und Pflege-Arbeiten an dem System vornehmen oder, da das System offline ist, eine saubere Datensicherung erstellen und via SCP abholen.

Bitte beachten Sie, daß das Rescue-System so lange aktiv bleibt, bis Sie es im Kundeninterface ZKM wieder deaktivieren und diesmal den Server zusätzlich neu starten.

Das Passwort des Rescue Modus wird bei jedem Start neu generiert. Es kann im dedicated Server Management im zentralen Kundenmanagement eingesehen werden, sobald das Rescue System vollständig geladen wurde. Und dann besser sofort lokal abspeichern - mit Datum und Uhrzeit - man kann nie wissen, wie oft man es für diese Rescue Session noch braucht.
.
Wir wollen aber zuerst die vorhandene lauffähige initiale opensuse Minimalversion sichern, weil dort die RAID1- Konfiguration sowie die Netzwerk-Konfiguration funktionierend enthalten sind.
.

Im Prinzip machen wir das Gleiche wie mit den virtuellen Maschinen, die zuerst runter gefahren werden und dann offline gesichert werden. Alle temporären Dateien sind dann nicht vorhanden und verwirren nicht.

Deshalb werden jetzt sowohl die "/boot" Partition und die "/" Partition (wir brauchen bei unserer Konfiguration die Inhalte dieser beiden Partitionen) mit tar zu einem tar.gz File gepackt und "Nachhause" (aufunsere lokalen NAS Server) geholt. Damit habe ich (für immer) eine minimale lauffähige opensuse 13.2 für diesen Server und diese IP Nummer.
.

Wie schon angesprochen, brauchen wir für die Virtualisierung eine andere Partitionierung als sie bei der Initial-/Grund-Version von webtropia vorgesehen war. Dort wird zwar nach der "swap" Partition (8GB) auch eine separate /boot Partition (1 GB) angelegt, aber die 3. Partition ("/") ist 922 Gigabyte groß und das ist für unsere Virtualisierung ungeeignet.
.