Diskless XTerminals unter Linux

I. Client/Server-Systeme im Studinetz in Göttingen

II. Bootp/Dhcp und das Etherboot-/Netboot-Package

III. Einrichtung und Betrieb der XTerminals

IV. Weiterführende Links

I. Client/Server-Systeme im Studinetz in Göttingen

0.Intro

Aktuelle Informationen zum Thema: Auf "GOE.NET | Anleitungen"!

Dieser Artikel ist ein Update des Textes zu Linux-XTerminals, wie er in der Augustausgabe des Linuxmagazins abgedruckt wurde. Die aktuellste Version ist bitte über die Anleitungsseite

dieses Webservers zu beziehen.

Ein Beispielfilesystem für die X-Terminals kann hier heruntergeladen werden. Eine ältere Version steht an dieser Stelle zur Verfügung.

Die Internet-AG des Studentenwerks, die an der Universität Göttingen die Internet-Grundversorgung für die Studierenden leistete, stand vor der Aufgabe, mehrere dezentrale internetfähige Arbeitsräme und -plätze auf dem Campus einzurichten. Die finanziellen Aufwendungen und der spätere Administrationsaufwand sollten sich in Grenzen halten, da auch die hiesige Universität nur über sehr wenig freie Finanzmittel verfügte. Unter dem Kosten- und Administrationsaspekt fiel eine Lösung ala Windows-NT oder Windows95/98 sofort aus, auch andere kommerzielle Netzwerklösungen konnten nicht zum Einsatz kommen. Deshalb besannen wir uns auf das inzwischen schon recht alte, in Netzwerkumgebungen aber immer noch sehr geeignete Prinzip des X-Terminals zurück. X-Terminals sind Minimalrechner, die analog zu den bekannten Terminals der Mainframe-Zeit eine Bildschirmausgabe und eine Tastatureingabe ermoglichen. Hierbei beschränkt sich das System nicht mehr nur auf eine Textausgabe, sondern ermöglicht inzwischen Grafikdisplays, wie sie von klassischen Workstations bekannt sind; bei immer noch beachtlicher Geschwindigkeit. Als Betriebssystem wurde daher Linux gewählt, da es zum einen kostenlos verfügbar ist, auf der anderen Seite sich sehr flexibel an Netzwerkumgebungen anpassen läßt. Gleichzeitig soll dem Umstand Rechnung getragen werden, dass an den meisten Arbeitsplätzen keine Betreuung geleistet werden kann, d.h. dass wenn das System stehenbleibt, abstürtzt etc. das 'normale Userverhalten' zur Reaktivierung ausreicht. Bei einem linuxbasierten NFS-Filesystem, welches read-only gemountet wird, bereitet es kein Prolem, wenn ein User ein Reset auslöst oder den Ausschalter betätigt. Dieses wird durch die Broadcastfähigkeit der X11-Clients (entweder direkt oder über einen Host-Chooser) bzw. Bootp-Protokolle, die nachfolgend eingehender betrachtet werden, sichergestellt. Inzwischen wird dieses zuerst in einer Studierendenumgebung getestete System auch im Mathematischen Institut der Universität Göttingen eingesetzt, da dort eine Reihe älterer SW-XTerminals ausgetauscht werden mussten.

1. Anforderungen an die Arbeitsplätze

An den Arbeitsplätzen sollten die BenutzerInnen vorkonfigurierte Grafikoberflächen vorfinden, mit denen alle Internetdienste ohne weiteren Einstellungen sofort einsetzbar sind. Die X-Terminals sind ein Teil dieser Verinfachungs- und Vereinheitlichungsstrategie, da sie einen dezentralen Zugriff auf wenige zentrale Server erlauben. Dadurch soll der Beratungs- und Einweisungsaufwand vor Ort gering gehalten werden. Später sollen diese Programme um diverse Officepakete erweitert werden.

2. Aufbau des Studierendennetzes in Göttingen

Das Kernstück des Studierendennetzes in Göttingen besteht aus einem zentralen Authentifizierungs- sowie einem Fileserver mit den Homeverzeichnissen und den persönlichen Konfigurationsdateien der einzelnen BenutzerInnen. Auf diesem und weiteren Linux-Servern werden die Grunddienste, wie Mail, WWW (private Seiten der UserInnen) und News vorgehalten.

Von diesem zentralen Server aus, werden alle dezentralen Terminalserver per NIS (dem Network Information Service zur Userauthentifizierung) und per NFS (dem Networkfilesystem, das die Homeverzeichnisse enthält) mit allen notwendigen Benutzerdaten versorgt. So sind relevante Benutzerdaten vor Ort obsolet womit sich der Konfigurationsaufwand dieser Rechner auf die angebotenen Applikationen beschränkt. Die Userhomeverzeichnisse und der Teil des Verzeichnisbaumes, der Manpages und Dokumentation bereithält wird durch den Automounter eingebunden.

Die Server für die Terminals verteilen sich über den gesamten Campus der Universität und hängen alle über Switches vor Ort in dem gemeinsamen VLAN des Studinetzes, welches im Backbone-Bereich mit mindestens 100Mbit arbeitet. An diesen Switches sind, zum Teil über HUB's, die Terminals an 10Mbit-Ports angeschlossen.

Auf den Terminalservern laufen alle Benutzerprozesse, wie der Webbrowser, das Mailprogramm, der Chatclient, das Officepaket etc. Die X-Terminals booten dabei als Diskless-Workstations per Bootp-Request von einem verfügbaren Terminal-Server und bekommen von diesem das Authentifizierungsfenster eines der antwortenden X11-Windowserver bereitgestellt oder starten einen Chooser, in dem alle verwendbaren Server angezeigt werden. Durch eine X11-Broadcast-Anfrage antwortet (hoffentlich) der nächste bzw. am schwächsten belastete Server. Im Chooser melden sich verfügbare Server mit ihrer Userzahl und Systemlast. Dadurch verringert sich das Ärgernis von Systemausfällen für die Benutzerin. Bleibt ein Server im Nutzerbetrieb stehen, wird durch ein Neustart des Terminals sichergestellt, dass weitergearbeitet werden kann. Somit bleiben die Terminals auch bei Teilausfällen im Netz immer noch benutzbar.

