![[Photo of the Author]](../../common/images/Ken-Y.gif)
original in en Ken Yap
en to de Harald Radke
![[Illustration]](../../common/images/illustration2.gif)
Die Idee selbst ist nicht neu. Hauptansatz ist hierbei, daß der Rechner ein Programm in einem nichtflüchtigen Speicher hat, zum Beispiel ein ROM Baustein, das ihm erlaubt, einen Server zu kontaktieren und ein Dateisystem über die Netzwerkverbindung zu nutzen. Es gibt mehrere Vorteile dieses Verfahrens. Die Kosten für die Pflege von Software auf vielen verschiedenen Rechnern können reduziert werden. Werden diese über das Netz gebootet, so befinden sich alle Dateien auf einem zentralen Server und müssen so nur an einer Stelle erneuert werden. Praktisch ist dieses Verfahren auch an Plätzen, die für Festplatten nicht geeignet sind, diese zerstören oder ihre Funktionsfähigkeit beeinflußen könnten, wie zum Beispiel eine Produktionshalle, in der eine Festplatte zu starken Schwingungen ausgesetzt ist. Letztlich erhält man durch diese Technik ein System, auf welchem zwischen verschiedenen Betriebssystemen gewechselt werden kann, ohne die Software neu zu installieren.
Oft geht das Booten über Netz einher mit dem Booten von Platte. Zum Beispiel kann ein Rechner Windows von der Festplatte aus fahren, aber manchmal eben über das Netz unter Linux starten. Dies bietet einige interessante Möglichkeiten. Ein Bekannter von mir zum Beispiel installiert Windows über das Netzwerk. Wenn dann die Windows-Installation (wie so häufig) instabil wird, kann der Administrator eine Neuinstallation durchführen, indem er Linux über Netz bootet und über ein Skript die Festplatte formatiert und eine neue Version einer Windows-Installation aufspielt.
Damit ein Rechner über Netz booten kann, benötigt er:
Man stelle sich einen Rechner ohne Festplatten vor (Diskless Computer = DC),
der über ein ROM für das Booten über Netz verfügt. Angenommen, er
ist einer von vielen gleichartigen DCs, wie kann dieser Rechner von allen anderen
unterschieden werden?
Es gibt eine Zahl, die jeden vernetzten Rechner auf der Welt einmalig und
unterscheidbar macht: die Ethernet-Adresse der Netzwerk-Karte.
Jede Ethernet-Karte auf der Welt besitzt eine eigene, einmalige 48 Bit breite
Ethernet-Adresse. Jeder Hersteller dieser Karten besitzt einen Block von
Adressen, aus dem er die Adressen seiner Karten bezieht. Es ist
Konvention, diese Adressen in hexadezimal Schreibweise darzustellen, wobei
immer zwei Ziffern durch einen Doppelpunkt getrennt werden, zum Beispiel:
00:60:08:C7:A3:D8.
Die Protokolle, die benutzt werden, um für eine gegebene Ethernet-Adresse
eine IP Adresse zu erhalten, heißen Boot Protocol (BOOTP) und
Dynamic Host Configuration Protocol (DHCP). DHCP ist eine Weiterentwicklung von
BOOTP. Im Folgenden gilt alles, was BOOTP betrifft, ebenso für DHCP, solange
dies nicht explizit eingeschränkt wird.
Nebenbei: Es ist nicht ganz richtig, daß BOOTP und DHCP nur für die
Resolvierung von Ethernet-Adressen benutzt wird. In weiser Voraussicht haben die
Entwickler dafür gesorgt, daß beide Protokolle mit jeglicher Art
von Hardware-Adressen arbeiten können. Allerdings wird Ethernet am häfigsten
benutzt.
Ein Beispiel für ein BOOTP Dialog sieht ungefähr so aus:
Nun mag man sich fragen, woher der DC die Adresse des BOOTP Servers am Anfang kannte. Die Antwort lautet: er kannte sie gar nicht! Die BOOTP Anfrage wurde an alle Rechner im LAN geschickt (Braodcast) und jeder BOOTP Server, der sie beantworten kann, wird auf sie reagieren.
Nachdem der DC eine IP Adresse erhalten hat, muß er die Datei mit dem Kern eines Betriebssystemes herunterladen und ausführen. Dafür wird ein weiteres Internetprotokoll verweden, genannt Trivial File Transfer Protocol (TFTP). Dies ist eine "light" Version des FTP Protokolles. Es gibt keine Authentifizierung und das Protokoll benutzt das User Datagram Protocol (UDP) statt des Transmission Control Protocol (TCP). UDP wurde aufgrund seiner Einfachheit dem TCP Protokoll vorgezogen. Die UDP Implementierung auf dem DC ist recht klein, sodaß der Kode problemlos in ein ROM paßt. Da UDP block-orientiert arbeitet, werden die Daten Block für Block, und nicht in einem Datenstrom übertragen:
Dies wird für die komplette Datei durchgeführt. Für das Handshaking wird ein einfaches Schema für die Bestätigung jedes Blockes benutzt, Verlust von Paketen wird durch das Wiederholen der Sendung bei einem auftretenden Timeout behandelt. Nachdem alle Blöcke übertragen worden sind, übergibt das ROM die Kontrolle an den Betriebsystemkern ab.
Schließlich muß für die Ausführung eines Betriebsystemes noch ein Wurzelverzeichnis zu Verfügung stehen. Gängiges Protokoll, daß von Linux und anderen Unix Derivaten hierfür benutzt wird, ist normalerweise Network File System (NFS), obwohl auch andere möglich sind. In diesem Fall braucht der Kode nicht im ROM zu liegen, sondern kann Teil des gerade heruntergeladenen Betriebsystemkernes sein. Wie auch immer, das Betriebssystem muß in der Lage sein, mit einem Wurzelverzeichnis per NFS statt einer lokalen Festplatte zu arbeiten. Linux kann entsprechend konfiguriert werden.
Neben kommerziellen Boot-ROMs existieren noch zwei freie Pakete für das Booten über Netz: Etherboot und Netboot. Beide können über die Etherboot Homepage bezogen werden. Zuerst muß aber vor Gebrauch sichergestellt sein, daß die Netzkarte von einem der beiden Paketen unterstützt wird. Eventuell muß zusätzlich noch jemand gefunden werden, der ein EPROM (Erasable Programmable Read Only Memory) mit dem Kode beschreibt, anfangs kann man aber ebensogut auch von Diskette booten.
Um eine Boot Diskette zu erstellen, muß ein spezieller Bootblock mit der Distribution mitkommen. Dieses 512 Byte großge Programm lädt die nachfolgenden Blöcke der Diskette in den Speicher und startet dann den im Speicher befindlichen Kode. Also muß nur der Bootblock der Diskette mit dem für die jeweilige Netzkarte entsprechenden Treiber verbunden werden:
cat floppyload.bin 3c509.lzrom > /dev/fd0
Bevor nun von der Netzwerk-Bootdiskette gestartet werden kann, müssen die oben erwähnten Service unter Linux (auf dem Server) gestartet werden: BOOTP (oder DHCP), TFTP und NFS. Diese können Schritt für Schritt konfiguriert werden. Man sollte jeweils jeden einzelnen Service auf seine Funktionsfähigkeit überprüfen, bevor der nächste installiert wird.
Nach der Installation des bootpd Servers, sei es von einer Linux Distribution oder durch Übersetzen des Quelltextes, muß sichergestellt werden, daß der Server auf BOOTP Anfragen wartet. Es gibt prinzipiell zwei Möglichkeiten, dies zu tun: die eine besteht darin, bootpd beim Start des Rechners hochzufahren und den Server die ganze Zeit über auf eine Anfrage warten zu lassen. Alternativ dazu kann der Server über inetd gestartet werden. Dann muß die Datei /etc/inetd.conf folgende Zeile enthalten:
bootps dgram udp wait root /usr/sbin/tcpd bootpd
Sollte /etc/inetd.conf geändert werden müsen, so wird ein Neustart des inetd Servers notwendig, am Besten dadurch, daß man ein HUP Signal an ihn sendet.Nun muß noch eine Datenbank für BOOTP und die Resolvierung Ethernet-Adressen -> IP Adressen angelegt werden. Diese Datenbank sollte unter /etc/bootptab liegen. Ihre Einträge haben die Form:
aldebaran.foo.com:ha=006008C7A3D8:ip=192.168.1.100:bf=/tftpboot/vmlinuz.nbEs können noch weitere Informationen angegeben werden, aber zu Anfang reicht dies aus.
Wird nun der DC mittels Diskette gebootet, so sollte er die Ethernet-Karte finden und eine BOOTP Anfrage via Broadcast absetzen. Ist alles korrekt eingestellt, sollte der Server dem DC anworten und ihm die benötigten Information übermitteln. Da /tftpboot/vmlinux.nb allerdings noch nicht existiert, wird der Versuch, die Datei zu laden, natürlich scheitern.
Als nächstes muß ein spezieller Kernel kompiliert werden, der in der Lage ist, das Wurzelverzeichnis über NFS einbinden zu können. Außerdem muß noch die entsprechende Option eingestellt werden, die IP Adresse von der ursprünglichen BOOTP Anfrage zu erhalten. Desweiteren muß die Netzkarte vom Kernel unterstützt werden, der Treiber muß fest in den Kernel integriert sein, und nicht als Modul nachgeladen werden. Es ist zwar möglich, eine RAM-Disk herunterzuladen, sodaß das Laden von Modulen funktioniert, dies sollte aber auf später verschoben werden.
Die zImage Datei, die nach der Kernelübersetzung entstanden ist, kann so nicht installiert werden. Sie muß vielmehr in ein tagged image umgewandelt werden. Dies ist ein normales Kernelimage mit einem speziellen Anfangsheader, der dem Netzwerk-Bootloader die Speicherbelegung des Kernels und seine Startadresse im RAM mitteilt. Um ein "tagged image" aus zImage zu erhalten, benutzt man ein Programm namens mknbi-linux. Dieses kommt mit dem Etherboot Paket mit. Nachdem die Imagedatei erstellt worden ist, wird sie in das Verzeichnis /tftpboot kopiert, und zwar unter den Namen, der in /etc/bootptab angegeben ist. Die Datei muß von allen lesbar sein, da der TFTP Server keine speziellen Rechte hat.
Nach der Installation von TFTP (wieder entweder von einer Distribution oder vom Quelltext), wird der Server meist von inetd aus gestartet, und zwar mit dieser Zeile in /etc/inetd.conf:
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot
Wieder muß inetd mittels eines HUP Signales neu gestartet werden. Wird der DC neu (über Diskette) gestartet, so sollte nun die Kerneldatei heruntergeladen und gestartet werden. Der Bootvorgang wird diesmal erst an dem Punkt unterbrochen, an dem via NFS das Wurzelverzeichnis eingebunden werden soll. Nun muß noch der NFS Dienst konfiguriert und die entsprechende Partition exportiert werden.
Aus verschiedenen Gründen ist es nicht so gut, das Wurzelverzeichnis des Servers als das des DCs mitzubenutzen. Einmal befinden sich hier viele Konfigurationsdateien, die auf den Server und nicht den DC zugeschnitten sind. Desweiteren ist dies unter dem Gesichtspunkt der Sicherheit bedenklich, da so Schreibzugriffe auf das Wurzelverzeichnis des Servers ermöglicht werden (das Wurzelverzeichnis des DCs muß aus unterschiedlichen Gründen von diesem beschrieben werden können). Glücklicherweise braucht das Wurzelverzeichnis des DCs nicht allzu groß zu sein, ca. 30 MB sollten ausreichen. Zudem kann ein großer Teil dieses Speichers von mehreren DCs geteilt werden.
Idealerweise sollte man für die Errichtung eines Wurzelverzeichnisses wissen, welche Dateien das Betriebssystem und die jeweilige Distribution dort erwarten. Kritisch in Sachen Booten sind Gerätedateien, Dateien in /sbin und /etc. Man kann sich jedoch viel Arbeit ersparen, indem man eine Kopie eines existierenden Wurzelverzeichnisses anlegt und diese nur noch entsprechend für den Einsatz unter dem DC modifiziert. Mit dem Etherboot Paket kommt eine Einführung mit, sowie ein Reihe von Verweisen auf Shellskripte, die für das Anlegen von DC Wurzelverzeichnissen ausgehend von einem gegebenen Wurzelverzeichnis geschrieben worden sind. Desweiteren findet man dort einige Tips und Hilfestellungen zu Problemen, da dies meistens der schwierigste Teil der ganzen Prozedur ist.
Der modifizierte Linuxkernel des DC erwartet das Wurzelverzeichnis unter /tftpboot/<IP Adresse des DC>, also zum Beispiel: /tftpboot/192.168.1.100 im obigen Falle. Dies kann, wenn notwendig, bei der Konfiguration des Kernels geändert werden.
Nun sollte /etc/exports auf dem Server angelegt oder modifiziert werden. Folgende Zeile wird eingefügt:
/tftpboot/192.168.1.100 aldebaran.foo.com(rw,no_root_squash)
Der Lese- und Schreibzugriff rw wird von mehreren Systemdiensten benötigt. Die no_root_squash Option verhindert, daß NFS die "root" ID des einen Systems auf die des anderen abbildet. Sollte diese nicht angegeben werden, könnten einige Daemons und Logger darauf recht ungehalten reagieren.
Nun wird nach dem Start (oder Neustart) des NFS Service (rpc.portmap und rpc.mountd) erneut der DC gebootet. Dieses mal sollte der Kernel das Wurzelverzeichnis über Netz mounten können und bis zum Login booten. Es ist recht wahrscheinlich, daß einige Dinge falsch konfiguriert sind. Viele Linux Distributionen sind für den Betrieb mit Festplatten ausgelegt und erforden ein paar kleinere Modifikationen für das Booten ohne Festplatte. Die häfigsten Fehler hängen damit zusammen, daß zur Bootzeit auf Dateien in /usr zugegriffen werden soll. Es gibt zwei Wege, diese zu eliminieren:
Es können jetzt noch mehr Verzeichnisse des Servers eingebunden werden, wie zum Beispiel /usr. Diese können nun auch nur Leserechte besitzen.
Ist man nun zufrieden, daß man über das Netz problemlos booten kann, mag man den Kode in ein EPROM schreiben. Einen entsprechenden Brenner bekommt man ab 170 DM, eine Investition, die für einen Hobbybastler, der das Gerät ab und zu mal benutzt, nicht allzu lohnenswert ist. Möglicherweise findet man auch mal ein Sonderangebot, man sollte dann aber auf jeden Fall darauf achten, daß es auch Software für den jeweiligen Brenner gibt. Ein erfahrener Elektronikbastler mag sich auch selbst solch ein Gerät bauen, deren Baupläne im Internet frei verfügbar sind. Für die Mehrzahl der Leser aber dürfte es angebracht sein, sich an jemanden zu wenden, der Zugang zu solch einem Brenner hat, zum Beispiel an jemanden aus einem Elektronikbastel Club oder auch einen Bekannten, der im Elektronikbereich tätig ist.
Ein paar Worte zur Technologie der EPROMs: Die Bits eines EPROMs werden durch das Anreichern des Gates eines Feldeffekt-Transistors mit Elektronen (mittels Anlegen einer erhöhten Spannung) auf logisch 0 gesetzt. Die dort gefangenen Elektronen bringen den Transistor dazu, zu leiten, was als 0 interpretiert wird (wie dann die 1 aussieht, sollte klar sein). Um ein EPROM zu löschen, werden die Elektronen auf eine höheres Energieniveau gehoben, sodaß sie das Gate verlassen können. Dafür wird der Chip durch das Quarzfenster mit UV Licht bestrahlt. Im normalen Gebrauch des EPROMs wird diese Fenster undurchsichtig verlebt, damit kein Licht hindurchscheint und so den Inhalt zerstören kann.
Es gibt noch eine weitere Technik, genannt Electrically Erasable PROM (EEPROM), auch manchmal als Flash PROM bezeichnet. Hierbei werden die Bits durch elektrische Signale gelöscht. Dadurch wird das Löschen mittels UV Licht bei Wiederverwendung unnötig, allerdings werden dann mehr Schaltkreise für das Löschen notwendig. Der geschickte Leser kann sich mit den Schaltplänen und der Treibersoftware für eine EEPROM Karte auseinandersetzen, die mit Etherboot mitkommen. Die Karte wird in einen freien ISA Steckplatz eines PCs eingesetzt und booted eine eingebaute Netzkarte.
X Terminals sind ein typischer Einsatzbereich. Durch das Fehlen einer Festplatte im Terminal wird dieses leiser und trägt so zu einer besseren Arbeitsumgebung bei. Der Rechner sollte schon mindestens 16 MB Speicher haben, sowie die beste Grafikkarte, die man für ihn finden kann. Ein High-End 486 oder auch ein kleiner Pentium finden so auch noch, nachdem sie von besseren Rechnern verdrängt worden sind, eine Existenzberechtigung.
Auch kommt das Booten über das Netz bei Rechnerverbänden zum Einsatz, bei denen der Gebrauch der DCs nicht allzu intensiv ist und keine Festplatte notwendig macht, zum Beispiel eine Gruppe von Rechnern im Klassenzimmer.
Dort sind weitere Verweise auf andere Quellen zu finden, eingeschlossen einer Mailing Liste, auf der Probleme und deren Lösungen diskutiert werden.
Happy Netbooting!