Eigenes Rescue System

Milchbroetchen

Hello :-)
Hallo,
folgendes ich möchte meinen Kunden ein eigenes Rescue System über PXE bereit stellen, dazu habe ich mir in einer VM ein Debian Installiert und einiges an Software sowie scripte dort Installiert/abgelegt. Wie gehe ich nun vor um dieses Debian in ein Image zupacken und dieses dann per PXE auszuliefern bei Bedarf?

Zur verfügung steht:
- eigener DHCP Server (ISC-DHCP-Server Instaliert)
- eigener PXE Server (tftp Daemon ist Installiert)
- eigener NFS Server

Es soll quasi so etwas in der Art sein wie Hetzner es anbietet, der Kunde drückt im Managment Interface auf Rescue aktivieren, bekommt ein "einmal" Passwort angezeigt womit er sich nach einem neustart des Servers in das bereit gestellte Rescue System einloggen kann.

Die von mir angebotenen Server unterstützen alle PXE boot (vServer auf Basis von Proxmox und dedizierte Server)

EDIT: Habe gehört, ich muss den Kernel meines zukünftigen Rescue Systems read only (ist ja logisch read only, sonst kann ja jeder etwas daran verändern) über den TFTP Server laden, dieser holt sich vom NFS Share wohl den Rest des Systems. Zusätzlich muss man wohl noch ein OverlayFS drüber laden damit das System wohl Temporär beschreibar ist solange wie es genutzt wird. Sind das richtige Informationen die ich habe? Falls ja, wie gehe ich dabei vor, hat jemand so etwas bereits am laufen in der Konstellation?

Das Debian was ich gerne als Rescue System nutzen soll existiert als Installation in einer Virtualbox lokal auf meinem PC, ich hoffe ich habe alles wichtige erwähnt.

Gruß
Ich :)
 
Last edited:
Hast das schon gelesen: http://etherboot.org/wiki/appnotes/bootbymacaddress

Wichtig ist, dass auch die richtigen Hosts das Image bekommen und das steuert man über die persistente MAC Adresse.

Die MAC-Adresse und IP-Adresse müssen dann zur dhcpd.conf hinzugefügt werden.
Der holt sich dann den Kernel GPXE via TFTP, lädt den Kernel GPXE und lädt den Rest via NFS HTTP. In dem Beispiel nutzen die GXPE (zum ersten mal von gehört), welches ein Bootloader für Netzwerkkarten sein soll. Die laden dann via HTTP Kernel, initrd und Scripte nach.

Die Hauptaufgabe besteht also darin, passende Scripte zur Verfügung zu stellen und auf irgendeine Art die dhcpd.conf zu verändern.
Am besten wäre ein Dienst mit Datenbank, der die dhcpd.conf fehlerfrei verändert. Wenn man das manuell macht, macht man Fehler.

Zusätzlich haben die Hoster noch Hardware, die ferngesteuert einen Reset- oder Power-Signal ausgeben kann.
Irgendwie muss man den Host ja auch neustarten können, wenn er hängen bleibt oder man sich selbst ausgesperrt hat.
Das Herunterfahren eines Hosts ist mir mal ausversehen passiert. Ziemlich peinlich das ganze.


Vielleicht ist der DHCP-Server besser: https://kea.isc.org/
Ich hatte mal auf Stackoverflow gesucht, dort ist unter anderem die Rede von LDAP beim isc-dhcpd.
Ein User hat sich z.B. ein kleines Python-Script geschrieben, um aus einer Datenbank die Einträge in die Konfiguration zu übertragen.
Vielleicht kann das der KEA besser.

Kea is an open source software system including DHCPv4, DHCPv6 servers, Dynamic DNS daemon, REST API interface, MySQL, PostgreSQL and Cassandra databases, RADIUS and NETCONF interfaces and related utilities.
Hört sich vielversprechend an. Die Rest-API könnte die Aufgabe vereinfachen.
 
Last edited by a moderator:
Wenn es wie beschrieben sich nur um vServer handelt wäre eine Rescue-CD welche der Kunde mounten und dann darin booten kann deutlich flexibler. Über VNC kann er dann auf die Konsole zugreifen. Du könntest das Image aber falls gewünscht auch einstellen dass es nach dem Boot das Einmal-Passwort von deiner Rescue-Oberfläche abruft und als root-Passwort setzt so dass es SSHbar ist.
 