Hieraus können aber Probleme resultieren, die sich im XDMCP und der Netzwerkstruktur begründen. Beim Broadcast eines Terminals antwortet nicht unbedingt der am wenigsten belastete Server. Gerade beim gleichzeitigen Start vieler Terminals steht die Belastung eines Servers noch nicht fest. So kann man sich statt des einfachen Broadcastes vorstellen, dass das Terminal deshalb eine Chooseranfrage an sich selbst stellt und dieser Chooser per Broadcast aus dem Netz die Server ermittelt oder auf eine vorgegebene Serverliste zurückgreift.

3. Hardwareanforderungen an die Terminals

An die X-Terminals werden (aus heutiger Sicht :-)) kaum Hardwareanforderungen gestellt: 486DX66 mit 16MB und einer 2MB-Grafikkarte mit einem 15-17"-Monitor erlauben bereits ein gutes und zügiges Arbeiten unter einer grafischen Oberfläche. Zum Jahreswechsel 1998/99 wurde für eine Grundkonfiguration eines solchen Arbeitsplatzes weniger als 1000DM (WinChip 200Mhz auf einen Intel-VX-Board mit 2MB S3 Grafikkarte, NE2000-kompatible PCI-Netzwerkkarte und 17" Monitor) ausgegeben, da auf Festplatten, CD-Laufwerke und Floppydrives verzichtet werden konnte. Konfigurationen mit geringerer Prozessorleistung, 12MB und geringerer Farbtiefe (8bit) sind auch lauffähig und aus älteren Beständen noch im Einsatz. Wobei es hier durchaus zu Beeinträchtigungen in der Laufzeitstabilität durch wachsende Speicherallokation des X-Servers kommen kann.

Trotz anspruchsvoller und intuitiver Oberfläche, wie dem KDE/GNOME (X11 Windowmanager, die sich am CDE und anderen modernen Grafikoberflächen orientieren) und größeren Applikationen, wie das Unix-Offic-Paket Applixware und Netscapes Communicator, genügt die beschriebene Hardwarekonfiguration, die unter einem neüren NT als hoffnungslos veraltet gilt und zu langsam verschrottet werden müßte. Die Kombination aus KDE, Netscape und StarOffice ermöglicht ein ähnliches Arbeiten wie unter Windows, mit dem Vorteil, daß die Programme zentral administriert und konfiguriert werden können. Im universitären Bereich lohnt es sich, bei Software auch Wege jenseits der ausgetretenen Pfade zu beschreiten. Gerade bei der notorischen Finanzknappheit der öffentlichen Einrichtungen stellt Linux eine mehr als brauchbare Alternative dar.

4. Hardwareanforderungen an die Server / Ausbau bei neuer Software

Linux ermöglicht durch dieses Network-Computing, ein Schlagwort, welches im Zuge des Administrationsaufwandes der Einzelplatzrechner und der damit verbundenen Kosten (Total Cost of Ownership), immer wieder genannt wird, die Weiterverwendung der vorhandenen Hardware ohne Restriktionen des Bedienungskomforts und der Geschwindigkeit. Die meisten Internet-Anwenungen, Officepakete und andere an der Uni eingesetzte Standardsoftware benötigen keine ständig wachsende Grafik-Leistung, wie sonst im Bereich der Spielesoftware zu beobachten.

Der Wettlauf zwischen neuer Software und größeren Hardwareanforderungen, wie ihn das Wintel-Kartell gerne bestimmen möchte, beschränkt sich in diesem Falle auf den Terminalserver.

Bisher bewegte sich die Serverausstattung im Göttinger Studierendennetz zwischen einem Cyrix P166+ mit 96MB und 2*1,2 GB Festplatte für fünf Terminals und zwei Dual-PII- 266 mit 512MB und 4*4 GB Festplatte für 25 Arbeitsplätze. Alle Bauteile sind PC-Standardlösungen, was schnellen und preiswerten Austausch ausgefallener Komponenten gestattet.

Inzwischen bedienen ein weitere Doppel-Prozessor-PC (Intel PII 350Mhz mit 1024MB und DUAL-Celeron 333 mit 512MB)) weitere bis zu 40 Arbeitsplätze. Ein Upgrade dieses Rechners fällt durch das Resourcensharing kleiner aus, als die Summe aller Neuanschaffungen die für 'Aufrüstung' der Einzelarbeitsplätze aufgewendet werden müßte. Die Ausfallsicherheit der Arbeitsplatzrechner wächst durch ihre minimalistische Ausstattung, da stark mechanisch beanspruchte Bauteile, wie Festplatte und Diskettenlaufwerk wegfallen können. Dadurch können diese Systeme auch an wenig bewachten Orten stehen, da ein PC ohne Disketten- und CD-Laufwerk ein geringeres Diebstahlrisiko beinhaltet.

5. Administrationsaufwand

Auch beim Administrationsaufwand erweist sich dieses System als sparsam, da Software-Updates für die X-Clients automatisch für alle Geräte auf einmal erfolgen. Generell sind alle Terminalserver mit einer gleichartigen Grundkonfiguration versehen, was ein einfaches Kopieren von Updates von einem Gerät zum anderen erlaubt.

Die Betriebssicherheit in diesem Netz kann durch den Einsatz weiterer Server erhöht werden. Durch die X- und Bootp- Anfragen als Braodcasts ist ein für den User unbemerkter Wechsel nach dem Neustart des Terminals bei Ausfall eines Gerätes möglich.

Dieses Konzept erlaubt weiterhin entfernt gelegene Terminalpools, da aufgrund der geringen Zahl der Verschleissteile die Ausfallwahrscheinlichkeit sinkt. Die Chance eines Hacker-Einbruchs in die Terminal-Systeme ist als sehr gering einzuschätzen, da nur ein sehr reduziertes Filesystem mit geringen Rechten und keine zusätzlichen Netzwerkdienste zur Verfügung stehen.

6. Einsatz in bestehender Infrastruktur

Ein großer Vorteil der verwendeten Konfiguration liegt in der Möglichkeit, diese parallel mit bestehenden Systemen zu betreiben. So kann in den zumeinst mit älteren Geräten ausgestatteten Rechner-Pools der Universität die beschriebene Lösung einfach in bestehende Netzwerkstrukturen eingegliedert werden. Das verwendete Bootp-Paket ermöglich eine Multi-Boot-Option, d.h. die Benutzerin kann beim Startvorgang des Rechners darüber entscheiden, welches Betriebssystem gewählt werden soll. So ist es möglich von der Festplatte das überlicherweise verwendete Windowssystem zu booten oder alternativ aus dem Netz ein Minimal-Linux zu starten, welches dann zum X-Terminalserver eine X11-Verbindung aufbaut. Dadurch bleibt die relativ hohe Netzbelastung durch den Export der Arbeitsoberfläche lokal und kann durch einfache Maßnahmen, wie dem Einsatz einer Switch vom restlichen Netz abgeschottet werden.

