Rescuesystem in der eigenen Netzwerkinfrastruktur (PXE)

Hallo und Herzlich Willkommen zu diesem Howto,

in diesem Howto werden wir einen PXE-Server mit Hilfe der Gentoo Subdistribution SysRescCD aufsetzen und dann weitergehend ein wenig darauf eingehen, welche Möglichkeiten man damit in einer professionellen Netzwerklandschaft hat.

Einführung
Vorraussetzungen für dieses Howto sind:
  • eine Bekanntschaft mit der Linuxkonsole.
  • Wissen über die grundlegenden Systemprozesse von Linux.
  • Vertrautheit mit Bootloadern und Bootprozessen im Allgemeinen.
Das Howto ist so verfasst, dass eigentlich jeder etwas fortgeschrittene Linux Systemadministrator keine Probleme haben sollte alle Schritte zu verstehen und auszuführen (außer Suse-Anwender; auch fortgeschrittene Suse Andwender sollten hier aufhören weiter zu lesen und sich nicht von all dem Fachlatein das gleich folgt verwirren lassen: "Wie? Kann ich das nicht mit der Maus anklicken?").

Wir verwenden SysRescCD, da es einige Vorteile für unser Vorhaben bietet:
  • es bringt bereits alle Tools mit die wir für einen PXE-Bootserver benötigen.
  • es lässt sich sehr einfach upgraden.
  • es ist statisch (was man bei einem Rescuesystem zu schätzen lernt).
  • es ist eine sehr leichtgewichtige Distribution (das ganze System muss ja beim PXE-Boot über die Netzwerkanbindung geschoben werden).
  • es lohnt sich, sich damit anzufreunden, weil es wohl, wie der Name auch impliziert, die beste Rescue Distribution ist, die so kursiert.
Installation des Rescueservers
Als erstes geht es auf die Sourceforge Seite von SysRescCD und dort wird die neueste stabile Version der Distribution geladen. Googlefaule klicken einfach auf den Link:

http://sourceforge.net/projects/systemrescuecd/
Zum Zeitpunkt dieses Howtos ist das die Version 1.3.0.

Brennt das ganze auf CD und schmeißt es in euren Server. Die Verwendung von VMware oder einer anderen virtuellen Maschine sei hier ausdrücklich empfohlen.

Ich gehe jetzt hier davon aus, dass der Server komplett "nackig" ist und nur eine Festplatte hat. Bei entsprechend anderer Konfiguration müssen die Schritte natürlich angepasst werden.

Wundert euch nicht, dass mein Installationsprozess für "SysRescCD auf HDD" hier von dem im Wiki von SysRescCD abweicht. Der dort beschriebene Weg ist nicht optimal und kompromitiert nicht nur die Updatefähigkeit des Systems, sondern auch dessen Funktionalität. Ich habe dort auch schon ein entsprechendes Statement ins Development Forum geschrieben.

Also wir starten von der CD und benutzen die Bootparameter:

altker64 setkmap=de backstore=off


Der alternative Kernel ist zwar größer, aber auch wesentlich kompatibler. Damit man nicht gleich in ein Problem läuft bei dem z.B. die Festplatten nicht erkannt werden empfehle ich hier den alternativen Kernel. Wenn natürlich alles geht, dann kann man natürlich auch gerne den optimierten Standardkernel verwenden. Backstore auszuschalten wäre an dieser einen Stelle zwar eigentlich überflüssig, sollten wir aber nochmal mit einem CD-Boot nacharbeiten müssen ist es wichtig, dass Backstore deaktiviert ist. Mit den F-Tasten kann man sich eine Menge Bootparameter und Erklärungen ansehen.

Jetzt machen wir uns mit

fdisk /dev/sda


oder der entsprechend abweichenden Festplattenbezeichnung des Servers eine primäre Partition. Bitte nicht vergessen, das Boot-Flag für diese Partition zu setzen.

Die Ausgabe von

fdisk -l


sollte dann in etwa so aussehen:
fdisk -l
Da ein Journaling Filesystem nicht optimal geeignet ist für speicherarme System, da zu wenige Nodes erstellt werden entscheiden wir uns hier für ext2:

mke2fs /dev/sda1