@DeaD_EyE vielen dank für deinen sehr ausführlichen Beitrag bis her. Wie kann ich denn mein bestehndes Rescue System was ich zur Zeit in der "Entwicklung" lokal auf dem PC in Vbox in ein bootbares Image bzw. Kernel Image verwandeln? Das ist zur Zeit mein größtes Problem, nicht unbedingt der PXE Bootvorgang an sich. @d4f Danke für deinen Tipp, es handelt sich dabei nicht ausschließlich um vServer sondern auch um einen größeren Teil root bzw. Dedicated Server.
 
Ich hatte in einem anderen Forum mal eine frage gestellt (nein es handel sich nicht um die gleiche wie hier) und bekam dies als Antwort:
Das Rescue System besteht aus mehreren Komponenten, für die ein direkter Download wenig Sinn macht. Das Rescue Image selbst kann man sich aber trotzdem jederzeit von unserem NFS Server kopieren. Aber an sich handelt es aber nur um ein ganz normales Debian. Der Rest ist auch nichts besonderes, ein Kernel via TFTP geladen, der vom NFS das Rescue Image readonly mounted und ein OverlayFS drüber legt damit es beschreibbar ist.

Meine Frage ist nun wie erstelle ich so ein Image und was hat es mit diesem OverlayFS auf sich?
 
Zu Overlayfs:

Lower == Persistentes Dateisystem
Upper == Beschreibbares Dateisystem
Workdir == Beschreibbares Dateisystem (auf dem gleichen Dateisystem wie upper!)

Als ich das gelesen habe, war meine erste Frage wozu workdir da ist. Das workdir benötigt man, sobald auf das FS beschreibbar sein soll.

Als Image könntest du den Ubuntu Server verwenden. Du müsstest dann die ISO auspacken und dann die entsprechenden Komponenten wie kernel und initrd zugänglich machen (GPXE -> http server). Der restliche Inhalt der ISO wird ganz normal via NFS Share bereitgestellt. Alternativ könnte man auch squashfs nutzen. Squashfs ist ein komprimiertes read-only Dateisystem, dass als Datei zum Client übertragen werden kann. LiveCDs machen das öfters. Dann wird das Archiv im speicher des Clients geladen und dann gemountet.
 
Last edited by a moderator:
Kurze Verständnisfrage, wenn ich ein Debian Image (squashfs) über tftp/nfs lade und entsprechende nutzer in diesem ReadOnly Rescue System arbeiten möchten muss ich dieses workdir als Filesystem drüber legen?
 
Ob man sqauschfs via NFS mounten kann, ist mir nicht bekannt. Ich vermute mal ja. Ist fast wie ein ISO-Image, nur dass es komprimiert ist.
 
muss ich dieses workdir als Filesystem drüber legen?
Um sicher zu gehen dass ich deine Frage verstanden habe; du möchtestest wissen ob man ein r/w Dateisystem über das ro Squashfs Dateisystem drüber legen muss? In dem Fall, ja.
Die generelle Methode ist, ein tmpfs an zu legen und über UnionFs dann das geladene Squashfs temporär beschreibbar zu machen. Bei heutiger Ram-Ausstattung ist das generell absolut kein Problem. Wichtig dabei ist dass ein TmpFS den Ram erst anfordert wenn er belegt wird und danach wieder freigibt. Du kannst also quasi tmpfs quasi gleichgross dem realen RAM machen um möglichst hohe Flexibilität zu ermöglichen.

Schau dir bei Möglichkeit übrigens mal die OVH Rescue für dedizierte Server an. Habe zwar keinen Einblick in deren aktuellste Version, aber vor paar Jahren war das eine wirklich hübsche Oberfläche inklusive web-basierter Hardwarediagnose.
 
Aktuell verwende ich initial einen ro nfsmount aus welchem ich dann ein tmpfs rw mache.

Die Dokumentation ist bei korrekter Anfrage über Dr. Google zu finden.

In Kurzform:

- debootstrap eines Debian
- ein bissl script "magic" in den initramfs Scripten
- fertig, Debian Rescue gebootet (innerhalb von ca. 90 Sek.) ssh offen, passwort gesetzt
 
Last edited:
Back
Top