Open Source im professionellen Einsatz

Einfache Verwaltung von plattenlosen Linux-Clients mit Union-FS

Wurzelimport

, ,

Selbst betagte Rechner kommen als Diskless-Clients unter Linux dank transluzenter Dateisysteme und anderer Zutaten zu neuen Ehren - ersparen sie ihren Admins doch jede Menge Arbeit.

Wo Software auf eine so große Anzahl Clients zu verteilen ist, dass der Rundgang mit der Installations-CD von vornherein ausscheidet, bieten sich einige Alternativen an. Häufig fällt die Wahl auf eine Administrationssoftware, die Betriebssystem, Anwendungen und Updates aus einem zentralen Repository via Netzwerk und gegebenenfalls mittels Wake-on-LAN auf die Clients verbreitet. Dieses an sich recht übersichtliche Verfahren kann in der Praxis jedoch schnell zu einem Alptraum ausarten. Denn gerade dann, wenn sich die Konfiguration der Zielmaschinen sehr rasch ändert, stößt diese Herangehensweise bald an ihre Grenzen.

Doch Abhilfe ist möglich. In der Unix-Welt sind Diskless-Clients weit verbreitet, die ihren Kernel und auch das Wurzeldateisystem übers Netzwerk beziehen. Damit entfällt die Softwareverteilung, weil alle Programme auf einem zentralen Server bleiben. Hat der Client genügend eigene Rechenpower, kann er als so genannter Rich-Client lokal Applikationen ausführen. Bei Thin-Clients findet andernfalls auch die Datenverarbeitung komplett auf dem Server statt.

PXE ist Standard

Die Zeiten, in denen man für den Systemstart via Netzwerk Boot-ROMs für exotische Netzwerkkarten brennen oder zumindest eine Bootdiskette dabei haben musste, sind so gut wie vorbei: Intels PXE-Industriestandard steckt in fast jedem PC, der damit in der Lage ist, ohne ein lokales Bootmedium sein Betriebssystem zu starten.

Wenn die Voraussetzungen erfüllt sind, kann man das Bios so umkonfigurieren, dass der PC immer via Netzwerk bootet. Dazu bedarf es lediglich eines DHCP-Servers für die Vergabe der IP-Adresse und der Bootloader-Definition sowie eines TFTP-Servers, der den Client erst mit dem Bootloader und danach mit dem Linux-Kern versorgt (Abbildung 1). Oftmals ist mit dem DHCP-Server auch noch ein dynamischer DNS-Server (DDNS) verbunden, der den Namen des gerade gestarteten Clients nach einer erfolgreichen DHCP-Adressenvergabe in den DNS-Dienst einträgt [1].

Abbildung 1: So bootet ein zustandsloser Client unter Mithilfe seiner Server.

Abbildung 1: So bootet ein zustandsloser Client unter Mithilfe seiner Server.

Hat der Linux-Kern auf der Clientmaschine seinen Dienst aufgenommen, verlangt er die Wurzel eines Dateisystems, um den Urprozess, meist »init«, starten zu können. Im Fall des Diskless-Clients ist dies natürlich ein Netzwerk-Dateisystem, genauer gesagt NFS, denn etwas anderes wird vom Linux-Kern an dieser Stelle nicht unterstützt. Zusätzlich müssen einige Kerneloptionen korrekt eingestellt sein [2].

Komplexität begrenzen

Beruht das Konzept einer derartigen Systemlandschaft auf plattenlosen Clients, ist eine der Randbedingungen, dass die Komplexität nicht beliebig steigen darf. Stattdessen sollen Standardlösungen den Administratoren das Leben erleichtern. Das hier vorgestellte Beispiel verwendet aus diesem Grund eine unmodifizierte Linux-Distribution, komplizierte Anpassungen entfallen. Ein Update der eingesetzten Software zieht also nicht die Anpassung einer Unzahl von Skripten nach sich. Zusätzlich gestaltet sich auch die Installation von Diskfull- und Diskless- Clients gleich.

Als Distribution für Server und Clients kommt Gentoo zum Einsatz. Die Installation eines Diskfull-Systems geschieht dort über eine »chroot()«-Umgebung, was auch beim Diskless-Client passt. Änderungen an den Start-Stop-Skripten können unterbleiben, damit geht der Admin möglichen Problemen bei einem Upgrade von vornherein aus dem Weg. Anzupassen sind nur Skripte, die zu Applikationen gehören, die der Anwender außerhalb der Gentoo-Paketverwaltung Portage installiert hat.

In einem Gentoo-Server sind die erforderlichen Dienste mit wenigen Kommandos schnell aufgesetzt:

emerge net-misc/dhcp
emerge net-ftp/tftp-hpa
emerge net-fs/nfs-utils


Die Konfiguration des DHCP-Servers ist in [3] nachzulesen. Listing 1 enthält ein entsprechendes Beispiel, die »subnet«-Blöcke sind jeweils den lokalen Gegebenheiten anzupassen. Die entscheidenden Optionen heißen »next-server« und »filename«. Die Option »next-server« bezeichnet den TFTP-Server. Im Beispiel ist dies derselbe Server, was aber nicht so sein muss.

Listing 1:
»/etc/dhcp/dhcpd.conf«

01 allow unknown-clients;
02 default-lease-time 1800;                # 30 minutes
03 max-lease-time 7200;                    # 2 hours
04 
05 subnet 192.168.39.0 netmask 255.255.255.0 {
06     range 192.168.39.128 192.168.39.254;
07     option broadcast-address 192.168.39.255;
08     option domain-name-servers 192.168.39.1;
09     option domain-name "localdomain";
10     next-server 192.168.39.10;
11     filename "gentoo_A/boot/pxelinux.0";
12 }

Diesen Artikel als PDF kaufen

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook