english version
Net-PCs mit Linux
I. Arbeitsplätze an Net-PCs / DXS
II. Einrichten der Diskless X Stations
III. Fazit/Ausblicke/Weiterführende Links
II. Einrichten der Diskless X Stations
0.Intro
Diskless X-Stations sollen den Administrationsaufwand senken, dabei
aber gleichzeitig eine gewisse Breite an Hardware unterstuetzen, da sich
der Einsatz der jeweils nächsten PC-Generation schrittweise vollziehen
können soll. Mithin soll der kleinste gemeinsame Nenner aller zur
Verfügung stehenden Rechner trotzdem höchste Performance und
Anwenderfreundlichkeit sicherstellen.
Der anfängliche Startvorgang erfolgt analog zu dem der
X-Terminals. Eine kleine Bootsoftware, die
auf der Clientmaschine installiert ist, sendet Bootp-/Dhcpbroadcastpakete
in das lokale Netz und erhält zuerst ihre IP-konfiguration und dann einen
Bootkernel per Tftp übertragen.
Die Ähnlichkeit zur X-Terminallösung stellt hochflexible
Umgebungen sicher und ermöglicht einfache Migration des PC' zwischen
X-Terminal und Diskless X-Station.
1. Booten des Kernels
Durch Bootp/DHCP erfolgt die grundsätzliche Übertragung der
Netzwerkdaten zu dem anfragenden Gerät, so dass keinerlei Information
dieser Art auf den DXS vorliegen muss. Es kommt eine Lösung mit Boot-PROMs
(basierend auf dem Netboot- bzw. Etherbootpaket) und geeigeneten Netzwerkkarten
in Frage. Einige Netzwerkkarten, wie die 3C905C von 3COM bringen ein eigenes
BIOS mit, welches tcp/ip basiertes Booten über Bootp/Tftp erlaubt.
Bei preiswerteren Netzwerkkarten benötigt man meistens ein seperates ROM,
welches den Bootcode aufnimmt. Die aktuelle Mainboardhardware erlaubt hingegen
eine Vereinfachung der Plazierung des Bootcodes.
In den meisten Fällen kann die erforderliche Software zum System-BIOS
hinzugefuegt und dann mit den üblichen Softwaretools ins Mainboard-ROM geflasht
werden. Für die Erläuterungen der Bootcodepakete und des Bootp-Servers sei
auf die Ausführungen zu den X-Terminals
verwiesen. In den meisten Fällen wird man inzwischen auf DHCP setzen, da es
die Übermittlung vielfältiger Konfigurationparameter gestattet,
wie er weiter unten beschrieben wird.
2. Der Bootcode im Mainboardbios
Einige All-In-One-Mainboards (Audio, Netzwerkadapter) vermitteln bereits
die Idee, was erreicht werden soll: Es gibt bereits eine BIOS-Einstellung
- "Boot from Network", leider jedoch meist nur für ein IPX/SPX Netzwerk.
Dieses lässt sich jedoch in den meisten Fällen modifizieren...
Die meisten handeslüblichen neuen Mainboards, verfügen über ein AWARD-
bzw. AMI-BIOS, welchen in einem Flashspeicher untergebracht ist. Mit
einer speziellen Software lässt sich der Bootcode dem BIOS hinzufügen. In vielen
Fällen kann so auf seperate EPROMs und damit auf einen EPROM-Brenner verzichtet
werden.
Man benötigt jeweils zwei Softwaretools, eines zum Auslesen und
Beschreiben des Speicherbausteins und eines zum Modifizieren des BIOS-Codes.
Die Tools zum Programmieren des Flashs liegen üblicherweise dem Board bei
oder sind einfach überAWARD (hier
awdflash.exe) oder AMI (dann amiflash.exe)
zu beziehen.
Auch unter Linux gibt es inzwischen (wenn auch noch eingeschränkte)
Option: Das < href="http://www.freiburg.linux.de/~stepan/bios">/dev/bios"
Projekt beschäftigt sich damit über ein Kerneldevice auf verschiedene
Flashbausteine zuzugreifen. So kann durch einfaches Laden des Moduls und
Anleigen des Devices mit "dd" das Bios ausgelesen und geschrieben werden.
Trotzdem ist hier noch Vorsicht angebracht, da nicht alle Chipsets und
Flashgrössen vollständig unterstützt sind.
Zur Analyse und Modifikation eines AWARD-BIOS verwendet man
cbrom.exe,
für ein AMI-BIOS amibcp.exe. Die beiden genannten Tools können zusäztlichen
Code hinzufügen oder überflüssige Bioskomponenten entfernen.
Auf diese Weisen kann man Etherboot in das Mainboardbios integrieren, ohne
überhaupt den Rechner aufschrauben zu müssen.
Zuerst speichert man das Biosimage in eine Datei (z.B. als bios.bin) und
legt möglichst noch ein Backup an oder man lädt die aktuelle
Version des BIOS von der Website des Boardherstellers herunter.
AWARD-Bios
Mit "cbrom bios.bin /d" ermittelt, wieviel Platz noch im
ROM-File vorhanden ist und für unseren Code zur Verfügung steht. Das Bios
im Flashrom liegt komprimiert vor, cbrom komprimiert unseren Code,
wenn es diesen dem Bios hinzufügt. Man benötigt deshalb, in Abhängigkeit
von Treiber unserer Netzwerkkarte, 8 bis 20 kByte freien Speicherplatz. Ist
nicht genügend vorhanden, können nicht benötigte Bioskomponenten entfernt
werden: Das Logo des Herstellers oder der Symbios/NCR SCSI-Code werden für
plattenlose Systeme nicht benötigt. "cbrom bios.bin /[pci|ncr|logo|isa]
release" entfernt solche nicht benötigten Teile.
Mit dem Kommando "cbrom bios.bin /[pci|isa] bootimg.rom [D000:0]" fügt man
den kompilierten Etherbootcode zum Bios hinzu. Das bootimg.rom ist der Code,
den man sonst in ein EPROM brennen würde. Die Option [pci/isa] hängt vom
Typ der Netzwerkkarte ab. Wenn man eine ISA-Karte verwendet, gibt man cbrom
noch die Speicheradresse mit, an die der Code wärend des Bootens kopiert
werden soll.
AMI-Bios
Das AMI-Tool (amibcp.exe) lässt sich interaktiv menugesteuert bedienen: Man
startet das Tool ohne Kommandozeilenparameter und lädt das Biosfile über den
ersten
Menupunkt: "Load BIOS from Disk File". Bearbeitet wird das BIOS über die dritte Menuoption "Edit BIOS Modules". Am unteren Bildschirmrand wird die noch
verfügbare Speichermenge für Erweiterungen angeziegt. Sollte dieser nicht
ausreichen, kann man versuchen überflüssige BIOS-Komponenten (Hersteller-Logo
...) zu entfernen.
Mit der "INS"-Taste kann man Zusatzmodule einfügen. Das
Modul kann "compressed" eingefügt werden, was bevorzugt werden sollte. Mit
"ESC" kann man den Edit-Bereich verlassen und mit Menupunkt Zwei: "Save BIOS
File to Disk" das veränderte Biosfile speichern.
Achtung: Man sollte Etherboot mit den Optionen -DASK_BOOT oder
-DEMERGENCYDISKBOOT kompilieren, da man sonst nciht mehr auf Diskette oder
Platte zugreifen kann. Der Code den man dem BIOS hinzufügt, wird noch vor
dem ersten Platten- oder Floppyzugriff ausgeführt.
3. Weitere Möglichkeiten des Bootens
Möchte man den Computer unter mehreren Betriebssystemen nutzen, z.B. neben
dem auf Festplatte installierten ms windos NT als X-Terminal starten,
verwendet man bei etherboot dazu die Compileoption -DASK_BOOT.
In einigen Fällen
gibt es jedoch Hardwarekonflikte zwischen Windows-NT und dem installierten
EPROM. Für diese Fälle kann man DOS Executables produzieren (z.B. mit make
rtl8139.com), welche die .rom Images in ihrer Funktionalität ersetzen.
Soweit man nicht auf einen bereits vorhandenen DOS-Bootsektor zurückgreifen
kann, erzeugt man ihn mittels Formatieren und Installieren einer Festplatte
mit DOS, bevor man NT einspielt (vgl. Win-NT Multiboot-HOWTO).
Man benötigt zudem die DOS Systemdateien (IO.SYS, MSDOS.SYS oder KERNEL.SYS
wenn man Freedos verwendet) und kopiert diese in das Verzeichnis des NT
Loaders. Wenn man die .COM Datei über die Autoexec.bat aufrufen möchte,
sollte man auch die entsprechende COMMAND.COM bereitstellen oder man nennt
die Etherbootdatei einfach nach COMMAND.COM um. Diese wird dann anstelle der
DOS-Shell aufgerufen, was Benutzereingriffe, wie Abbrüche etc. verhindert.
Anschliessend fügt man der BOOT.INI eine Zeile hinzu, als wollte man DOS
booten:
[boot loader]
timeout=20
default=C:\bootsect.dos
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Workstation, Version 4.0"
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Workstation, Version 4.0 [VGA-Modus]" /basevideo /sos
C:\bootsect.dos="DHCP/TFTP (Linux diskless via etherboot)"
Unter Windows 95 bzw. 98 kann die .COM-Datei einfach über das Bootmenü
aufgerufen werden.
4. DHCP und Konfigurationsdateien
Dhcp wird aufgrund seiner Flexibilität zum zentralen
Konfigurationstool. Es wird versucht werden, über diesen Dienst alle
relevanten Informationen zum Betrieb einer Diskless X-Station zu
übertragen. Neben den klassischen Parametern, wie Hostname, IP-Adresse,
Netzmaske und Gateway, zählt dazu eine Reihe von Servern: X-Display-, Time-,
Swap-, NIS-Server etc. Darüberhinaus soll in einem Stringfeld die
Konfiguration von Grafikkarte und Monitor, incl. Mausanschluss übermittelt
werden. Ein weiteres Feld nimmt Kommandozeilen auf, die an die Datei
boot.local angehangen und ausgeführt werden auf. So lassen sich der Sound
konfigurieren oder zusätzliche Gerätetreiber laden.
Im weiteren bezieht sich die Beschreibung auf die Dhcp-Implementation
des Internet Software Consortioums (ISC). Diese liegt inzwischen in der
dritten Version vor und unterstützt eine ganze Reihe von Features.
A. Serverseite
Die DHCP-Konfigurationsdatei /etc/dhcpd.conf kann gegenüber den
Einstellungen für X-Terminals z.B. über Informationen zum Font-,
Print-, Swap- und NIS-Server durch entsprechende Optionstrings erweitert
werden:
option nis-domain string;
option nis-servers ip-address [, ip-address... ];
option font-servers ip-address [, ip-address... ];
option lpr-servers ip-address [, ip-address... ];
option swap-server ip-address [, ip-address... ];
DHCP bietet die Möglichkeit Vendoroptionen aufzunehmen, d.h. es
können eigene Optionen definiert werden. Hierfür steht ein Codebereich von
128 - 255 zur Verfügung. Wenn man sehr viel Information übertragen will,
sollte man die Paketgrösse des Bootpreplypakets über den Standard hinaus
erhöhen. Diese Optionen werden zu Bginn der
Konfigurationsdatei vom dhcpd definiert:
# -- much info transferred --
dhcp-max-message-size 1024;
# -- user defined options --
option bootlocal-script code 151 = string;
option x-server-defs code 152 = string;
Wobei folgende Variablen verwendet werden können: string, integer,
boolean, text, ip-number. Diese können auch zu Arrays
zusammengefasst werden. Anschliessend verwendet man diese Optionen
genauso, wie die bereits vordefinierten:
group {
option x-server-defs "de MouseMan ttyS0 65 90 XF86_S3 accel 16";
option bootlocal-script "insmod agpgart >>/dev/null";
...
host dxs01 {
...
Das "group" Statement hilft hierbei, neben der Unterteilung nach
Subnetzen, Konfigurationsblöcke mit gleichen Parametern zusammenzufassen.
So muss nicht für jeden Host die gesamte Palette wiederholt werden.
Eine Beispielkonfiguration könnte wie folgt aussehen:
option domain-name "stud.uni-goettingen.de goe.net gwdg.de";
filename "/boot/bootimg";
use-host-decl-names on;
default-lease-time 72000;
max-lease-time 144000;
subnet 134.76.60.0 netmask 255.255.252.0 {
option domain-name-servers 134.76.60.21, 134.76.60.100;
option ntp-servers ntps1.gwdg.de, ntps2.gwdg.de, ntps3.gwdg.de;
option font-servers dionysos.stud.uni-goettingen.de;
option x-display-manager s4, s5, s6, s9, s10, s11, s12;
# option netbios-name-servers 134.76.63.252;
option routers 134.76.63.254;
option broadcast-address 134.76.63.255;
# range 134.76.60.201 134.76.60.253;
}
group {
option option-151 "de PS/2 psaux 96 100 XF86_SVGA svga 16";
option option-152 "modprobe -qa agpgart esssolo1";
host klusi {
hardware ethernet 00:00:1C:D9:78:D9;
fixed-address 134.76.60.64; }
...
B: Clienteinstellungen
Auf der Clientseite sorgt dhclient für die Konfiguration der
einzelnen Variablen, in dem die Daten vom Server angefordert und durch
dhclient-script in die Konfiguration der DXS eingefügt werden.
Die Konfiguration, welche Daten überhaupt angefordert werden sollen,
welche für den Betrieb zwingend notwendig sind, bzw. nur bei
Vorhandensein abgefragt werden, erfolgt in der Datei
/etc/dhclient.conf. Benutzerdefinierte Optionen werden durch
"option-XXX" abgefragt, wobei XXX durch den Zahlenwert ersetzt wird, wie
er in der /etc/dhcpd.conf definiert wurde. Das zu übertragende
Datenmaximum wird durch die MTU-Size des Netzwerkes begrenzt. Wie auch bei den
Servereinstellungen gilt: Soll viel Information übertragen werden, muss
die Grösse des Bootreplypakets angepasst werden. Dieses lässt sich vom
Server mit "send dhcp-max-message-size 1024" anfordern.
dhclient-script ist ein umfangreiches Shellskript,
welches entweder über den Aufruf der entsprechenden Kommandos den Hostname
setzt oder /etc/resolv.conf anlegt, sondern auch Konfigurationsdateien
parsen oder neu anlegen kann. Mit dem ISC-DHCP wird ein Beispielskript
verteilt, welches dann um alle Optionen erweitert werden muss, die über
die Minimalkonfiguration von IP-Adresse, Hostname und DNS-Auflösung
hinausgehen. Alle Konfigurationsdateien, die von diesem
Vorgang berührt werden, sind deshalb in die Ramdisk verlinkt. So kann das
Basisfilesystem Readonly bleiben und einheitlich für alle Geräte verwendet
werden.
5. Der Bootkernel
Die Anforderungen an den Kernel einer DXS sind gegenüber einem
X-Terminal gewachsen. Er soll
zugleich eine breite Hardwarepalette unterstützen, dabei aber
flexibel bleiben, damit nicht für jede neue Hardware ein seperater
Kernel erstellt werden muss. Deshalb und um den neuen
Aufgaben der Soundwiedergabe, dem Anschluss von Userdevices etc. gerecht zu
werdeni, wird er modular aufgebaut. Auf diese Weise lassen sich sehr viele
verschiede Komponenten
unterstützen, ohne dass dabei Konflikte zum Basiskernel entstehen und
sich ein entsprechend grosser Overhead ergibt. Die Unterstützung für
alle verwendeten Netzwerkkarten, sowie die Basisfilesysteme NFS und Minix
(für die Ramdisk) müssen sebstverständlich statisch eingebunden
sein, da diese zu Beginn des Bootvorganges benötigt werden.
Kandidaten für die modulare Unterstützung sind deshalb alle
Zusatzdevices, die nicht an allen Arbeitsplätzen zur Verfügung
stehen müssen. Dazu gehört die breite Palette an unterstützten
Soundkarten, verschiedene SCSI-Adapter und Geräte, USB-Unterstützung,
serielle Mäuse
und Drucker, Removable Devices, wie ZIP und LS120 etc. Besondere Filesysteme
oder Treiber, wie den AGP-Gart für ausgesuchte Grafikhardware,
welche nur unter bestimmten Bedingungen zur Verfügung stehen
müssen und
weitere Funktionen werden auch als Modul zur Verfügung gestellt.
Ansonsten gelten die Voraussetzungen, wie sie für die X-Terminals
bereits getroffen wurden.
In der /etc/modules.conf liegen die Anweisungen, welche
Kernelmodule geladen werden muessen, wenn ein bestimmtes Device z.B. der
IDE/ATAPI-Treiber fuer das ZIP-Drive angefordert wird.
6. NFS als Basisfilesystem
Das Networkfilesystem bildet die Basis des gesamten DXS-Projekts. Eine
hohe Stabilität, Verfügbarkeit und Zuverlässigkeit müssen
gewährleistet sein. Hierin liegen zur Zeit noch einige Probleme von Linux
begründet. Die derzeitige Kernelarchitektur enthält noch einige
Schwächen, so dass die derzeitige Implementation Schwächen zeigt. Diese
lassen sich umgehen, wenn man Abstriche in der Geschwindigkeit in Kauf
nimmt und z.B. auf den Kernel-NFSD verzichtet. Da aber gerade die Filesystemperformance
die Brauchbarkeit der DXS beeinflusst, stehen der Kernel-NFSD und die NFS
Version3-Unterstützung auf der Wunschliste. Hierdurch kann der
Datendurchsatz nocheinmal verdoppelt werden.
Das Filesystem einer Arbeitsstation setzt sich aus mehreren Teilen
zusammen. Zürst wird das Basisfilesystem analog zur
XTerminalimplementation als Root-NFS gemountet. Dieses enthält alle zum
weiteren Booten notwendige Systemsoftware: Binärdateien, Bibliotheken und
Skripten. Hierbei wurde versucht die Struktur weitestgehend an der
Standardinstallation zu orientieren und nur wenige unumgängliche Dateien
an die speziellen Erfordernisse plattenloser Clients anzupassen. Dies soll
verhindern, dass bei allfälligen Systemupdates zu viele Abhängigkeiten
beachtet werden müssen. In einem nächsten Schritt liesse sich durch das
Anlegen von Hardlinks weiterer Aufwand reduzieren.
Anschliessend werden das /usr- und /opt-Verzeichnis, wie auch das Root-NFS
readonly hinzugemountet. Somit besteht kein Risiko der Veränderung
systemwichtiger Dateinen. Durch die komplette Übernahme der beiden
wichtigsten Verzeichnisse für Anwenderprogramme, entfällt die spezielle
Softwareadministration für die DXS. Weiterhin wird in den Bereich der
RAM-Disk unter /tmp/users eine schreibbare NFS-Partition eingehängt, die
den beschreibbaren Platz im Dateisystem ausdehnt.
Per Automounter werden auf Anforderung die Homeverzeichnisse der User
eingefügt. Um auch hier eine höhere Ausfallsicherheit zu erhalten, wurde
der Automounter so modifiziert, dass er mehrere Server auf Erreichbarkeit
prüfen und dann einhängen kann.
Eine Beispielumgebung für DXS (stark abhängig von der
Serverinstallation!!) liegt als Tar-Ball vor.
7. Die Startskripten
Das erste Skript, welches beim Booten vom Client ausgeführt wird, ist
gegenueber der Standardinstallation an die plattenlose Umgebungsbedinung
angepasst worden. Hier werden die einzelnen Bereiche des Filesystems
gemountet und dhclient gestartet, um zum fruehest moeglichen
Zeitpunkt alle Konfigurationsoptionen zur Verfuegung zu haben. In
boot.local werden weitere Anpassungen vorgenommen, die diesmal aber
abhänging vom Hostnamen passieren: So lässt sich angepasst an das
Gerät das entsprechende Soundtreibermodul installieren, bei Bedarf die Treiber
für die Videokarte oder andere Devices laden.
Zum Schluss wird wieder das Auswahlskript fuer den X-Server (in
/bin/xrun) aktiv, welches anhand des Rechnernames die geeignete Auswahl
von Hardwaretreiber und Konfigurationsdatei trifft.
Zurück
Weiter
Text von Dirk v. Suchodoletz (dirk@goe.net)