Jetzt kopieren wir in einem Rutsch die Distribution auf die Festplatte und kreieren symbolische Links zu den Bootdateien. Das hat den Vorteil, dass wir ein Update einfach machen können indem wir eine neuere Version der Distribution komplett wieder auf Festplatte kopieren und alle Dateien überschreiben, da die symbolischen Links einfach weiter auf die neuen Versionen der Dateien zeigen:

mount /dev/sda1 /dev/custom

cp -rv /mnt/cdrom/* /mnt/custom

mkdir /mnt/custom/sysrcd

ln -s ../sysrcd.dat /mnt/custom/sysrcd/sysrcd.dat

ln -s ../sysrcd.md5 /mnt/custom/sysrcd/sysrcd.md5

ln -s ../isolinux/rescuecd /mnt/custom/sysrcd/rescuecd

ln -s ../isolinux/rescue64 /mnt/custom/sysrcd/rescue64

ln -s ../isolinux/altker32 /mnt/custom/sysrcd/altker32

ln -s ../isolinux/altker64 /mnt/custom/sysrcd/altker64

ln -s ../isolinux/initram.igz /mnt/custom/sysrcd/initram.igz


Weiter gehts mit Grub:

grub-install --no-floppy --root-directory=/mnt/custom /dev/sda


Damit sollte Grub und die richtige Map für den späteren Boot von Festplatte erstellt sein.

Nun erstellen wir mit Vim die grub.conf

vim /mnt/custom/boot/grub/grub.conf


und schreiben foglendes hinein:
default 0
timeout 5

title   SysRescCD
root    (hd0,0)
kernel  /sysrcd/altker64 subdir=sysrcd setkmap=de backstore=alldev
initrd  /sysrcd/initram.igz

Das Backstore Argument ist dabei vorweggegriffen. Was ein Backstore ist, darauf gehen wir gleich ein.

Damit Grub unsere grub.conf auch findet erstellen wir noch einen symbolischen Link:

ln -s grub.conf /mnt/custom/boot/grub/menu.lst

Jetzt muss noch der Backstore eingerichtet werden. Die Backstorefunktionalität dieser Distribution ist einer der Hauptgründe warum sie sich so gut für einen Rescueserver eignet. Es bedeutet, dass alle Änderungen die wir am System vornehmen in einer Änderungsdatei gespeichert werden. Damit ist und bleibt die komplette Installation statisch und kann ohne Datenverlust oder Konfigurationsaufwand geupdatet werden. Auch erleichtert es ungemein da debuggen. Wer genaueres zum Thema Backstore erfahren möchte, der sollte hier nachsehen:

http://www.sysresccd.org/news/2008/06/29/creating-a-backing-store-to-keep-your-modifications-in-sysresccd/

Die Backstoredatei wird mit folgendem Befehl, in einer Größe von 512 MB, erstellt und muss dabei ins Root-Verzeichnis, da ansonsten weitere Bootparameter fällig wären:

sysresccd-backstore create /mnt/custom/sysrcd.bs 512

Wer die Backstoredatei lieber auch im sysrcd-Ordner haben möchte, der findet in dem obigen Link die Informationen wie man das machen kann. Auch wenn man seine Backstoredatei zu klein angelegt hat ist ein vergrößern dieses Dateisystems problemlos möglich. Den Befehl dazu findet man auch in obigem Link.

Vorsicht, wenn man die Backstoredatei nicht richtig eingerichtet hat oder sie aus irgendeinem Grund nicht funktioniert, dann merkt man das nicht sofort. Man wundert sich dann nur, warum keine Änderungen die man gemacht hat nach einem Neustart noch da sind. Also nicht verzweifeln, sondern an die Backstoredatei denken!

Damit sollte der Rescueserver fertig installiert sein. Wir entfernen die CD und nach einem Reboot

shutdown -r now

sehen wir ob alles glatt ging und gehen zum nächsten Teil dieses Howtos über.

Einrichtung des Rescueservers

Wie dem wachsamen Auge bestimmt schon nach dem Neustart aufgefallen ist, läuft beim Booten ein aufwändiges Hardwareerkennungsscript, das uns auch gleich alle möglichen Konfigurationsdateien anlegt. Während dieses verhalten bei einer Live-CD wünschenswert ist - und auch später bei dem Live-OS, das auf dem zu rettenden System laufen wird - ist Dies auf unserem Rescueserver nicht erwünscht, da es uns z.B. unsere eigenen Konfigurationen die wir etwa für die Netzwerkanbindung machen, bei jedem Neustart verpfuscht.

Wir entfernen dieses Script mit:

rc-update del autoconfig

Außerdem erstellen wir ein root-Passwort mit dem wir uns über SSH einloggen können:

passwd

Netzwerkkonfiguration

Nun richten wir die Netzwerkkonfiguration ein. Wir gehen dabei aus, dass die zu verwendende Netzwerkkarte an eth0 gebunden ist. Wir setzen einen symbolischen Link auf ein vorhandendes und dafür zuständiges Init-Script

ln -s net.lo /etc/init.d/net.eth0

und schreiben uns eine /etc/conf.d/net

vim /etc/conf.d/net

mit folgendem Inhalt (sollte schon Inhalt vorhanden sein, muss dieser erst komplett entfernt werden),


config_eth0=( "xxx.xxx.xxx.xxx broadcast xxx.xxx.xxx.255 netmask 255.255.255.0" )
routes_eth0=( "default via xxx.xxx.xxx.xxx" )

wobei natürlich die X'e jeweils durch die IP des Servers und des entsprechenden Gateways auszutauschen sind. Wer Problene damit hat und weiterführende Informationen benötigt, der sollte in der Gentoo Dokumentation fündig werden.

Einen Nameserver brauchen wir auch noch (er hat meistens dieselbe IP wie das Gateway):

cat nameserver xxx.xxx.xxx.xxx > /etc/resolv.conf

Wir starten unseren Netzwerkservice

/etc/init.d/net.eth0 start

und wenn alles geht (vielleicht ein Test mit ping) fügen wir ihn dem Autostart hinzu:

rc-update add net.eth0 default

rc

Die PXE-Dienste

Um den PXE-Bootserver zu betreiben benötigen wir DHCP, TFTP und THTTP. In diesem Howto werden wir alle 3 Komponenten auf unserem einen Server betreiben. In der Praxis jedoch wird es wohl bei den Meisten so sein, dass nur TFTP und THTTP auf dem Rescueserver betrieben werden und der Rescueserver in eine bereits vorhandene DHCP-Infrastruktur eingebunden wird. Entsprechende Kenntnisse mit dhcpd vorrausgesetzt ist dies natürlich problemlos möglich.

Wir beginnen damit den DHCP-Server einzurichten:

vim /etc/dhcp/dhcpd.conf


# DHCP Server Configuration file.
# see /usr/share/doc/dhcp*/dhcpd.conf.sample

