Von: Dr. Klaus Plessner
Es geht auch ohne Microsoft", lautet die Überschrift einer der Web-Seiten aus der Rubrik "Internet-Cafe" des Wuppertaler Hochschulrechenzentrums. Die Rede ist dort von einem Service, den die Universität ihren Studenten zur Verfügung stellt: 60 mit Netscape ausgerüstete PCs ermöglichen den Zugang zum Internet und die Abfrage von Diensten der Unibibliothek. Wer einen Platz an einem der Rechner ergattert, die in der Bibliothek und in der Cafeteria aufgestellt sind, kann auch E-Mails empfangen oder verschicken. Die PCs arbeiten ausschließlich mit Linux und haben weder eine Festplatte, noch ein Diskettenlaufwerk oder ein CD-ROM-Laufwerk. Das Betriebssystem wird über das Netz geladen, mit Hilfe von "Netboot", einem Network-Bootloader-Programm, das auf dem Boot-ROM einer handelsüblichen Netzwerkkarte abgespeichert ist.
Auch die Universität Freiburg setzt Diskless-Workstations ein. Zum Hochfahren der Rechner dient der Bootloader "Etherboot". Linux-Clients bieten dort den Angehörigen der Universität einen Internet-Zugang, Telnet und Xwindows. Mit einem Browser lassen sich Datenbankdienste aufrufen, E-Mails verschicken und Besucherinformationen abfragen (siehe [2]).
Selbst in der freien Wirtschaft finden Remote-Boot-Verfahren auf der Basis von Linux Anklang. Ein Zusammenschluß südafrikanischer Warenhausketten der Möbelbranche mit insgesamt 1000 Filialen begann 1995 die Geschäfte auf Linux-Plattformen abzuwickeln. In jedem Möbelhaus steht mittlerweile ein Linux-Server, der um die vier Diskless-Workstations verwaltet. Den Start-up erledigt "Netboot".
Besserer Support
Zur Zeit gibt es zwei kostenlose Linux-Pakete für den Remote-Boot von PCs. "Netboot" stammt von Gero Kuhlmann und Jamie Honan. "Etherboot" wurde gemeinsam von Markus Gutschke und Ken Yap aus dem Network-Bootloader von "FreeBSD" entwickelt. Beide Pakete ermöglichen den Start eines Client-Rechners, indem sie eine Netzwerkverbindung mit einem Boot-Server herstellen, der den Client mit dem Kernel des Betriebssystems versorgt. Mit anderen Worten, der Client fährt nach einem Reset oder nach dem Einschalten wie gewohnt hoch, wobei er sämtliche Startinformationen von wenigen zentral verwalteten Servern erhält. Damit lassen sich identisch konfigurierte Workstations sehr einfach administrieren. Ihre Konfiguration wird lokal auf den Servern verwaltet. Für den Administrator besteht die Arbeit effektiv in der Betreuung eines einzigen Clients. Neue Rechner zu installieren bedeutet, abgesehen vom Aufbau der Hardware, ein paar Tabellen zu ergänzen. Der Griff zu Linux als Client-Betriebssystem spart Kosten. Evan Summers, DV-Betreuer der südafrikanischen Möbelhauskette äußert sich sehr zufrieden: "Mindestens tausend Lizenzen hätte man sonst allein für die Server gebraucht, nicht zu erwähnen die viertausend Workstations." Der Hauptgrund für die Wahl von Linux besteht in den Augen von Summers in der Qualität des Supports. Hilfeleistung erfolgt durch Mailing-Listen. Das sind "schwarze Bretter" im Internet, auf denen sich per E-Mail Fragen anbringen lassen, die innerhalb von Stunden beantwortet werden. Hilft das nicht weiter, wendet man sich an den Entwickler des Programms, welches Probleme bereitet. Der Vorteil gegenüber kommerziellen Betriebssystemen besteht darin, daß alle Informationen verfügbar sind. Es bestehen keine Geheimnisse.
Geringer Hardware-Aufwand
Um seinen Rechner über das Netz zu booten, muß zunächst die Netzwerkkarte mit einem Boot-ROM ausgestattet, sofern diese einen dafür vorgesehenen Sockel hat. Bei vielen handelsüblichen Interface-Karten trifft das auch zu.
Als nächstes - und damit ist in der Regel die Reihe der Anschaffungen schon abgeschlossen - braucht man die Software. Die ist schnell besorgt, man wendet sich am besten an die Homepages der Bootloader (siehe http://www.slug.org.au/etherboot/ und http://www.han.de/~gero/net boot/index.html). Die Remote-Boot-Pakete für Linux verfügen über zwei Hauptbestandteile:
Ein Makefile zur Erzeugung des Bootloaders. Der Bootloader wird mit einem EPROM-Brenner auf das Boot-ROM geschrieben. Ein Tool zur Erstellung des Client-Kernels. Dieser unterscheidet sich vom kompilierten Kernel, da er Code für die Kommunikation mit dem Bootloader enthält.
Bevor man seinen PC in eine Diskless-Workstation verwandelt, kann der Bootloader zu Testzwecken auch auf eine Diskette geschrieben werden, die statt einer Boot-Diskette den Rechnerstart einleitet.
Wie kommt nun ein Remote-Boot zustande? Sobald der Client-Rechner eingeschaltet wird, schickt der Bootloader einen BOOTP-Broadcast ab. Damit fragt er nach den IP-Adressen des Clients und des Boot-Servers und nach dem Namen des Kernel-Image. Anschließend fordert er vom Boot-Server per TFTP (Trivial File Transfer Protocol) die Übermittlung des Betriebssystem-Kernels an. Wenn der Kernel die Steuerung des Clients übernommen hat, importiert er sein Root-Verzeichnis von einem NFS-Server. Danach ist der Boot-Vorgang abgeschlossen. Häufig wird auch ein Home-Verzeichnis über NFS gemountet, wenn auf dem System Benutzer eingerichtet werden. Swapping über das Netz versucht man zu vermeiden, da es die Netzwerkbelastung erhöht. Entweder macht genügend RAM-Kapazität eine Speicherauslagerung überflüssig, oder der Client hat eine Festplatte, auf der sich eine Swap-Partition einrichten läßt.
Sowohl der Bootloader als auch der Client-Kernel können nicht nur unter Linux erzeugt werden. Die Makefiles sind für die meisten Unix-Systeme ausgelegt. Das Betriebssystem des Clients muß nicht Linux sein. Beide Pakete unterstützen den Remote-Boot von MS-DOS und Windows 95. Auch der Boot-Server muß nicht unter Linux betrieben werden. Der Client-Kernel kann ebensogut auf einem Novell-Server oder auf einem Windows-NT-Rechner verwahrt werden.
PCs von der Stange
Zur Ausstattung der Wuppertaler Diskless-Workstations gehören ein AMD-K5-Prozessor, 32 MByte RAM, eine Graphikkarte und ein 17-Zoll-Monitor. Als Server dient zum einen eine "Challenge M" von Silicon Graphics mit 192 MByte RAM und einer 9-GByte-Festplatte. Hierauf liegen das Root-Verzeichnis und die Boot-Kernels. Ein PC mit einem K6-233-Prozessor von AMD, 64 MByte RAM und einer 18-GByte-Festplatte verwaltet die Home-Verzeichnisse der Benutzer. Momentan gibt es 19 000 Home-Verzeichnisse. Jeder eingeschriebene Student erhält seinen Plattenplatz und eine eigene E-Mail-Adresse. Abgesehen von einem halbjährlichen Update der Home-Verzeichnisstruktur gebe es kaum Wartungsarbeiten, betont Eckhard Grah vom Rechenzentrum der Universität. Die Boot-Kernels und die Filesysteme sind für alle Clients identisch. Durch Hardmounts auf ein Master-Filesystem kann somit Plattenplatz gespart werden. Änderungen an den Files im Master-Filesystem sind unmittelbar für alle Clients wirksam. Was die Hardware-Ausstattung anbelangt, ist die Situation in Wuppertal durchaus typisch.
Je nach der Ausstattung der Server und der Clients und je nach den Anwendungen, die für den Benutzer bereit liegen, bieten sich verschiedene Möglichkeiten einer Remote-Boot-Architektur. In Wuppertal läuft die Anwendung auf den Clients, nachdem sie vom NFS-Server geholt wurde. Ebensogut könnten die Anwendungen auf dem Server gestartet werden. Über das X-Protokoll kann auf dem Zentralrechner ein X-Server gestartet werden, der vor Ort die Anwendungsprozesse aufruft (siehe [1]). Das stellt hohe Anforderungen an die Kapazität des Servers. Übernimmt der Client die Abwicklung der Programme, so besteht die Alternative, Java-Applets zu verwenden, die sich mit einem Java-fähigen Browser ausführen lassen. Nach diesem Modell arbeiten sowohl die Wuppertaler als auch die Freiburger Terminals. "Infobase", ein Datenbankdienst der Uni Freiburg ist in Java programmiert.
Boot-Parameter zentral verwalten
Die Remote-Boot-Pakete für Linux bieten auch die Möglichkeit eines Dual-Boot. Beim Hochfahren erscheint ein Menü, welches die ladbaren Betriebssysteme zur Wahl stellt. Dieses Verfahren wird in Rechnerräumen von Universitäten eingesetzt, wo Benutzer mit unterschiedlichen Betriebssystemen arbeiten. Die Universität Regensburg hat in den Rechner-Pools PCs aufgestellt, die mit Dual-Boot gestartet werden, jedoch nicht diskless arbeiten, sondern mit einem Diskettenlaufwerk und einer Festplatte versehen sind. Nach dem Start können die Studenten wie gewohnt mitgebrachte Disketten einspielen und Dateien auf der Festplatte zwischenspeichern. Eine Partitionierung der Festplatte bei jedem Start sorgt dafür, daß dem Benutzer zu Beginn der Sitzung jeweils dieselbe Konfiguration präsentiert wird. Möglich wäre auch, mit dem Boot-ROM lediglich die Boot-Konfiguration vom Server zu holen, während das Betriebssystem nach wie vor von der Festplatte geholt wird. Dadurch reduziert man die Netzbelastung, ohne auf die Möglichkeit zu verzichten, die Boot-Parameter zentral zu verwalten.
Die Bootloader-Pakete "Netboot" und "Etherboot" sind zueinander kompatibel. "Etherboot"-Clients können mit einem Kernel starten, der mit "Netboot" erzeugt ist und umgekehrt. "Netboot" simuliert gerade soviel DOS-Umgebung, daß die zu den Netzkarten gelieferten Treiber verwendet werden können. Dadurch unterstützt das Paket alle Netzkarten, für die DOS-Treiber erhältlich sind. Bei der Erzeugung des Boot-ROM-Codes müssen allerdings die Kartenparameter angegeben werden, weshalb für jede Konfiguration ein eigenes Boot-ROM-Programm erzeugt werden muß. Zu guter Letzt ist "Netboot" auch für Flash-ROM-Karten zu verwenden. Damit können Neubespielungen des Boot-ROM auch über das Netzwerk erfolgen. "Etherboot" unterstützt weniger Netzwerkkarten. Der Code des Bootloaders ist jedoch kleiner als beim "Netboot"-Paket und paßt auch auf ein acht KByte großes Boot-ROM. Außerdem konfiguriert sich der Bootloader selbst, so daß er, ohne Abstimmung auf die Kartenparameter für jedes Boot-ROM einzusetzen ist.
Linux im Aufwind
Obwohl Linux immer noch mit dem Ruf einer "Bastlerwerkstatt" zu kämpfen hat, wächst der Umfang seiner Verbreitung. Gemäß einer Studie von Datapro (siehe auch Seite 30 bis 33) stand Linux im letzten Jahr an vierter Stelle, hinsichtlich der Anzahl seiner Installationen. Der Studie zufolge führt Linux sogar, was die Beurteilung durch die Benutzer anbelangt. Auch über den Support äußerten sich die Befragten zufrieden. Eine einzige Einschränkung macht Eckhard Grah vom Wuppertaler Rechenzentrum: "Zugegeben, es gibt keine Telefonnummer, um die nette Dame einer Hotline anzurufen."
Literatur
[1] Milz, H.: Linux inside; iX 8/1995, Seite 36, Verlag Heinz Heise, Hannover, 1995
[2] Winterer, Dr. V.-H. und andere: Linux-Magazin, 1/1998, Seite 72, Linux-Magazin-Verlag, München, 1998