Der notwendige Eingriff in die bestehenden Systeme beschränkt sich dabei auf den Einbau eines Boot-Roms, das mittels EPROM-Programmierer aus alten Mainboard-Roms gewonnen werden kann. Alle anderen Komponenten können in ihrer Konfiguration übernommen werden. Das installierte Betriebssystem ist durch die geeignete Kernelkonfiguration vor Benutzerzugriffen geschützt. Zusätzlich besteht die Option des seperaten Accountings, wenn die X-Terminals andere IP-Nummern als das ursprüngliche System verwenden. Auf diese Art und Weise läßt sich auch der Zugang zu speziellen Resourcen, wie Druckern, Plottern und Belichtern sperren oder ermöglichen. Verschiedene Benutzerklassen können einfach in ein und dem selben Raum, mit derselben Hardwareausstattung bedient werden.

II. Bootp/Dhcp/TFTP und das Etherboot-/Netboot-Package

0. Intro

Das Bootp-Protokoll und als Weiterentwicklung das DHCP ermöglichen die automatische Netzwerk- und Bootkonfiguration von Clientsystemen. Dazu müssen keinerlei Informationen zu IP-Nummer, Netzmaske etc. auf dem Clientrechner bekannt sein. Dieses ermöglicht eine einfache Anpassung bei Änderungen in der Netzwerkstruktur und erlaubt festspeicherlose Clients und einen leichten Wechsel eines Gerätes zwischen verschiedenen Netzen. Die eleganteste Lösung für X-Terminals (auf Basis von Standard-PC-Hardware) besteht in der Installation eines Boot-EPROM's auf der Netzwerkkarte. Der Terminals werden in anhand ihrer Hardwareadresse der Netzwerkkarte (MAC) identifiziert.

1A. Das Bootp-Protokoll

Bootp ist ein UDP-basiertes Netzwerkprotokoll, über das grundsätzl Daten zur Konfiguration eines Clientsystems übertragen werden können. Die einzelnen Parameter werden untenstehend im Zusammenhang mit den beiden existierenden Implementationen erläutert. Ein Teil der Informationen, die bereitgestellt werden, übernimmt der Kernel schon durch den Bootp-Prozess, der vom EPROM gestartet wird. Hierzu gehört die IP-Konfiguration mit Netzmaske und Standardgateway. Die Informationen zur DNS-Auflösung werden später gesondert angefragt. Testen kann man beide Bootp-Dienste durch den Befehl bootpc -hwaddr [MAC des Terminals]. Für diesen Test und den Aufruf des dhcpcd für die DNS-Konfiguration sind bestimmte Kerneloptionen notwendig.

1A. Die Implementation als bootpd

Die Parameter des bootpdlassen sich am besten anhand der /etc/bootptab, der zentralen Konfigurationsdatei des bootpd erläutern:

(Kommentare sind mit '#' gekennzeichnet.)

.default:\ # es können mehrere Profile definiert werden
:td=/boot/:\ # TFTP Rootverzeichnis
:hd=/boot/:\ # Homeverzeichnis des Bootfiles
:rp=/boot/root:\ # RootPath für das exportiere NFS-Verzeichnis
:bf=bootimg:\ # BootFile, das Image des Kernels
:ht=ether:\ # Hardwaretype (Ethernet)
:sm=255.255.0.0:\ # Netmaske (hier Class-B)
:gw=172.16.98.254:\ # Gateway
:ns=172.16.98.1:\ # Nameserver
:dn=your.domain:\ # Domainname
:vm=rfc1084:\ # Vendor Magic
:hn:to=-18000: # Hostname übergeben: TimeOut

terminal01:tc=.default:\ # verwende '.default' Profil
:ha=0020AF5733BB:\ # MAC-Adresse der Netzwerkkarte des Terminals
:ip=172.16.189.111: # zuzuweisende IP-Adresse für das Terminal

Wenn für alle Terminals die gleichen Parameter gelten, könnten diese in einer gemeinsamen Konfiguration definiert werden (hier .default). Es können auch mehrere solcher Konfigurationen angegeben und mit dem 'tc'-Feld entsprechend zugewiesen werden. Sehen die Konfigurationen für die einzelnen Terminals sehr verschieden aus, werden diese hinter dem Namen des Terminals (hier terminal01) angegeben. Der Zeilenumbruch wird durch das '\' versteckt, es erleichtert die Lesbarkeit. Alle Felder müssen mit Doppelpunkten voneinander getrennt sein. Als weitere Optionen können Timeserver, YP-Server & Domain ... übertragen werden.

Dabei muss bedacht werden, dass das Bootp-UDP-Paket nur eine bestimmte Menge an Informationentransferieren kann, d.h. nicht alle dargestellten Optionen auf einmal übertragen werden können.

Die Felder für das TFTP (Trivial FTP, sehr abgespecktes FTP-Protokoll) weisen schon auf eine weitere Funktion hin, die in der beschriebenen Konfiguration benötigt wird, aber nicht zwingend gemeinsam mit Bootp verwendet werden muss...

Leider gibt es in unserer Umgebung in Abständen Probleme mit dem TFTPD auf Serverseite, so dass für einige Zeit einige Bootp/TFTP-Server den Kernel nicht übertragen und sich das ganze in einer Fehlermeldung:
loading /boot/bootimg ... XXX .sleep. äussert. Deshalb experimentieren wir gerade mit dem neueren (und verbesserten) TFTPD des Netbootpaketes herum. Mit diesem sehen wir die beschriebene Fehlermeldung seltener, dafür beendet sich der Prozess nach Übertragung des Bootkernels in vielen Fällen nicht korrekt unabhängig von der verwendeten (x)inetd-Implementation. Beim NILO-Paket findet man eine Standalone-Implementierung des TFTPD. Diese verhält sich in Tests bisher am zuverlässigsten.

1B. Implementation als dhcpd