ddns-update-style interim;
ignore client-updates;

subnet xxx.xxx.xxx.0 netmask 255.255.255.0 {


option routers xxx.xxx.xxx.xxx;
option subnet-mask 255.255.255.0;
option domain-name-servers xxx.xxx.xxx.xxx;

# if we want to define an IP address for a mac address
host pxeclient {

hardware ethernet xx:xx:xx:xx:xx:xx:xx;
fixed-address xxx.xxx.xxx.xxx;

}

}


allow booting;
allow bootp;

next-server xxx.xxx.xxx.xxx; # IP addr of the TFTP server

class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
filename "/pxelinux.0";
}
Nun folgt der TFTP-Server:

vim /etc/conf.d/in.tftpd


# /etc/init.d/in.tftpd

# Path to server files from
INTFTPD_PATH="/tftpboot/"

# For more options, see in.tftpd(8)
# -R 4096:32767 solves problems with ARC firmware, and obsoletes
# the /proc/sys/net/ipv4/ip_local_port_range hack.
# -s causes $INTFTPD_PATH to be the root of the TFTP tree.
# -l is passed by the init script in addition to these options.
INTFTPD_OPTS="-R 4096:32767 -s ${INTFTPD_PATH}"
Als Letztes kommt der HTTP-Server:

vim /etc/conf.d/thttpd


# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License, v2 or later
# $Header: /var/cvsroot/gentoo-x86/www-servers/thttpd/files/thttpd-2.25/thttpd.confd,v 1.1 2004/08/08 18:34:03 stuart Exp $

## Config file for /etc/init.d/thttpd

## the startup-dir of thttpd is the docroot, so we specify it here
## and the init-script does a "cd" prior to startup:
THTTPD_DOCROOT="/mnt/cdrom"

## There are 2 ways to configure thttpd:
## 1) specify all params on the cmd-line
## 2) use a config-file (and start with "-C ")
## Note: 1) and 2) can be mixed.
##
## We choose 1) here -- if you have a more complicated setup read
## thttpd(8) for details on 2).
THTTPD_OPTS="-p 80 -u root -r -i /var/run/thttpd.pid -l /var/log/thttpd.log"

## For a more complex setup (e.g. cgi-support) use an external configfile:
## comment the THTTPD_OPTS line above und use the one below.
#THTTPD_OPTS="-C /etc/thttpd/thttpd.conf"

## If you know what you are doing you can add cgi-support with the line below;
## but you _should_ use the extern-configfile version!
#THTTPD_OPTS="$THTTPD_OPTS -c **.cgi|**.sh"
Wie man sehen kann, liegt der Konfigurationsaufwand beim DHCP-Server, der an die eigenen Bedürfnisse angepasst werden muss. Die anderen beiden sollten wohl für fast alle Zwecke so wie sie hier beschrieben sind korrekt konfiguriert sein.

Beim DHCP-Server ist es sehr wichtig, dass dieser die IP-Adressen an die PXE-bootenden Clients Anhand ihrer MAC-Adressen zuordnet, da es sonst zu Überschneidungen im Netzwerk kommen kann. Die IP-Adressen werden zwar nach wenigen Sekunden gleich wieder von PXELINUX, welches wir jetzt gleich behandeln werden, eingerichtet, aber auch diese wenigen Sekunden sind ein Konfigurationsfehler, der zu Ausfällen anderer Server im Netzwerk durch Überschneidung der IP-Adressen führen kann. Es ist also jedem zu empfehlen sich hier Gedanken über seine DHCP-Konfigurtion zu machen und an dieser Stelle nicht einfach nach dem Copy&Paste-Prinzip vorzugehen.

Also starten wir die Serverdienste

/etc/init.d/dhcpd start

/etc/init.d/in.tftpd start

/etc/init.d/thttpd start


und fügen sie dem Autostart hinzu:

rc-update add dhcpd default

rc-update add in.tftpd default

rc-update add thttpd default

rc


PXELINUX
Kommen wir zu PXELINUX. PXELINUX ist eine Art Bootloader. Nachdem Unser Client eine IP vom DHCP-Server bekommen hat, verbindet er sich zum TFTP-Server und fordert PXELINUX an. PXELINUX, wenn es dann geladen ist, fordert vom HTTP-Server das Betriebssystem an und lädt es in den RAM. Fertig geladen ist das Rescuesystem.

Unser Rescuesystem sollte eigentlich zu diesem Zeitpunkt schon funktionieren. Wenn wir einen Client in unserem Netzwerk im BIOS auf PXE-Boot einstellen sollte er erfolgreich eine statische Kopie von SysRescCD über das Netzwerk laden. Allerdings nur mit Standardkonfiguration.

Das Tolle hier ist aber, dass sich der komplette Bootprozess von PXELINUX nun hier mit einer einzigen Datei steuern lässt, die wir jetzt pxelinux.cfg nennen werden (auch wenn die Datei selbst gar nicht pxelinux.cfg heißt, aber das werden wir gleich verstehen).

Es gibt einen Ornder /tftpboot/pxelinux.cfg/ und in diesem Ordner ist momentan eine Datei enthalten, welche default heißt. Wir können dort jetzt aber weitere Dateien erstellen und diese nennen wir wie MAC-Adressen. Zum Beispiel:

/tftpboot/pxelinux.cfg/xx-xx-xx-xx-xx-xx-xx


