Plattenlose Clients auf Basis von Linux bieten die Möglichkeiten vollwertiger klassischer Workstations bei reduzierten Hardwarekosten, geringerem Lärmpegel sowie vermindertem Administrationsaufwand. Bei Standard-PC-Komponenten sinken die Kosten weiter.

IT-Umgebungen, die wenig Personal binden und das Softwarebudget wenig belasten, erfreuen sich steigender Beliebtheit. Einen guten Ansatz zur Vereinheitlichung und Automatisierung bilden Thin Clients [4]. Dieser Rechnertyp senkt die Kosten durch Reduktion der Hardware und durch Zentralisierung.

Mit Linux als Betriebssystem erhalten solche Plattformen zudem eine solide und flexible Softwarebasis zu sehr niedrigen Kosten. Solche Clients sind auch nicht auf Spezialhardware angewiesen, sondern mit klassischer PC-Hardware realisierbar. Je nach Anwendung fallen die Anforderungen so niedrig aus, dass auch ältere Pentium-Rechner noch eine sinnvolle Weiterverwendung finden. Die Voraussetzung für den performanten Betrieb von Diskless Clients – eine leistungsfähige Ethernet-Installation – ist üblicherweise gegeben.

Das Know-how und die Programme für einen Betrieb von Linux Diskless Clients (LDC) stellt dieser Beitrag vor. Einige Grundlagen und frühere Entwicklungen lassen sich zum Beispiel[1] entnehmen, unter[9] finden sich im Netz Informationen, Beispiele und Ergänzungen. Praktisch umgesetzt wird das Wissen aus diesem Beitrag in der mathematischen Fakultät der Universität Göttingen beim Betrieb eines Übungsraums und von Dozenten-Arbeitsplätzen sowie am Gymnasium Remigianum in Borken zur Ausstattung eines Lehr-PC-Pools.

Protokolle und Technologien

Diskless Clients booten meist über ein ROM. Das bringt zwei Vorteile zugleich: Erstens ist die Wahrscheinlichkeit des Ausfalls einer wichtigen (Hardware-) Komponente niedrig. Zweitens erfolgt die Administration ausschließlich auf dem Server. Die benutzte Boot-ROM-Implementation Etherboot[7] ist ein schönes Beispiel für ein GPL-Tool.

Mit dem Pre-Execution Environment (PXE), einer Komponente von Intels Wired for Management (WfM), vereinheitlichen die Hersteller von Netzwerk-Hardware die Software für den LAN-basierten Rechnerstart. Beide verwenden zur Beschaffung der IP-Grundkonfiguration das Dynamic Host Configuration Protocol (DHCP), das den weiteren Startvorgang der Linux-basierten Clients steuert. Zur Übertragung des Betriebssystemkerns dient das Trivial File Transfer Protocol (TFTP), wobei Etherboot alternativ das Network File System (NFS) verwenden kann. DHCP, TFTP und NFS basieren auf UDP.

Neben dem Netzwerk-Dateisystem benötigen Diskless Clients ein beschreibbares Filesystem, das die dynamischen Daten aufnimmt. Die Wahl fiel auf das TEMPFS, dessen Größe sich dynamisch an die abgelegte Datenmenge anpasst. Alternativ käme auch die betagte RAM-Disk in Frage. Ideal wäre ein transparentes Dateisystem wie das Translucent File System (TFS) in Sun OS 4.x, das es für Linux aber nicht gibt. Inzwischen gibt es einen Erfolg versprechenden Ansatz eines Translucent FS für Linux von Bernhard M. Wiedermann[11]. Die Dateisystemstruktur würde sich so besonders für Konfigurationsdateien vereinfachen.

Der übers Netzwerk kopierte Bootkernel benötigt spezielle Einstellungen, um zu starten. Etherboot liefert hierzu ein Tool für das so genannte Kernel-Tagging mit. PXE in Verbindung mit Etherboot nutzt dabei dessen Fähigkeiten oder bietet zusammen mit dem Syslinux-Bootloader eine alternative Strategie an (siehe Abschnitt “Syslinux und PXE”).

Die Client-Bootsoftware

Ziel bei der Wahl einer geeigneten Bootsoftware ist, dass keine Spezialhardware erforderlich ist. Die Software sollte nach dem Anschalten des Geräts ohne besondere Benutzerinteraktion und zügig bereitstehen. Denkbar sind zudem besondere Features, so könnte ein Bootmenü den Start von Diskette anbieten.

Auch sind Verkettungen möglich: Schlägt zum Beispiel das Booten aus dem Netzwerk fehl, sucht die Startsoftware auf weiteren Devices nach Bootblöcken. Alle Ansätze sollten sich aus Sicht des Servers möglichst gleich verhalten, um den Aufwand für Anpassungen gering zu halten. Das betrifft verschieden getaggte Kernel für Etherboot, PXE/Syslinux (siehe weiter unten) und die kommerziellen Boot-ROMs gleichermaßen.

Etherboot – das freie Boot-ROM-Paket

Das Etherboot-Paket[7] enthält die Treiber für fast alle gängigen Netzwerkkarten, auch für Gigabit- und Wireless-Adapter. Es unterstützt die Zusammenarbeit mit anderen Bootloadern, Dual-Boot-Lösungen und Bootmenüs. Wegen seiner GPL-Lizenz darf Etherboot auf beliebig vielen Installation laufen, ohne dass Gebühren fällig werden.

Die aus dem Etherboot-Paket kompilierten Bootimages sind so kompakt, dass sie in übliche EPROMs und Flash-ROMs für Netzwerkkarten Platz finden. Einzukalkulieren ist allerdings, dass jeder Zusatz, zum Beispiel die NFS als Kerneltransfer-Protokoll, den Umfang aufbläht und dabei kleine EPROMs oder alte ISA-Netzwerkkarten überfordert. Alternativ darf der Code als Extension-ROM dem BIOS des Mainboards hinzugefügt werden. (DOS-)Programme wie »cbrom.exe« für Phoenix/Award- und »amibcp.exe« für AMI-BIOSe nehmen die Modifikationen vor (siehe Kasten “BIOS-Spezial- tools”). Die Bootimages belegen zwischen 8 und 64 KByte. Im Code enthalten sind der Treiber für die Netzwerkkarte und die Protokolle DHCP und TFTP beziehungsweise NFS.

Abbildung 1: Ablauf des Bootvorgangs eines Linux-Diskless-Clients in den beiden Ausprägungen Etherboot und PXE.

Dank der offenen Quellen sind die Aussichten für eigene Anpassungen an spezielle Netzwerke gut. Interessant ist die Etherboot-Fähigkeit, Clients zeitweise statt per Netzwerk auch von Festplatte, Diskette oder CD-ROM-Laufwerk booten zu lassen, was Bootserver-Ausfälle überbrücken hilft. Auch die Lilo-Alternative Grub (Grand Unified Bootloader) hat ein Modul für Etherboot. Gut fürs Testen und Debuggen ist, dass Etherboot sowohl ausführbare DOS-Dateien erzeugen als auch direkt in den Bootsektor einer Diskette schreiben kann.

Etherboot-Einstellungen

Etherboot bekommt seine Optionen in der sich selbst dokumentierenden Datei »Config« im Source-Verzeichnis mitgeteilt. Details enthält die umfangreiche Dokumentation, die jedoch als separates Paket von der Entwickler-Seite[7] geladen werden will. Art und Menge der gewählten Optionen bestimmen den Umfang des späteren ROM-Image. In EPROM-Chips passen zwischen 128 und 512 KBit; BIOS-Flash-ROMs müssen über entsprechend freien Platz verfügen.

Über die Konfigurationsdatei steuert der Administrator auch, wie das Kernelimage zu laden ist. Die aktuelle Etherboot-Implementierung kann dabei statt TFTP auch NFS verwenden, das später sowieso für das Root-Filesystem des Clients gebraucht wird. Ein Server-seitiger Dienst weniger erhöht zudem die Systemsicherheit. Andererseits vergrößert die NFS-Unterstützung den erzeugten ROM-Code um einige KByte.

Abbildung 2: Etherboot startet aus einem Disketten-Image: Es erkennt und initialisiert die Netzwerkkarte anhand ihrer PCI- und Vendor-ID und startet DHCP.

Wer die Bootauswahl-Meldung (Starten vom Netz oder von einem lokalen Device) ändern will, darf sich an der Datei »etherboot.h« zu schaffen machen, die im selben Verzeichnis wie die Konfigurationsdatei liegt. Soll sich Etherboot mit einem anderen Vendor-Code-Identifier-String als dem eingestelltem »Etherboot« gegenüber dem DHCP-Server melden, ist die Datei »main.c« anzupassen. Beide genannten Möglichkeiten muss der Administrator zusätzlich in der zentralen Konfigurationsdatei aktivieren.

BIOS-Spezialtools

Der Etherboot-Code wird als Extension-ROM dem BIOS des jeweiligen Mainboards mit Spezialtools hinzugefügt. Die (DOS-)Tools sind eigentlich für Mainboard-Hersteller gedacht, um dem Standard-BIOS die Firmware für IDE- oder SCSI-Controller, Antivirus-Software und so weiter hinzuzufügen. Etherboot ist eine solche Erweiterung. Eine gewisse Vorsicht ist jedoch angebracht, da bei falschem BIOS-Inhalt ein Totalausfall des Mainboards droht. Umsicht und ein in Reserve gehaltener Flash-Baustein mit dem Original-BIOS machen Fehlschläge aber unwahrscheinlich. Die beiden im Folgenden beschriebenen Tools operieren direkt auf dem Flash-Baustein. Deshalb benötigt man das Image des BIOS als Datei – die üblichen Flash-Programme beherrschen diese Arbeit ebenso wie das spätere Zurückschreiben. Award- und Phoenix-BIOS Der Aufruf des kommandozeilenorientierten »cbrom.exe« ohne Parameter zeigt alle seine Optionen an. »cbrom bios.bin /d« ermittelt den freien, also für eigenen Code nutzbaren Platz im ROM-File. Das BIOS im Flash-ROM ist von Haus aus komprimiert; Cbrom staucht seinen erzeugten Code darum auch. Etherboot benötigt 8 bis 20 KByte freien Speicherplatz. Ist nicht genügend vorhanden, entfernt »cbrom bios.bin /[pci|ncr|logo|isa] release« entbehrliche BIOS-Komponenten – das Logo des Herstellers oder den Symbios/NCR-SCSI-Code brauchen festplattenlose Systeme beispielsweise nicht. Das Kommando »cbrom bios.bin /[pci|isa] bootimg.rom [ D000:0]« fügt den kompilierten Etherboot-Code dem BIOS hinzu. » bootimg. rom« ist der Code, den man sonst in ein EPROM brennen würde. Die Option »[pci|isa]« hängt von der Netzwerkkarte ab. ISA-Karten gibt Cbrom die Speicheradresse mit, an die der Code während des Bootvorgangs kopiert wird. AMI-BIOS Das AMI-Tool »amibcp.exe« ist im Gegensatz zu »cbrom.exe« interaktiv per Menü bedienbar: Man startet es ohne Kommandozeilenparameter und lädt das BIOS-File über den ersten Menüpunkt »Load BIOS from Disk File«. Bearbeitet wird das BIOS über »Edit BIOS Modules«. Der untere Bildschirmrand zeigt den noch verfügbaren Speicher für Erweiterungen. Mit der [Ins]-Taste setzt der Bediener Zusatzmodule ein, am besten mit »compressed«. Per [Esc] verlässt man den Edit-Bereich und ein »Save BIOS File to Disk« speichert das veränderte BIOS in eine Datei. Abbildung 3: Cbrom analysiert das BIOS des Abit-Mainboards BP6. Der freie Speicherplatz reicht locker aus, um noch den Etherboot-Code als »PCI driver [B]« einzufügen.

Kompilieren des ROM-Codes

Zur Erzeugung der »*.rom«-Images genügt der Aufruf von »make« im Quellverzeichnis. Die Images wandern dabei ins Unterverzeichnis »bin32«. Sinnvoll ist es, erste Tests der Bootimages von einer Bootdiskette zu fahren. Der Aufruf von »make bin32/ Name_der_Netzwerkkarte .fd0« erzeugt ein ROM-Image mit vorgeschaltetem Disketten-Bootheader für »/dev/fd0«.

Aufmerksamen Zeitgenossen bietet der »make«-Aufruf zudem die Chance, ihn beim Schreiben des ROM-Image auf Diskette mit einem einfachen »cat« zu beobachten. Das Nachahmen spart den Umweg über »make«. Auf analoge Weise werden PXE-Images erzeugt, die später die Bootsoftware der Clients lädt.

Mknbi baut Bootimages

Das Perl-Skript »mknbi-linux« vermag nicht nur Bootimages für Linux zu erzeugen, sondern auch für andere Betriebssysteme, zum Beispiel DOS. Hilfe dazu gibt es per »man mknbi«. Das Kernel-Tagging geschieht zum Beispiel mit: »mknbi -o Bootimage -d /nfsroot/dxs -ip rom Kernelimage [ Ramdiskimage]«.

Die Optionen geben nacheinander das Kernelfile, das Outputfile (der netzbootfähige Kernel) und das NFS-Root an. Die letzte Option veranlasst den Kernel dazu, seine IP-Konfiguration über die DHCP/BOOTP-Anfrage des Boot-ROMs zu beziehen. Das diesem Beitrag zugrunde liegende Projekt benötigt diese Option jedoch nicht, da die DHCP-Anfrage aus der INITTAR-Umgebung[12] heraus erfolgt.

Syslinux und PXE

PXE ist ein weiterer Mechanismus, um übers Netz eine plattenlose Maschine zu starten. Einigen Netzwerkkarten und Kompakt-Mainboards ist PXE bereits implementiert. PXE Linux von Peter Anvin wird mit dem Syslinux-Paket[10] verteilt. Syslinux stellt eine Art erweiterten »loadlin« (einen Second Stage Bootloader) bereit, der zusammen mit PXE einen Linux-Kernel mit Optionen und einer RAM-Disk mit TFTP lädt. Ebenso könnten Images der Bootsektoren anderer Betriebssysteme zur Wahl stehen – und schon ist ein netzgesteuertes Multiboot geboren.

PXE-Linux beschafft die Kernel-Bootinformationen aus einer Datei im Verzeichnis »pxelinux.cfg/« auf dem Server, deren Name sich aus der hexadezimalen Repräsentation der IP-Adresse des Clients zusammensetzt. Existiert eine solche Datei nicht, entfernt PXE Linux sukzessive von rechts beginnend Zeichen und vergleicht erneut. Bleibt auch das erfolglos, greift es auf eine Default-Konfigurationsdatei zurück.

PXE funktioniert auch gemeinsam mit Etherboot. In diesem Fall wird ein Kettenstart ausgeführt: Zuerst aktiviert sich PXE, das dann ein auf PXE zugeschnittenes Etherboot lädt, das wiederum den Bootvorgang weiterführt. Die Kombination erweist sich immer dann als hilfreich, wenn PXE schon vorhanden und ein Eingriff in die bestehende Hard- und Software nicht erwünscht ist. Man benötigt nur einen für Etherboot aufbereiteten Kernel und spart sich das getrennte Bereitstellen von Bootkernels. Voraussetzung ist jedoch ein aufwändig konfigurierter DHCP-Server, der zuerst die PXE-Anfrage und anschließend Etherboot mit den korrekten Daten versorgt. Ein gutes Howto gibt es unter[5].

# For prompting ...
CFLAGS32+=     -DMOTD -DIMAGE_MENU
# [...]
# Change download protocol to NFS, default is TFTP
CFLAGS32+=     -DDOWNLOAD_PROTO_NFS
# For prompting and default on timeout
CFLAGS32+=     -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
# [...]
# Enabling this makes the boot ROM require a Vendor Class
# Identifier of "Etherboot" in the Vendor Encapsulated Options
CFLAGS32+=     -DREQUIRE_VCI_ETHERBOOT

DHCP – Das zentrale Konfigurationswerkzeug

Das Dynamic Host Configuration Protocol (DHCP,[1]) ist ein Netzwerkprotokoll, das für den vorliegenden Fall die Daten zur Konfiguration eines Clientsystems überträgt: Hostname, IP-Adresse, Netzmaske, Gateway, aber auch Server-IPs (Time-, Swap-, NIS- und Druckserver). In Menu- und Motd-Optionen sind zudem Parameter für die Boot-ROM-Software Etherboot sendbar.

Die Konfigurationsdatei des DHCP- Daemon »/etc/dhcpd.conf« sollte der Administrator sinnvoll strukturieren. Neben dem »subnet«-Statement helfen »group« und die Unterteilung in Subnetze dabei, die Konfigurationsblöcke mit gleichen Parametern zusammenzufassen. Eine Konfiguration könnte etwa wie Listing 2 aussehen.

01 option domain-name "math.uni-goettingen.de goe.net gwdg.de";
02 filename "/nfsroot/bootimg";
03 use-host-decl-names on;
04 default-lease-time 72000;
05 max-lease-time 144000;
06 subnet 134.76.60.0 netmask 255.255.252.0 {
07 option domain-name-servers 134.76.60.21, 134.76.60.100;
08 option ntp-servers ntps1.gwdg.de, ntps2.gwdg.de;
09 option font-servers dionysos.stud.uni-goettingen.de;
10 option x-display-manager s4, s5, s6, s9, s10, s11, s12;
11 option routers 134.76.63.254;
12 option broadcast-address 134.76.63.255;
13        class "PXEClient:" {
14        match if substring (option vendor-class-identifier, 
15                           0, 10) = "PXEClient:";
16        filename "/nfsroot/dxs/boot/3c905c-tpo.pxe"; }
17 group {
18        option lpr-servers 134.76.60.2;
19               host dxs02 {
20        hardware ethernet 00:00:1C:D2:87:DF;
21        fixed-address 134.76.60.64; ''
22 #...

DHCP erlaubt es, so genannte Vendor-Optionen (also zusätzliche) aufzunehmen. Hierfür steht der Codenummernbereich von 128 bis 255 bereit. Von ihnen macht das Listing 3 reichlich Gebrauch. Folgende Grund-Variablentypen sind verwendbar: »string«, »integer«, »boolean«, »text«, »ip-number«. Alle sind auch zu Arrays kombinierbar.

Admins, die ahnen, dass viele Konfigurationsdaten zu übermitteln sind, sollten die Paketgröße des BOOTP-Reply-Pakets über den Standard (572 Byte) hinaus auf 1024 Byte erhöhen: »dhcp-max-message-size 1024«. Diese Optionen werden zu Beginn der Konfigurationsdateien für den Server-Daemon sowie den Client (»dhclient«) definiert. Das Listing 3 ist mehr als Beispiel, weniger als vollständige Aufzählung zu verstehen.

01 # -- lot of information to be transferred --
02 dhcp-max-message-size 1024;
03 # -- user defined options --
04 option o128 code 128              = string;
05 option o129 code 129              = string;
06 option menudflts code 160         = string;
07 option motdline1 code 184         = string;
08 option menuline1 code 192         = string;
09 option menuline2 code 193         = string;
10 option menuline3 code 194         = string;
11 option start-x code 223           = string;
12 option start-snmp code 224        = string;
13 option start-sshd code 225        = string;
14 option start-xdmcp code 226       = string;
15 option start-cron code 227        = string;

Die Option »128« definiert ein Magic Packet, das die Auswertung von Menu-Optionen für Etherboot einschaltet. Standardwerte für die Menü-Auswahl, also dafür, welches Feld nach dem Timeout startet, legt die Option »160« fest. Die Zusammensetzung des Menüs, das Etherboot nach dem Kontakt mit dem DHCP-Server angezeigt, geschieht durch »192« und folgende.

Die Optionen ab »223« (ein willkürlich gewähltes, nicht vergebenes Feld) definieren Variablen zur Konfiguration der Diskless Clients. Im gezeigten Fall, ob ein Dienst gestartet werden soll oder nicht. Das bietet in heterogenen Umgebungen die Möglichkeit an, nicht alle Clients über einen Kamm zu scheren.

Vendor-Code-Identifier sind als feste Optionen für DHCP definiert: »vendor-class-identifier« für die Identifizierung des Clients durch den Server und »vendor-encapsulated-options« zur Server-Identifizierung seitens des Clients. Auf diese Weise kann der Server die Clients voneinander unterscheiden und verschiedene Werte für die gleiche Option zurückliefern.

Das ist sogar zwingend notwendig, wenn PXE und Etherboot verkettet booten. Denn PXE erhält zwar die identische IP-Konfiguration, lädt aber anstelle des Kernelimage das Etherboot-PXE-Image. Das im Beispiel gezeigte »class«-Statement hilft dabei, eine solche Unterscheidung vorzunehmen. Erkennt der Code eine PXE-Implementation auf einer speziellen 3COM-Karte, wechselt der Inhalt des DHCP-Felds »file«.

Client-seitige Konfiguration

Das Kommando »dhclient« stellt den Dienst zur Client-seitigen Konfiguration bereit, also den dynamischen Bezug einer IP-Adresse mit Linux. Die Konfiguration sollte passend zum DHCP-Server erfolgen. Die Eintragung beziehungsweise Anwendung der Information geschieht mittels »dhclient-script«. Die Ausschnitte aus dem »dhclient-script« (Listing 5) zeigen die Zusammenarbeit mit dem DHCP. Variablen werden interpretiert und in Konfigurationen umgesetzt oder entsprechende Dateien geschrieben. Das ist etwa mit den Bootskripten des System-V-Init vergleichbar.

Listing 5 ist unverkennbar ein Bash-Skript, andere Skriptsprachen wären ebenso möglich. Wichtig ist lediglich die Abstimmung der Informationskette: DHCP-Server -> DHCP-Client -> Skript -> Konfigurationsdatei/Service. Jede Erweiterung der An- oder Abwahl von Optionen geschieht entlang dieses Pfades.

Aufteilung und Dateisysteme

Das Filsystem, speziell das Root-Filesystem eines Clients ohne eigenen Festspeicher weicht zwangsläufig von dem gewohnter Festplatteninstallationen ab. Eine große Zahl von Maschinen mit unterschiedlichen Funktionen und verschiedener Ausstattung wird aus einem einheitlichen Verzeichnis bedient. Das wirkt zudem günstig auf das Caching-Verhalten des Servers.

Besitzt die Servermaschine das gleiche Betriebssystem auf gleicher Prozessorarchitektur, lassen sich Teile ihres Filesystems für die Clients einbinden. Das erlaubt es sogar, die Softwareverwaltung Server-seitig zu zentralisieren. Jedoch muss bei lizenzpflichtiger Software an entsprechende Vorkehrungen gedacht werden, da sie über mehrere Thin Clients verteilt wird. Nur die Teile des Server-Filesystems für Konfigurationsdateien sowie Temporärverzeichnisse mit Sockets für XFree86, MySQL und andere gibt der Server seinen Clients nicht frei. Gleiches gilt für sicherheitsrelevante Teile.

Der Filesystemhierarchie-Standard für freie Unix-Betriebssysteme ordnet den Dateibaum nach den Kriterien in Tabelle 1. Damit erhält man die NFS-Exportmöglichkeiten in einer Art Matrix wie in Tabelle 2. Dynamische Daten wie Konfigurationsdateien, Logfiles und Sockets hält der Client im Speicher (TEMPFS, RAMFS oder RAM-Disk).

Nicht alles in die RAM-Disk

Da man nicht alle problematischen Bereiche pauschal in die RAM-Disk legen kann, sind feine Abstimmungen durch Einzelfreigaben und Symlinks unumgänglich. Die Verzeichnisse mit den Standardapplikationen »/opt« und »/usr« lassen sich generell unproblematisch im Nur-lesen-Zugriff freigeben.

Das Spezialverzeichnis »/dev« wird nicht exportiert, wenn man auf den Device-Filesystem-Daemon setzt. Andernfalls wäre es, wie auch »/etc« und »/var«, in der RAM-Disk des Clients anzusiedeln. Unter diesen Bedingungen sieht die Aufteilung für den Verzeichnis-Export per NFS wie im Listing 6 aus.

Aufsetzen des Dateisystems

Ausgehend von gleicher Prozessorarchitektur und ähnlicher Software-Ausstattung von Client und Server, steht nun die Aufgabe an, das Root-Filesystem der Clients zu extrahieren, am besten per Shellskript: Es erzeugt zuerst die komplette Verzeichnisstruktur, in die entweder Teile des Server-Dateisystems kopiert oder während der Initialisierungsphase gemountet werden.

Weiterhin kopiert oder verlinkt das Skript alle notwendigen Programme und Basisbibliotheken aus den Verzeichnissen »/lib«, »/bin« und »/sbin«. Liegt das Client-Root-Filesystem auf einer separaten Partition des Servers, werden die Dateien kopiert, im anderen Falle hart verlinkt (Softlinks sind nicht NFS-transparent). Hardlinks bewirken zudem das wünschenswerte Verhalten, dass Änderungen am Server-Dateisystem sich sofort auf die Clients auswirken. Vorsicht ist jedoch bei Hardlinks ebenfalls geboten, da sich infolge Updates Inode-Einträge ändern könnten.

01 # /etc/dhclient.conf
02 send dhcp-max-message-size 1024;
03 send dhcp-lease-time 3600;
04 request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name;
05 require subnet-mask, domain-name-servers;
06 timeout 40;
07 retry 40;
08 reboot 10;
09 select-timeout 5;
10 initial-interval 2;
11 script "/sbin/dhclient-script";

01 # dhclient-script
02 #...
03 # set up snmpd configuration
04 test -n "$new_start_snmp" &&                              
05 sed -e "s,NETADDR/MASK,$netaddr/$new_subnet_mask,g"       
06     /etc/ucdsnmpd.conf.default >/etc/ucdsnmpd.conf
07 #...
08 sed -e "s,KEYTABLE=.*,KEYTABLE="$LANG",i"               
09     -e "s,START_GPM=.*,START_GPM=$start_gpm,i"            
10     -e "s,GPM_.*,GPM_PARAM="-t $MP -m $MD",i"           
11     -e "s,START_X=.*,START_X="$new_start_x",i"          
12     -e "s,START_SNMP.*,START_SNMPD=$new_start_snmp,i"     
13     -e "s,START_SSHD.*,START_SSHD=$new_start_sshd,i"      
14     -e "s,DISPLAYM.*,DISPLAYMANAGER=$new_start_xdmcp,i"   
15     -e "s,DEFAULT_WM.*,DEFAULT_WM="$defaultwm",i"       
16     -e "s,CRON.*,CRON="$new_start_cron",i"              
17     -e "s,START_RWHOD.*,START_RWHOD=$new_start_rwhod,i"   
18     -e "s,START_LPD.*,START_LPD="$start_lpd",i"         
19     -e "s,START_CUPS.*,START_CUPS="$start_cups",i"      
20     -e "s,START_YPBIND.*,START_YPBIND="$start_nis",i"   
21     -e "s,START_XNTPD.*,START_XNTPD="$start_xntp",i"    
22     -e "s,XNTPD_I.*,XNTPD_INITIAL_NTPDATE="$initntp",i" 
23     -e "s,VMWARE.*,VMWARE="$new_start_vmkernel",i"      
24     /etc/rc.config.default | grep -v "#" >/etc/rc.config;
25 #...

In fast jedem Bereich ist jedoch darauf zu achten, dass spezielle Verzeichnisse wie »/lib/modules«, die maschinenspezifisch sind, nicht einfach kopiert, sondern mit den entsprechenden Daten für die Thin Clients gefüllt werden. Gleiches gilt für manche Dateien in »/var« und »/etc«: Maschinen- und IP-spezifische Dateien wie »hosts«, »resolv.conf«, »HOSTNAME«, »fstab« und so weiter gehören in die RAM-Disk. Andere Bereiche, zum Beispiel das für alle Clients gleiche und umfangreiche Verzeichnis »/etc/opt«, bindet der Client vom Server wiederum (gemeinsam mit dem Root- Filesystem) per NFS ein.

Bei der Aufteilung der einzelnen Dateien und Verzeichnisse kommt es auf die konkreten Erfordernisse an. Starke Reduktion des RAM-Disk-Anteils bedeutet höheren Aufwand bei der Aufteilung. Das Beispiel teilt das Konfigurationsverzeichnis »/etc« in einen statischen Teil »/etc.s« und einen RAM-Disk-Teil »/RAM/etc« auf. Ersterer wird vom Server read-only exportiert. Der Rest ist bereits Bestandteil des INITTAR und wird per Link auf »/etc« abgebildet, er enthält für alle statischen Elemente Links nach »/etc.s«. Mit einem transluzenten Filesystem wäre der Aufwand des häufigen Querverlinkens vermeidbar. [11]

Das INITTAR

Die Init-RD (Initial RAM-Disk) ist nicht nur unhandlich und unflexibel, sondern seit Einführung des TEMPFS auch überflüssig. So funktioniert es:

• Mounten eines leeren TEMPFS als Root-Filesystem.
• Auspacken eines Tar.gz-Image, das dem Kernel auf dem gleichen
  Weg mitgegeben wird wie per Init-RD.
• Starten des »init«-(Ersatz-)Skripts.

INITTAR ist nicht mehr auf eine fixe Größe festgelegt und muss nicht mit einem Dateisystem formatiert werden. Das Erstellen eines Tar-Files mit Gzip-Komprimierung genügt. Für TEMPFS ist ein Kernelpatch mit Neu-Übersetzung des Kernels erforderlich. [12]

Zweiteilige Boot-Prozedur

Die Initialisierung des vorgestellten Linux Diskless Clients erfolgt analog zum Kernelstart neuerer Linux-Distributionen. Vor dem Mounten des Root-Filesystems startet die beschriebene minimale RAM-Disk-Umgebung. Sie übernimmt Konfigurationsaufgaben, etwa das Laden der Kernelmodule für Dateisysteme oder RAID-Festplatten. Die Zweiteilung der Boot-Prozedur vereinfacht Kernel und Fehlersuche. Nur die für den Start erforderlichen Elemente sind fest im Kernel verankert, alle weiteren werden bei Bedarf nachgeladen.

Dazu wird statt »init« jenes Shellskript ausgeführt, das zuvor das Netzwerkkarten-Kernelmodul ermittelt und geladen hatte. »dhclient« beschafft IP- und weitere Konfigurationsdaten. »dhclient-script« übernimmt die IP-Konfiguration, das Mounten und Zusammensetzen des Dateisystems und das Schreiben der Konfigurationsdateien. Danach übergibt »dhclient-script« die Kontrolle wieder an »init«, das das RAM-Disk-Filesystem nach »/RAM« und die gemounteten Root-Filesystemteile auf die oberste Verzeichnisebene »/« umhängt.

Zuletzt startet aus dem neuen Root-Filesystem das herkömmliche »init« – die Initialisierung ist beendet. Genau dann startet die gewohnte Boot-Prozedur mit ihrem Runlevel-System (Sys-V-Init unterhalb des Verzeichnisses »/etc/init.d«).

Nicht ganz einfach: Fehler suchen

Auf festplattenlosen Systemen muss die Netzwerkkonfiguration stehen, bevor ein Logservice auf dem Client funktioniert. Das gestaltet die Fehlersuche etwas komplizierter als gewohnt. Aber schon das Server-Logfile liefert erste Hinweise. Ein Teil der Fehlersuche – gerade bei der XFree86-Konfiguration – kann remote erfolgen, wenn auf dem Client der Secure-Shell-Daemon »sshd« läuft.

Fürs Debugging der ersten Bootschritte sollten die Start- und Konfigurationsskripte über Debug-Meldungen verfügen, die bei jedem fehlgeschlagenen Befehl die Ursache angeben und Maßnahmen zur Abhilfe erläutern. Weitere Informationen liefert eine Logdatei, die den Bootvorgang und die Einrichtung der Hard- und Software protokolliert.

Fazit

Diskless Clients erfordern gegenüber der klassischen Workstation einen erhöhten Einrichtungsaufwand, der sich aber bereits bei einen kleinen Anzahl gleichartiger Arbeitsplätze lohnt. Die hier präsentierte Lösung skaliert besonders gut. Die Lade- und Reaktionszeiten der Clients liegen – je nach Hardware, Bandbreite des Netzwerks und Server-Dimensionierung – noch unter denen vergleichbarer Stand-alone-Workstations.

Die offene Software-Architektur verwendet ausschließlich etablierte und für viele Plattformen verfügbare Standardprotokolle und Applikationen sowie gut dokumentierte Progammiersprachen wie Bash und Perl. Das Projekt bietet damit Schnittstellen zu anderen Plattformen. So ist über einen Citrix-Metaframe-Client eine Verbindung zu Windows-Servern möglich, die sich nahtlos in den Desktop eingliedert. Es gibt mehrere Java-Runtime-Umgebungen für Linux und damit eine ganze Reihe plattformübergreifender Software, etwa SAP-R/3-Frontends. Im Extremfall tritt der Desktop der vorgestellten Architektur komplett in den Hintergrund.

Das Resultat ist eine preiswerte, lizenzkostenfreie und skalierbare Lösung für kommerzielle Plattformen wie Kiosk- oder Point-of-Sale-Produkte. Auch die IT-Sicherheit profitiert von Diskless Clients: Große Teile des Filesystems werden nur lesbar gemountet, was Manipulationen an Programmen und Bibliotheken erschwert. Zudem gelingt es angriffslustigen Usern nicht mehr so leicht, eigene Programme und Skripte zu verstecken. Insgesamt verschiebt sich der Aufwand für Sicherheit und Konfiguration von den Clients zum Server und damit auf ein besser zu überwachendes Terrain. (jk)