Sollte es notwendig viele Optionen an die Clientsysteme zu übertragen, empfielt sich der Einsatz des dhcpd, der auch über eine umfangreichere Palette an Optionen verfügt. Für Server, die eine Mischumgebung aus Windowsystemen mit dynamischer IP-Zuweisung und X-Terminals bestehen, kommt nur noch DHCP in Frage. Weiterentwicklungen finden in erster Linie beim dhcpd statt, die verwendeten bootdp Implementationen stammen aus den Anfängen der 90er und werden nur noch im Falle grober Sicherheitslöcher gepatcht. Das Internet-Software-Consortium entwickelt z.B. eine Beispielimplementation des DHCP und einiger anderer Internetprotokolle. Der Sourcecode liegt in dem meisten Fällen auch in einer Linuxanpassung vor.

Die Konfigurationsdatei des dhcpd sieht wie folgt aus:

# -- global options --
server-identifier dhcpd-server.your.domain;
option domain-name "your.domain";
filename "/boot/bootimg";
use-host-decl-names on; # damit die Terminals den Hostnamen übertragen bekommen
subnet 172.16.0.0 netmask 255.255.0.0 {
option domain-name-servers 172.16.24.1, 172.16.10.46; # DNS
option netbios-name-servers 172.16.63.252; # Netbios, falls auch Windowssysteme von diesem Server booten
option routers 172.16.98.254;
option broadcast-address 172.16.255.255;
}

# -- client specific --
host terminal01 {
hardware ethernet 00:20:AF:57:33:BB; # MAC-Adresse
fixed-address 172.16.189.111; } # zuzuweisende IP-Adresse für das Terminal

Die meisten Optionen sind selbsterklärend. Der dhcpd ist vielfältig konfigurierbar, so dass z.B. eine dynamische Adressvergabe für Windowsrechner und eine statische Bootkonfiguration für die Terminals von einem Server aus erfolgen können. Der Dhcpd läuft am besten als Stand-Alone-Prozess, wobei darauf geachtet werden sollte, dass dann der bootpd in der /etc/inetd.conf auskommentiert wurde.

2. Das TFTP-Protokoll

Das TFTP dient zum Transfer des zu bootenden Netzkernels (welche Optionen dieser enthalten muss und wie man ihn mit einer entsprechenden Bootsignatur versieht, wird in den folgenden Abschnitten erklärt). Das Protokoll muss neben der Bootp-Implentation auf ein 16k bzw. 32k EPROM passen, welches auf die Netzwerkkarte des (plattenlosen) Terminals gesteckt wird, und ist deshalb sehr klein gehalten. Es bietet keinen Schutz durch Passwortauthentifizierung und sollte deshalb mit Vorsicht aufgesetzt werden. Eine Absicherung des TFTP-Transports hat Werner Koch geschrieben. Dabei kann zum einen durch das Boot-Protokoll ein TFTP-Root angegeben werden, was einen Zugriff auf die Root-Ebene des Servers verhindert.Auch beim Aufruf des Dämons in der /etc/inetd.conf kann ein Root-Verzeichnis angegeben werden:

(Ausschnitt der /etc/inetd.conf)
[...]
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd /boot
bootps dgram udp wait root /usr/sbin/bootpd bootpd -c /boot
#
[...]
oder: (Ausschnitt der /etc/xinetd.conf)
[...]
# disabled = bootps
# disabled = tftp
[...]
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = nobody
only_from = 134.76.0.0
server = /usr/sbin/in.tftpd
server_args = /boot
}

service bootps
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/bootpd
server_args = -c /boot
}

3. Konfiguration des Servers

NFS-Konfiguration

Im vorgestellten Falle dient der Bootp-Server auch gleichzeitig als NFS-Server für das Root-Filesystem unserer XTerminals. Im Kernel wird dafür die Option '[*] Root file system on NFS ' aktiviert (weitere Optionen auch weiter unten). Damit versucht das Terminal nach dem Start des Kernels sein Filesystem vom Server zu mounten (siehe hierzu auch die mknbi-Optionen).

Damit dieses gestattet wird, sollten zum einen die beiden NFS-Daemonen (rpc.nfsd und rpc.mountd) auf dem Server installiert und aktiviert sein. In der /etc/exports werden die Freigaben eingetragen:

/boot/root 172.16.0.0/255.255.0.0(ro)

Im Beispielfalle befindet sich der NFS-Root-Tree unter '/boot/root'. Aus Sicherheitsgründen wird das Filesystem nur ReadOnly exportiert, für Testzwecke empfielt sich aber die Einstellung ReadWrite mit Root-Zugriff (rw, no_root_squash). Wenn als NFS-Server eine abweichende Hardware- bzw. Softwareplattform zum Einsatz kommt, ist zu überprüfen, ob das Deviceverzeichnis (/dev) der Terminals komplett richtig mit Major- & Minornummern übertragen wird. In einer Umgebung aus DEC-Alpha-Stations (DEC-Unix und RedHat-Linux) gelang dieser Export bisher nicht sauber.

Bootp/TFTP-Konfiguration

...erfolgt in der Datei /etc/inetd.conf, wobei in den meisten Fällen nur für die beiden im verherigen Abschnitt gezeigten Zeilen die Kommentierung entfernt und der Datenpfad angepasst werden muss. Danach sollte der inetd neu gestartet werden.

4. Erstellen des speziellen Linux-Kernels

Damit der Linux-Kernel in der beschriebenen Umgebung aus dem Netz gebootet werden kann, sind einige Einstellungen erforderlich:
(Nur Auszüge der .config im Kernelverzeichnis Kernel-Version 2.2.10)
[...]
CONFIG_BLK_DEV_RAM=y
[...]
CONFIG_PACKET=y  # notwendig für dhcpcd Anfrage
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
[...]
CONFIG_IP_PNP=y
[...]
CONFIG_NFS_FS=y
CONFIG_ROOT_NFS=y
[...]
Erstere Option ermöglicht die Ramdiskunterstützung. Hier habe ich im Sourcecode die Grösse auf 128k (Standard sind 4MB) reduziert, weil nur sehr wenige Kilobyte benötigt werden. Die weiteren Einstellungen starten die Kernel IP-Autokonfiguration, die letzten legen das Rootfilesystem auf das NFS fest.

Zum Schluss muss das zImage mit einer speziellen Bootsignatur versehen werden:
mknbi -k zImage -o bootimg -d /boot/root -i rom
Die Optionen geben nacheinander das Kernelfile, das Outputfile (der dann netzbootfähige Kernel) und das NFS-Root an. Die letzte Option übergibt dem Kernel die Information, dass er seine IP-Konfiguration über die Bootp-Anfrage des Bootroms bezieht. Das mknbi stammt aus dem Netbootpaket. Hier sollte immer die aktuelle Version verwendet werden, da sonst evtl. Schwierigkeiten beim Starten des Kernels durch das ROM auftreten könnten. Ein mknbi passend zur Version 4.2.1. des Etherbootpaketes liegt im /sbin Verzeichnis des Terminalbaumes.

5. Netzwerkkarten

Es gibt eine Reihe von Netzwerkkarten, die vom Etherboot-Paket unterstützt werden. Dazu gohören die NE2000 und kompatiblen in der ISA und PCI-Version, bis hin zu den 100Mbit-Typen mit dem RTL 8139 oder Tulip Chipset, die 3COM 503 und 509, die WD8003 und 8013 kompatiblen. SMC-Ultra-Karten, die Davicom 9102 sowie bestimmte Tulip-Chip-basierte Modelle sind auch einsatzfähig. Die Netzwerkkarte sollte einen Sockel für das Bootrom enthalten und eine Bootromgrösse von 16k bzw. 32k unterstützen. Mit einigen Einschränkungen kann man den Code auch für ein 8k Rom erstellen. Sehr gute Erfahrungen machten wir mit allen NE2000 kompatiblen, den SMC und den 3C509-Karten. Von den neueren (100Mbit-Typen) wurden bisher die RTL8139-basierten Netzwerkadapter erfolgreich getestet.

Ein andere Herangehensweise waehlt das Netbootpaket von Gero Kuhlmann. Dieses Paket unterstützt alle Netzwerkkarten, die über einen Packetdriver (freie Implementation auch im Crynwr-Paket) oder einen NDIS-Treiber verfügen. Hierzu bekommt das EPROM einen kleinen Bootblock verpasst, der zürst den Netzwerkkartentreiber und dann Bootp/TFTP aufruft.

Mit diesem Paket funktionieren auch die oben angesprochenen RTL8139-Implementationen (hier wiederum musste man den NDIS-Treiber einsetzen, der auch der Packetdriver nicht funktionierte). Weiterhin lief auch die parallel getestete Karte mit dem DEC-Tulip-Chip (10Mbit und 100Mbit Version).

6. Der Bootcode im Mainboardbios (AWARD)

Einige neuere Boards (meistens All-In-One-Mainboards mit Onboard Netzwerkadapter) besitzen bereits eine BIOS-Option - "Boot from Network", die leider aber nur Novell-IPX unterstützt. Eine Reihe von Boards ist ähnlich erweiterbar: Verfügt das Board über ein Award-BIOS und genügend freien Speicher darin (ca. 9kbyte sind erforderlich), so lässt sich der Netbootcode dem BIOS hinzufügen.

AWARD bietet für OEMs ein Tool "cbrom.exe" an, welches das Hinzufügen und Entfernen von BIOS-Komponenten ermöglicht. Neben diesem Tool benötigt man noch das klassiche Awardflash (awdflash.exe), welches mit dem Mainboard mitgeliefert wird.

Für das AMI-Bios existiert wohl auch solch ein Tool, welches aber nicht allgemein zu Verfügung gestellt wird, weshalb hier noch keine Tests stattfinden konnten.

Voraussetzung dieser Option ist das Vorhandensein von genügend freiem Speicher im BIOS-Flashrom. Dieses bekommt man heraus, indem man den Flashrominhalt mit awdflash.exe in eine Datei schreibt und mit dem Aufruf von cbrom biosdatei /d diese analysiert. Wenn mehr als 9kbyte im komprimierten Speicherblock verfügbar sind, lassen sich die meisten Boot-Codes unterbringen. Evtl. kann man durch Löschen von BIOS-Zusätzen, wie Virenschutz und NCR-SCSI-Unterstützung den benötigten Platz schaffen.

Der Bootcode wird durch das BIOS-Tool komprimiert, so dass man sich nicht darum kümmern muss. Mit cbrom biosdatei /isa netboot.rom D000:0 schreibt man den Boot-Code (netboot.rom) in die BIOS-Datei. "D000:0" gibt den Speicherbereich an, in den der Code beim Start des Rechners dekomprimiert werden soll. Das Tool meldet die Kompressionsrate und beendet sich anschliessend (wenn kein Fehler auftrat ohne weitere Meldung). Das Ergebnis lässt sich mit der zuerst genannten CBROM-Beispielzeile überprüfen. Anschliessend wird die BIOS-Datei mit awdflash wieder ins Flash zurückgeschrieben (Backup des Original-BIOS-Codes anlegen!).

Wenn man den Bootcode direkt im BIOS unterbringt, empfielt sich eine Abfrage, ob lokal gebootet werden soll, da das BIOS nach seinem Hochlauf sofort den Bootcode ausführt. (Befindet sich dieser in einem seperaten ROM, ist es kein Problem dieses im Notfall zu entfernen, mit dem Code im BIOS-ROM entfällt diese Option aber!)

Erfolgreich getestet wurde diese Vorgehensweise mit einem Socket7-All-In-One-Board von PCChips und einem neueren Gigabyte Intel-BX-basiertem Slot1 Board. Beide BIOSse verf&umml;gten &umml;ber ausreichend freien Speicher, da das Flashrom 256kbyte (2MBit Typ 29E020 ...) gross war.

Vorteil dieser Lösung: Alle notwendigen Handlungen können ohne Zusatzgeräte ausgeführt werden. Möchte man auf Nummer Sicher gehen, kann man ein Flash-ROM-Baustein der gleichen Grösse kaufen (ca. 10DM) und nach dem erfolgreichen Booten des Rechners gegen den eingebauten Baustein austauschen (VORSICHT, da dieses bei laufendem Rechner erfolgt). Dann "brennt" man mit dem Flash-Utility den Code in den neuen Baustein und hat den alten als Backup bei Fehlversuchen in der Hinterhand. Für die beschriebene Lösung kann in keinster Weise eine Garantie übernommen werden, auch wenn diese Operation mehrfach mit Erfolg durchgeführt werden konnte!

7. EPROMS / Sonstige Unterbringung des Bootcodes

Lässt sich die eben beschriebene Variante wegen zu alten Boards/BIOS oder zu geringem freien Speicher im Flash nicht anwenden, kann man auf seperate EPROMs ausweichen. Als Eproms können alte BIOS-Steine von Mainboards verwendet werden, so sie ein Fenster zum Löschen des Inhalts besitzen. So können alte 286er Hauptbretter zumindest zum Teil weiterverwendet werden :-) Neu kosten die Bausteine je nach Händler um die 4 bis 10DM. Die Typenbezeichnung für ein 32k EPROM sieht ähnlich 27C256 aus. Gelöscht werden können die klassischen EPROM's mit einer UV-Lampe, die Weiterentwicklung sind elektisch löschbare Bausteine, wie sie für Flashroms auf Mainboards, Grafikkarten oder auch in Modems verwendet werden. Weiterhin muss man sich irgendwo einen EPROM-Brenner organisieren oder mit dem Code jemanden aufsuchen, der so ein Teil rumliegen hat. Rechenzentren, Uniinstitute der Physik oder Informatik sollten soetwas besitzen.

Eine weitere Möglichkeit bietet sich in der Verwendung von EEPROM´s. Dieses sind elektrisch löschbare EPROM´s, wie sie auch auf modernen Mainboards im Einsatz sind. Im später beschriebenen Netboot-Paket ist eine Bauanleitung für eine Flashcard dabei. Diese FLashcard kann in einem ISA-Slot Platz finden und auch dauerhaft anstelle des Boot-ROM´s auf der Netzwerkkarte eingesetzt werden.

In den meisten Fällen ist die Boot-Rom-Option der Netzwerkkarte entweder über die Konfigurationssoftware oder einen Jumper zu aktivieren. Weiterhin muss ein Adressbereich für das ROM ausgewählt werden. In diesem Speicherbereich sollten sich keine anderen BIOSes befinden, was aber auf einem Terminal kaum vorkommen sollte.

Verfügt die Netzwerkkarte über keinen Sockel, so kann der Code auch über eine Floppy gebootet oder auch als Boot-Option z.B. unter Windows9X eingetragen werden. Dazu kann man neben dem ROM-Code auch Code für die Floppy und eine .COM Datei compilieren. Da diese Dateien sehr klein sind, bietet sich hier das Recycling alter 5,25" Laufwerke geradezu an.

8. Das Etherboot-Paket

Derzeit ist die Version 4.2.X aktuell. Diese sollte auf jedem grösserern FTP-Archiv vorhanden sein. Das Paket wird wie üblich entpackt mit 'tar -xlzf etherboot.tgz' entpackt. Es gibt ein umfangreiches Verzeichnis mit Anleitungen in verschiedenen Formaten unter doc/. Die Verzeichnisse src-16/ bzw. src-32/ enthalten die Dateien zur Erzeugung des Codes für 16k (128k-1) bzw. 32k (256k-1) Eproms. Nach dem Aufruf von 'make' erhält man für jeden Typ Netzwerkkarte ein *.rom und *.bin Image, wobei ersteres später in das Eprom gebrannt wird. Im Netbootverzeichnis (hier: netboot-0.7.3) liegt der Code für das 'mknbi' (-linux). Zürst werden hier mit 'configure' eingige Anpassungen vorgenommen, dann mit 'make' der Code erzeugt.

9. Das Netboot-Paket

Die neüste Version ist die 0.9, welche nun auch die Komprimierung grosser (Packet/NDIS-) Treiber unterstützt. Die maximal unterstützte EPROM-Grösse ist zur Zeit 64k (27C512). Dieses Paket liegt als TGZ vor, muss entpackt, danach mit ´configure´ angepasst und anschliessend mit ´make´ kompiliert werden. Ein ROM-Image (hiermit wird automatisch auch ein Floppyimage zu Testzwecken erzeugt) erstellt man durch ´make bootrom´. Wenn die benutzte Netzwerkkarte nicht in der umfänglichen Liste (zur Zeit 129 Einträge), sollte der Pfad zum Paket- oder NDIS-Treiber der Netzwerkkartendiskette (und die Vendor und PCI-ID, angezeigt am Ende des Bootvorganges, bevor das OS geladen wird) bekannt sein. Anschliessend kann das eine erzeugte Image mit der Endung .flo auf eine Diskette (dd if=image.flo of=/dev/fd0) kopiert und im Terminal getestet werden.

10. Das NILO-Projekt

NILO steht für Network Interface Loader und soll das Booten von Linux/BSD und den Windozen erlauben. Dieser Loader ist die Weiterentwicklung beider vorher beschriebenen Pakete und soll durch die Verwendung der Linux-Kerneltreiber jede von Linux unterstützte Netzwerkkarte benutzen können. Dieses Paket befindet sich noch in der Entwicklung und ist noch nicht in jedem Falle einsatzfähig.

III. Einrichtung und Betrieb der XTerminals

0. Intro

Die XTerminals basieren auf der Suse6.2 Linuxdistribution und verwenden einen Kernel der 2.2er Version. Die Software des Bootvorganges wurde an die besonderen Gegebenheiten (readonly NFS) und Erfordernisse (bestimmte Zusatzdienste) angepasst. Ein Beispiel-TGZ (Suse60)(welches derzeit ca. 60MB (28 komprimiert) umfasst) liegt hier auf diesem Server, wobei natürlich einige Anpassungen an die lokalen Konfigurationen unumgänglich sind. Die neue Version basierend auf Suse6.2 kann hier heruntergeladen werden. Diese befindet sich aber noch in der Erprobungsphase. Neben dem Terminalhauptverzeichnis (in diesem Falle 'root' genannt) enhält das Paket auch einen Beispielkernel (V2.2.12 mit Unterstützung für 3C509, NE2000 ISA/PCI, RTL 8139 und SMC-Ultra). Alle Angaben von absoluten Dateinamen beziehen sich auf das NFS-Root, d.h. so wie sie im Verzeichnisbaum auf dem Terminal sichtbar sind. Auf dem Server ist entsprechend das NFS-Root hinzuzufügen, wobei man bei symbolischen Links etwas aufpassen sollte, da diese hier natürlich von den Bedingungen des XTerminals abweichen. Der Umfang der Terminalinstallation lässt sich weiter reduzieren, in einer älteren Version basierend auf Suse4.2 wurden lediglich 20MB benötigt (bei geringerem Funktionsangebot). Gleichzeitig soll die Unterstützung verschiedenartiger PC-Hardware sichergestellt werden. Die Terminals sollen am Ende mehrere Aufgaben erfüllen (können):

Bereitstellung des XServers (für das Graphik Login)

Ermöglichen eines Logins an der Console (zumindest für Root)

Zugriff auf Blockdevices (Floppylaufwerk, evtl. ZIP/CDRom)

1. XDisplay

Die Hauptaufgabe der Terminals besteht in der Bereitstellung der Grafikconsole, wobei je nach Erfordernis entweder die Server per Broadcast oder per indirektem Broadcast über einen Chooser ausgewählt werden sollen. Broadcast stellt sicher, dass solange mindestens ein Server läuft, immer ein Login angeboten wird. In der /etc/rc.config (zentrale Suse-Konfigurationsdatei) kann hierzu als Startoption für das Display "broadcast" oder "indirect" eingetragen werden.

Wenn ein Chooser gewünscht wird, verbindet sich das Terminal mit sich selbst ($HOSTNAME in der /usr/X11R6/bin/xrun), wobei dann der lokale xdm die Broadcastanfragen übernimmt und im chooser darstellt. So wird auch in dieser Einstellung eine Abhängigkeit von einem bestimmten Server vermieden. Hierfür muss in der /etc/rc.config die Aktivierung des xdm erfolgen. Dieser übernimmt nur das Management der xdmcp Anfragen, kümmert sich aber nicht um die Verfügbarkeit des lokalen Displays. Diese erfolgt über ein spezielles Skript zur Auswahl der richtigen Hardwareeinstellungen (Beschreibung im nachsten Abschnitt). Die Xaccess Datei (/usr/lib/X11/Xaccess) lässt dabei nur die Anfrage des Choosers zu, auf einen Broadcast anwortet das Gerät selbst nicht, da es weder mit Serverfunktionionalität ausgestattet wurde, noch die Hardware diese in den meisten Fällen zulässt.

2. XServer (Hardwareauswahl)

Ziel der Konfiguration der Gesamtanlage war es, für alle Terminals denselben NFS-Root-Baum zu verwenden, um einen möglichst geringen Administrationsaufwand sicherzustellen. Anpassungen für die Hardware der Grafikkterminals erfolgen an zwei Stellen:

im Kernel; hier muss die richtige Netzwerkkarte, die PS2-Schnittstelle bzw. die seriellen Schnittstellen bereitgestellt werden (siehe dazu die Ausführungen im Abschnitt II).

beim Start des entsprechenden XServers (SVGA, Mach64, S3(V) ... ) mit den Anpassungen für den Monitor und dem geeigneten Link auf das Mousedevice (/dev/ttyS0(1) oder /dev/psaux).

Diese Auswahl geschieht in der Datei xrun im Verzeichnis /usr/X11R6/bin, in dem auch die verschiedenen Grafikkartenserver liegen. In dieser Datei wird anhand des Terminalnames entschieden, welcher Grafikkartenserver in Kombination mit welcher X11-Konfigurationsdatei (alle in /etc: XF86Config.S3 ...) ausgewählt wird. Das ganze geschieht über eine einfache CASE-Anweisung anhand des Hostnames. Gleichzeitig sorgt diese Datei für den Restart des X11, so es sich beendet haben sollte oder abstürzte.

Auf diese Weise können ohne Probleme neü Terminals ins Netz eingefügt werden, bei Bedarf wird eine weitere Auswahlspalte in der xrun hinzugefügt. Mit diesem Konzept wird eine Hardware-Breite von 486DX66 (mit 12MB und 1MB Grafikkarte am 14"-Monitor mit 1024x768 im Interlace-Modus) bis hin zum WinChip200 (mit 32MB und 4MB Grafikkarte am 17"-Monitor mit 90Hz Bildwiederholfreqünz) abgedeckt.

Soll auf dem Client selbst ein XDM mit einem Chooser für das Gerät laufen, so sind mindestens 12(16)MB vorzusehen, da f&uul;r XDM und Chooser weitere Libraries in den Speicher laden (ca. plus 3 (Standard-XFree-Chooser) - 4 MB (khostchooser), je nach Auswahlfenster). Da aber der X-Server nach jedem Auslogvorgang neu gestartet wird, besteht kein Konflikt im Speicherverbrauch, da in dem Moment, wo der Xserver mehr Speicher alloziert (für Farben, Fonts ...) der Chooserprozess sich bereits beendete.

Sollen mehr darstellbare Farben angezeigt werden (die vorgestellte Implemetation verwendet 16bit Farbtiefe, bei älteren Karten 8bit) oder soll die Bildschirmauflösung steigen, so muss mit einem höheren Speicherbedarf für den XServerprozess kalkuliert werden.

3. Der Bootvorgang

Aus Sicherheitsgründen soll das NFS-Root-Verzeichnis aller Terminals nur ReadOnly vom Server bereitgestellt werden. So wird verhindert, dass bei der unumgänglich grosszügigen Class-B-Netz-Freigabe, keine Veränderungen am Filesystem der Terminals (durch Externe ohne Zugriff auf den Bootp-Server) vorgenommen werden können. Eine explizite Freigabe einzelner IP-Nummern oder recht enger Bereiche in der /etc/exports ufert sehr schnell aus und bietet auch keine Sicherheit gegen Missbrauch der IP, wenn ein Terminal offline ist. Eine Einschränkung in der Sicherheit stellt die notwendige Dateifreigabe im all-readable Modus dar oder wahlweise die NFS-Option 'no_root_squash'.

Als allererster Vorgang wird eine RAM-Disk angelegt und mit dem Minix-Dateisystem versehen und danach RW gemountet. Im Beispielfalle umfasst die Ramdisk 512kByte (hartkodiert bei der Kompilation des Kernels). Anschliessend wird aus dem RO-NFS-Bereich (hier /var/ram ) der Teil des Dateisystems, der RW-Zugriffe gestatten soll, in die RAM-Disk kopiert. Diese Bereiche umfasst das /dev Verzeichnis (in erster Linie für die Zugriffe auf die Terminaldevices tty1 (-tty6)), ein Teil des /var Verzeichnisses (z.B. 'run' für das Schreiben des utmp-Files, tmp für die X11-Locks, den Tastaturkompiler und die /etc/resolf.conf). Dateien im restlichen Verzeichnisbaum, auf die Schreibzugriffe notwendig sind (/etc/adjtime) oder Dateien, die beim ersten Mount unsichtbar bleiben sollen (/etc/mtab), werden geeignet in die RAM-Disk verlinkt.