Dies ist dann die Config-Datei, welche geladen wird, wenn der Client mit dieser entsprechenden MAC-Adresse darauf verbindet. Damit können wir innerhalb dieser Config-Datei die entsprechenden Config-Parameter speziell für diesen Server setzen, wie z.B. ein root-Passwort für das Rescuesystem, oder die Netzwerkkonfiguration. Hier ein Beispiel wie diese Datei in einem einfachen Fall aussehen kann (VORSICHT! Alles was hinter "append" steht, steht in einer Zeile!):
default rescue

timeout 10
prompt 1
display f1boot.msg
F1 f1boot.msg
F2 f2images.msg
F3 f3params.msg
F4 f4arun.msg
F5 f5troubl.msg
F6 f6pxe.msg
F7 f7net.msg

label rescue

kernel altker64
append scandelay=5 netboot=http://xxx.xxx.xxx.xxx/sysrcd.dat initrd=initram.igz setkmap=de eth0=xxx.xxx.xxx.xxx dns=xxx.xxx.xxx.xxx gateway=xxx.xxx.xxx.xxx rootpass=xxxxx

label diskboot

localboot 0x80

Die Option rootpass ist hierbei von besonderer Bedeutung, da wir ohne ein Rootpasswort nicht über SSH in unser System verbinden können.

Wie man sehen kann, ist diese Datei wie eine grub.conf aufgebaut. Das ist auch nicht verwunderlich, da es sich hier ja ebenfalls um einen Bootloader handelt. Wer genaueres zu den Bootparametern oder zur pxelinux.cfg braucht, der wird auf der Seite von SysRescCD fündig. Vor allem interessant hier ist eine Funktion, die sich Autorun nennt, auf die wir gleich noch eingehen werden.

Möglichkeiten
Nun da wir einen komplett funktionierenden Rescueserver haben erzähle ich noch eine Kleinigkeit über die Möglichkeiten die sich von hier aus bieten, falls der aufmerksame Leser bis jetzt noch nicht selbst darauf gekommen ist.

Wenn wir einen neuen Server in unser Netzwerk bekommen müssen wir lediglich diesen mit seiner MAC-Adresse und IP in die dhcpd.conf eintragen und eine pxelinux.cfg für dessen MAC-Adresse erstellen. Wenn es sich um ein großes oder professionelles Netzwerk handelt könnten wir z.B. ein kleines Webinterface machen, mit welchem man die pxelinux.cfg bearbeiten kann. Im Webinterface kann man dann zwischen den beiden labels "rescuesystem" und "bootfromdisk" hin und herschalten. Und schon ist das Rescuesystem für jeden Teilnehmer unseres Netzwerks steuerbar.

Desweiteren könnte man ein weiteres label hinzufügen, welches mit Hilfe der Autorun-Funktionalität ein Komplettbackup (welches wir z.B. in Verbindung mit LVM als LVM-Snapshot regelmäßig erstellen. Hierfür bietet sich hervorragend Tartarus an, damit man geprüfte und bewährte Scripts verwendet und nicht seinen eigenen fehleranfälligen Murks) von einem bestimmten Zeitpunkt wieder einspielt. Und das alles mit einem Mausklick vom Webinterface.

Abschied
Ich hoffe diese Anregungen gefallen. Es ist wirklich kein weiter oder komplizierter Weg mehr von hier aus solche Dinge umzusetzen.

Ich wünsche euch viel Spaß mit dem Rescuesystem (oder auch Backupsystem oder ...) und hoffe, dass keiner Schwierigkeiten hatte diesem Howto zu folgen.

Alles Gute und ein dickes Lob an den Suse-User, der es bis hier unten hin geschafft hat (vielleicht ist es Zeit für einen Umstieg?). ;-)

Grüße

Xel'Ra

1 Kommentar(e)

Zum Posten von Kommentaren bitte

Kommentare

Von: Manuel

Hallo,

sehr gutes HowTo.
Kleine Anmerkung, die Zeile
mount /dev/sda1 /dev/custom
sollte doch besser
mount /dev/sda1 /mnt/custom
heißen.

Und das zweite,
tftp sagt
recvfrom: Socket operation on non-socket
Sollte der tftp nicht vom InetD gestartet werden? Ansonsten muß man ihn mit Parameter -l starten.
IP bekomme ich beim Boot. Danach heißt es dann tftp open timeout

Ansonsten super dingen.

Grüße

Manuel