Anschliessend erfolgt die Konfiguration der DNS-Auflösung durch den Aufruf von dhcpcd -H -D, welcher die /etc/resolv.conf in der RAM-Disk mit der konkreten Bootumgebung überschreibt.

Danach sieht das Bootskript (/sbin/init.d/boot) wieder vergleichbar zur Standardkonfiguration aus, wobei alle unnötigen Vorgänge (Filesystemchecks, Swap etc.) entfernt wurden. Der Start bestimmter Dienste wird weiterhin durch die rc Skripten und die geeignete Verlinkung dieser in den INIT-Leveln (sbin/init.d/rcX.d) sowie durch die /etc/rc.config sichergestellt. Die Netzwerkkonfiguration entfällt dabei, da diese bereits über die Bootp-Parameter (siehe Abschnitt II) erfolgte.

4. Console/SSH-Remote Login

Diese Feature wird nicht unbedingt zum Betrieb des Terminals benötigt und kann in der /etc/inittab abgeschaltet werden. Es ermöglicht aber ein umfangreiches Debugging und das Studium des Systemverhaltens. Weiterhin können so neü Funktionen implementiert werden, ohne dass man nur auf die teilweisse dürren Fehlermeldungen, die auf dem Schirm des Terminals erscheinen, angewiesen wäre. Das Login am Terminal erweist sich als sehr nützlich, wenn man z.B. den Prozessstatus oder die RAM-Auslastung feststellen möchte. Das Console Login steht in der vorliegenden Konfiguration nur dem Super-User zur Verfügung, wobei natürlich auch über die Bootp-Konfiguration NIS-Daten verfügbar gemacht werden könnten.

Weiterhin kann durch Setzen der entsprechenden Option in der /etc/rc.config der SSHD gestartet werden, was ein erleichtertes Remote-Debugging erlaubt. Es sollte jedoch daran gedacht werden, dass jeder zusätzliche Prozess Speicherplatz benötigt und es somit auf knapp dimensionierten Terminals knapp werden kann.

5. Debugging

Ein Logfile schreibt das Terminal nicht, es wäre aber natürlich möglich es remote an einen Syslogserver übertragen zu lassen. Da aber keine wichtigen Netzwerk und Logindienste (ausser der Konsole) zur Verfügung stehen, schien mir die Ueberwachung in diesem Falle nicht notwendig. Wer es dennoch einschalten möchte, kann die Option "LOGGING" in der /etc/rc.config Datei auf "yes" setzen. Alle Veränderung des Filesystems gehen mit einem Neustart verloren, so dass auch hierüber keine Statusmeldungen notwendig erschienen. Die recht komfortablen Startmeldungen der Suse-Implementation geben schon beim Start einen guten Ueberblick. Durch Zurücksetzen des Default-Runlevels auf '2' (in der /etc/inittab) lässt sich die Bildschirmausgabe gut beobachten und interpretieren und bei Bedarf ein weiteres X (z.B. bei neür Hardware) einrichten...

6. Zusatzdienste

Alle Terminals der geeigneten Hardwareausstattung (in diesem Falle ausreichend CPU-Leistung) beteiligen sich am RC5DES Kontest, da die Bereitstellung des X (und evtl. des XDMCP Chooser) viel Rechenpower ungenutzt lässt.

Auch diese Option lässt sich über die /etc/rc.config ein- und ausschalten, der Start abhängig von der Hardwareleistung kann analog zur xrun Datei (siehe 2.XServer) erfolgen. Ergeben sich gut parallelisierbare Probleme (wie z.B. im Linux-Cluster) oder für einige mathematische Anwendungen, lassen sich diese Maschinen im Hintergrund auch für solche Projekte konfigurieren und nutzen.

7. X11-Zugriff auf Nicht-Linux Server

Der verwendete XFree-Server unterstützt einen Keybordcompiler. Auf diese Weise kann on-the-fly eine Anpassung der Tastatur an unterschiedliche X11-Plattformen geschehen. Dafür verwendet der Keybordcompiler ein Verzeichnis in der Ramdisk, in dem die Tastaturanpassungen abgelegt werden. So funktionierte die Tastaturanpassung bei einem Connect auf ein DEC-Alpha-System ohne Problem, bei SUN (Solaris) und IBM-AIX mit kleinen Einschränkungen. Die Probleme aus der Zeit der klassichen X-Terminals mit kryptischen Anpassungen der XKeysymDB und Konsorten entfallen dadurch in den meisten Fällen.

8. Ausblicke

Inzwischen erhöhte sich die Zahl der eingesetzten Terminals auf knapp 100. Weitere Institutionen denken darüber nach, dieses System auch für eigene Angebote zu nutzen. Inzwischen erhalten die neueren Terminals eine 100Mbit Netzwerkkarte, da die Preisunterschiede zu den 10Mbit-Karten bei der Beschaffung nicht ins Gewicht fallen. Auch wenn sich die Zahl der standalone betriebenen Arbeitsplätze erhöht, wird das Konzept der Terminals wegen ihres geringen Wartungsaufwandes und ihrer geringen Kosten beibehalten werden. Inzwischen gibt es Überlegungen über diese Terminals weitere Angebote, wie bestimmte Univerwaltungsdienste (Immatrikulation, Zugriff auf Prüfungsämter) oder die Bibliothek über den Chooser zusätzlich anzubieten. Hierdurch lässt sich die Verantwortung trennen: Jeder Server steht bei der ihn betreibenden Institution (Bibliothek, Prüfungsamt, Rechenzentrum), die Terminals werden gemeinsam benutzt, da die Clientel die gleiche ist und somit die Aufstellung verschiedener Rechner für verschiedene Anwendungen entfällt. Aufgrund der starken Verbreitung von Linux am Campus sehen sich sogar ignorante Institute gezwungen bei ihrer Webseitendarstellung auf die Kompatibilität zu Netscape unter Linux zu achten :-))

IV. Weiterführende Links

ISC - DHCPD Beispielimplementation

Etherboot Homepage

Homepage des Netbootpakets

X WindowSystem Terminals

Setting up an X-Terminal with Linux

Homepage des NILO-Projektes

Linux Terminal Server Project

Text von Dirk v. Suchodoletz (dirk@goe.net)