Das Linux Terminal Server Project tritt an, um die Installation und Wartung von Terminalservern zu vereinfachen. Der Artikel stellt auf der Basis von Ubuntu 7.04 Funktionsumfang und Konfiguration von LTSP 5 vor, das auch lokale Soundkarten, Drucker und USB-Sticks einbindet.

Auf Unix-Systemen finden Administratoren ideale Voraussetzungen für den Betrieb von Terminalservern. Die zahlreichen netzwerkfähigen Dienste, zum Beispiel die Grafikschnittstelle X11, die Remote-Shell SSH und das Netzwerk-Dateisystem NFS, bieten seit vielen Jahren ausgereifte und erprobte Standards. Gutes Server-based Computing zeichnet sich aber dadurch aus, dass die Benutzer den Eindruck gewinnen, als würden sie bei ihrer Arbeit direkt vor der laufenden Anwendung sitzen.

Um diese Illusion möglichst perfekt zu machen, genügt es nicht, die Anwendungen auf dem Client lediglich anzuzeigen. Die Programme sollen ihre Soundausgaben auf den Geräten abspielen, auf denen die Darstellung läuft, und nicht auf dem Server, der sie tatsächlich ausführt. Umgekehrt sind im Client eingestöpselte USB-Sticks erst dann nützlich, wenn der Terminalserver sie einbindet. Client-seitige Drucker vom Server aus zu benutzen, erweist sich meist ebenfalls als wünschenswerte Funktion.

Ein Chroot für LTSP

Das Linux Terminal Server Project (LTSP, [1]) kombiniert X-Window, SSH und NFS mit der Einbindung lokaler Drucker, Laufwerke und Soundkarten in einem übers Netzwerk gebooteten Betriebssystem. Dabei verbindet es diese Dienste geschickt zu einer vollwertigen Terminalserver-Lösung auf der Basis von GNU/Linux, die ganz nebenbei auch noch leicht einzurichten und wartungsfreundlich ist. Deshalb setzen es gerade Schulen und Bildungseinrichtungen verschiedenster Art oder Projekte aus der Entwicklungshilfe gerne ein (siehe Kasten “LTSP und Linux4Afrika”).

LTSP und Linux4Afrika

Das Linux Terminal Server Projekt ist eines der beliebtesten Projekte für Server-based Computing. Die Liste der Erfolgsstorys auf der Webseite [1] füllt mehrere Bildschirme, darunter befinden sich vor allem Schulen und Bildungseinrichtungen weltweit. Ein Projekt, das auf LTSP setzt, ist das im Rahmen der Entwicklungshilfe entstandene Linux4afrika, das 2006 der Freiburger Open-Source-Software-Verein Freioss.net e.V. ins Leben rief. Getragen von derzeit 304 Mitgliedern aus 27 Ländern, will die Initiative dabei zunächst in Tansania (Abbildung 1) und Mosambik Schulen mit Computerausstattung unterstützen. Jede Schule erhält einen Terminalserver und gebrauchte, getestete Computer ohne Festplatten als Thin Clients, Freioss sammelt dafür Computer, Bildschirme und Zubehör. Abbildung 1: Bis November 2007 erhalten sieben tansanianische Computerexperten, alle Mitglieder von Freioss.net e.V., ein Linux-Training. Von links nach rechts: Sebastian P. Koyi, Walter V. W. Nyoni, Baraka A. Onjare, Ted F. Silkiluwasha, Linux-Magazin-Redakteur Markus Feilner, Hamisi R. Kisinzah, Jovin M. Shumbusho, Freioss.net-Vorstand Hans-Peter Merkel und Andegenie A. Mwaipopo. (©Foto: Agnes König Begonnen hatte alles mit Debian Sarge und LTSP 4, nach kurzer Zeit stellten die Entwickler aber auf Edubuntu um, da die vorinstallierte Programmauswahl besser in den Ausbildungsbereich passt. Ein weiterer wichtiger Aspekt waren der Local Device Support von LTSP 5 und die Tatsache, dass diese Version out of the Box einfach funktioniert. Weil die gesammelten gebrauchten Computer und deren Netzwerkkarten aufgrund ihres Alters meist nicht PXE-tauglich sind, brennt das Team die notwendige Bootsoftware in einmal beschreibbare Eproms gebrauchter NICs. Als Terminalserver kommen AMD64-Dualcore-CPUs mit 2 GByte RAM zum Einsatz, die das Projekt aus Spendengeldern finanziert. Eine Musterfestplatte bleibt im Besitz von Freioss, jede Schule erhält mehrere mit »dd« erstellte Kopien, um sicherzustellen, dass ein Festplattenausfall schnell zu beheben ist. Neue Edubuntu-Releases werden in Deutschland getestet und bei Migrationen nach Tansania oderMosambik zum Austausch geschickt. In vielen Einsatzorten ist keine dauerhafte Internetanbindung vorhanden, deshalb haben die Entwickler die Offline-Wikipedia Kiwix, Moodle und Typo3 vorinstalliert. Zwei afrikanische Praktikanten verfassen zurzeit Dokumente, die den Unterricht an den Schulen unterstützen. Um die dortigen Schüler trotz fehlender Internetverbindung auf zukünftige Onlinetechnologien vorzubereiten, läuft auf dem Terminalserver auch ein lokaler Mailserver. Mit diesem lernen die Schüler, innerhalb des Klassenzimmers E-Mail-Techniken anzuwenden. Im Oktober 2007 werden die ersten Schulen die PCs in Betrieb nehmen – die zweite Sammelaktion kann starten. Den nächsten Container verschickt das Projekt wohl Ende November, im Frühjahr 2008 reisen einige Mitglieder von Freioss nach Tansania, um sich vor Ort über den Projektstand zu informieren und Workshops für Lehrer und Schüler durchzuführen. Das Linux4Afrika-Projekt berichtet auf der Webseite [http://www.linux4afrika.de] regelmäßig über den aktuellen Projektstand.

Den Kern einer LTSP-Installation bilden dabei Chroot-Umgebungen, in denen die zu bootenden Systeme enthalten sind. So startet mit möglichst wenigen Ressourcen ein X-Server auf dem Thin Client, der sich automatisch mit dem Terminalserver verbindet.

Bis zur Version 4 von LTSP stellt sich diese Chroot-Umgebung als eine eigenständige Distribution dar, die über eine spezielle Toolchain zur Administration verfügt. Größtenteils besteht sie aus einer speziellen Zusammenstellung von Projekten wie Glibc oder X.org, was sich allerdings mit der Zeit als problematisch herausgestellt hat. Denn all diese Projekte entwickeln sich weiter und geben regelmäßig Sicherheitsupdates heraus, die in LTSP eingepflegt werden wollen.

LTSP 5 (Muekow): Ubuntu als Basis

Das ursprünglich unter dem Codenamen Muekow initiierte LTSP 5 hat sich deshalb für einen anderen Weg entschieden. Anstatt wie bisher eine Kompilation unterschiedlichster Projekte herauszugeben, legten die Programmierer den Schwerpunkt auf die zentralen Bestandteile von LTSP. Neben den Startskripten und der angepassten Konfiguration machen jetzt kleinere Hilfsdienste dem Terminalserver auch die Peripheriegeräte der Thin Clients zugänglich.

Die restlichen Programmpakete und große Teile der Toolchain stellt in LTSP 5 dagegen die Host-Distribution des Servers. Sie bildet die Chroot-Umgebung im Kleinen nach und ermöglicht das Aktualisieren und Ergänzen um weitere Programme über den Paketmanager Apt-get. Ubuntu trägt neben Debian derzeit am meisten zur Entwicklung von LTSP 5 bei. Deshalb finden sich bei diesen Distributionen und deren Ablegern Edubuntu und Skolelinux die fortgeschrittensten LTSP-5-Implementierungen. Vor allem Edubuntu legt dabei viel Wert auf eine möglichst einfache Einrichtung und eine für die Weiterbildung ausgerichtete Paketauswahl.

Ressourcenbedarf und Anwendungen

Bei der Dimensionierung von Terminalservern für LTSP ist es schwer, allgemein gültige Aussagen zu treffen, da sich die Anforderungen je nach Einsatzzweck stark unterscheiden. Für typische Office-Szenarien gelten bei der Speicherkapazität derzeit 256 MByte RAM für den eigentlichen Serverbetrieb und 64 MByte RAM pro angemeldetem Benutzer als gemeinhin anerkannte Richtwerte.

Während eine Midrange-CPU im Bereich von 2 GHz im reinen Office-Betrieb noch etwa 15 bis 20 Benutzer ganz gut versorgt, mag für Anwendungen mit multimedialem Schwerpunkt bereits eine Highend-CPU mit mehreren Kernen erforderlich sein. Insbesondere Flash, Java, Video- und 3D-Anwendungen sind ja dafür bekannt, ein System deutlich unter Last zu setzen.

Im Zweifelsfall hilft es, die für den Einsatz geplanten Anwendungen bezüglich Speicherverbrauch und CPU-Auslastung sehr genau unter die Lupe zu nehmen und diese Werte für die gewünschte Anzahl von Benutzern hochzurechnen. Auf jeden Fall muss der Admin dabei Reserven einkalkulieren, denn mit zu wenig verfügbarem Speicher lagert der Server Daten in die Swap-Partition aus, die Performance leidet darunter erheblich.

Netztopologie und Disks

Die von Edubuntu propagierte Netztopologie sieht ein eigenes Subnetz für die Clients vor. Der Terminalserver sollte daher über zwei Ethernet-Karten verfügen, von denen die eine mit besagtem Subnetz und die andere mit dem übrigen LAN oder einem Router verbunden ist. Spätestens ab zehn Benutzern ist es ratsam, ein Gigabit-Ethernet für das Client-Subnetz zu verwenden, um gelegentliche Übertragungsspitzen einzelner Clients besser aufzufangen. Üblicherweise sind die durch viele simultane Zugriffe beanspruchten Festplatten der empfindlichste Engpass derartiger Systeme, daher lohnt es sich meist, auf schnell lesende Raids zu setzen.

Als Bestandteile des Raid eignen sich günstige SATA-Festplatten mit Native Command Queuing (NCQ) und 16 MByte Cache. Native Command Queuing ermöglicht es SATA-Platten, die Reihenfolge kurz nacheinander eintreffender Kommandos zu ändern, um so die Leseleistung zu optimieren. Gerade bei vielen simultanen Zugriffen ist dies von Vorteil, ein entsprechender Controller mit NCQ-Unterstützung ist dafür allerdings ebenfalls erforderlich.

Dimensionierung der Thin Clients

Etwas einfacher sieht die Dimensionierung der Clients aus. Als Minimum genügen hier ein 233-MHz-Prozessor, 64 MByte RAM, 100-MBit-Ethernet und eine Grafikkarte mit 2 MByte Video-RAM. Die empfohlene Ausstattung liegt mit einem 400-MHz-Prozessor und 128 MByte RAM etwas höher. Gehören das Abspielen von Videos und 3D-Anwendungen zum angepeilten Funktionsumfang, ist eine Grafikkarte mit Xvideo- oder GLX-Unterstützung erforderlich. Eine lokale Festplatte ist dagegen nicht notwendig.

Wenn die Clients vom Netz booten, empfiehlt sich eine Ethernet-Karte mit PXE-fähigem Boot-ROM. Wer keine mit solchen Boot-ROMs bestückten Exemplare besitzt, bekommt vom Etherboot/Gpxe-Projekt [2] maßgeschneiderte ROM-Images für viele gängige Karten [3]. Dieser Weg setzt natürlich den Zugriff auf einen EEPROM-Brenner voraus. Ohne den bleibt nur der Download der vom Etherboot-Projekt bereitgestellten Images für Disketten oder CDRs.

Generell ist das Booten vom Netz gegenüber dem Booten von konventionellen Laufwerken vorzuziehen, da Störungen durch mechanische Verschleißerscheinungen praktisch ausgeschlossen sind. Zusätzlich entfällt die organisatorische Aufgabe, immer die passenden Bootmedien bereithalten zu müssen.

Installation von LTSP 5

Besonders einfach ist die LTSP-Einrichtung, wenn der Administrator die Serverinstallation von Edubuntu verwendet, die [4] ausführlich beschreibt. Die vorgeschlagene Netztopologie vorausgesetzt, erhält er nach Abschluss der Installation ein schlüsselfertig eingerichtetes LTSP 5, von dem die Thin Clients ohne weitere Arbeit booten können.

Um LTSP nachträglich in ein Ubuntu-System zu integrieren, ist etwas mehr Handarbeit erforderlich. Zunächst muss der Admin sicherstellen, dass die Ethernet-Karten des künftigen Terminalservers richtig konfiguriert sind. Die Einstellungen dafür finden sich in der Datei »/etc/network/interfaces«.

In Listing 1 steht eine beispielhafte Konfiguration, die sich an der von Edubuntu vorgeschlagenen Topologie orientiert. Die Karte »eth0« hängt dabei am regulären Subnetz und bezieht ihre Konfiguration automatisch über das Netz, während »eth1« das Thin-Client-Subnetz versorgt und statisch auf die IP-Adresse »192.168.0.254« eingestellt ist. Über einen Aufruf von »man 5 interfaces« sind weitere Einzelheiten über den Aufbau dieser Datei zu erfahren.

01 # Die loopback-Schnittstelle
02 auto lo
03 iface lo inet loopback
04 
05 # Die Karte am regulären Subnetz
06 auto eth0
07 iface eth0 inet dhcp
08 
09 # Die Karte am Thin-Client-Subnetz
10 auto eth1
11 iface eth1 inet static
12     address 192.168.0.254
13     netmask 255.255.255.0
14     network 192.168.0.0
15     broadcast 192.168.0.255

Wer verhindern will, dass automatische Helfer wie Avahi oder der Network Manager die Ethernet-Schnittstellen wieder verkonfigurieren, deinstalliert am besten die Pakete »avahi-autoipd« und »network-manager«. Das folgende Kommando gibt die neue Konfiguration frei:

sudo invoke-rc.d networking restart

Der nächste Schritt ist die Installation des Pakets »ltsp-server-standalone«. Es enthält das Skript »ltsp-build-client«, das die Chroot-Umgebung für das Clientsystem zusammenbaut. Die Software hat einige Abhängigkeiten zu wichtigen Diensten, die zum Betrieb eines Terminalservers notwendig sind, aber das Paketmanagement löst in der Regel alle derartigen Dependencies selbstständig auf. Darüber hinaus sollte der SSH-Server installiert sein, da LTSP ihn für seinen standardmäßigen Login-Mechanismus benötigt.

Nach seinem Aufruf bezieht das Skript »ltsp-build-client« automatisch die benötigten Pakete für das Chroot aus den Repositories und installiert mit Hilfe von »debootstrap« ein abgespecktes Ubuntu-System in »/opt/ltsp/i386«. Der Hauptunterschied zum Hostsystem ist neben der spartanischen Ausstattung das installierte Paket »ltsp-client«, das die Startskripte zum laufwerkslosen Betrieb eines Thin Clients mitliefert.

Dieses System kann der Admin weitgehend wie eine völlig normale Ubuntu-Installation administrieren. Ein Online-Update bewerkstelligt er beispielsweise wie folgt:

sudo chroot /opt/ltsp/i386
apt-get update
apt-get upgrade
exit

Bevor die Clients vom Netz booten, sollte Root sicherstellen, dass die dafür benötigten Dienste korrekt konfiguriert und erreichbar sind.

DHCP: Automatische Konfiguration im Netz

Über das Dynamic Host Configuration Protocol (DHCP) beziehen die Clients vollautomatisch sämtliche Einstellungen wie IP-Adresse, Subnetz, Standard-Gateway und weitere Parameter. Dabei läuft auf einem Rechner (typischerweise dem Terminalserver selbst) der Daemon »dhcpd3«, der alle Anfragen im Client-Subnetz behandelt. Seine Konfiguration liegt in der Datei »/etc/ltsp/dhcpd.conf«, Listing 2 zeigt ein kommentiertes Beispiel dazu.

Wer jede einzelne Option des DHCP-Daemon kennen will, wirft einen Blick in »man 5 dhcpd.conf«. Glücklicherweise braucht der Admin in der vom Paket »ltsp-server-standalone« vorgegebenen Konfiguration selten etwas zu ändern. Im Wesentlichen muss er darauf achten, dass das Subnetz mit dem der Ethernet-Karte übereinstimmt, die die Clients bedient. Von besonderem Interesse für LTSP sind aber die Einträge »filename« und »option root-path« (siehe die Abschnitte über PXE und NFS).

Trivial File Transfer Protocol

Das Trivial File Transfer Protocol (TFTP) ist eine stark abgespeckte Variante von FTP. Weder kennt es eine Benutzer-Authentifizierung noch irgendwelche Dateiberechtigungen. Auch das Auflisten von Verzeichnissen ist nicht möglich und Dateien dürfen maximal 32 MByte groß sein. Dafür lässt dieses Protokoll wegen seiner Einfachheit sehr schlanke Implementierungen zu, die auch in das Boot-ROM einer Ethernet-Karte passen.

TFTP liefert unter LTSP den Bootloader und den Kernel an den Client. Standardmäßig verwendet Edubuntu 7.04 den Daemon »tftpd-hpa« als TFTP-Server, der über den Superserver »inetd« gestartet wird. Normalerweise liegt das TFTP-Wurzelverzeichnis in »/var/lib/tftpboot«. Dort müssen der Bootloader und der Kernel samt RAM-Disk untergebracht sein. Nach Änderungen an Kerneldateien kopiert das Skript »ltsp-update-kernels« diese aus der Chroot-Umgebung dorthin und passt automatisch die Symlinks für den Bootloader an.

PXE und Syslinux, Etherboot und Gpxe

Das Preboot Execution Environment (PXE) ist ein Standard von Intel, der es PCs ermöglicht, selbstständig über die Ethernet-Karte vom Netz zu booten. PXE verbindet sich dafür zunächst mit dem DHCP-Server, besorgt sich eine IP und liest die in Listing 2 verwendete DHCP-Option »filename« aus.

01 # Hier eingetragene Optionen werden
02 # für alle Clients erzwungen
03 authoritative;
04 
05 group {
06   # Typische Parameter für ein IP-Netz
07   option domain-name "example.com";
08   option domain-name-servers 192.168.0.1;
09   option broadcast-address 192.168.0.255;
10   option routers 192.168.0.1;
11   option subnet-mask 255.255.255.0;
12 
13   # Der Pfad zum Bootloader auf dem TFTP-
14   # Server jeweils für PXE und Etherboot
15   if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
16     filename "/ltsp/i386/pxelinux.0";
17   }
18   else{
19     filename "/ltsp/i386/nbi.img";
20   }
21 
22   # Das zu mountende NFS-Root-Verzeichnis
23   option root-path "/opt/ltsp/i386";
24 
25   # Host "foo" mit der MAC-Adresse  
26   # "00:11:22:33:44:55"
27   # bekommt immer die IP-Adresse 
28   # "192.168.0.10"
29   host foo {
30     hardware ethernet 00:11:22:33:44:55;
31     fixed-address 192.168.0.10;
32   }
33 
34   # Sonstige Rechner im 
35   # Subnetz "192.168.0.0/24"
36   # bekommen eine zufällige 
37   # IP-Adresse zwischen
38   # "192.168.0.20" bis "192.168.0.250"
39   subnet 192.168.0.0 netmask 255.255.255.0 {
40     range 192.168.0.20 192.168.0.250;
41   }
42 }

Der Client erhält dadurch den TFTP-Pfad zum Bootloader, lädt diesen herunter und führt ihn aus. Unter LTSP kommt Pxelinux aus dem Syslinux-Paket [5] zum Einsatz, es lädt den Kernel samt RAM-Disk und startet den Client.

Mit Etherboot gibt es auch ein freies Projekt, das PCs ohne PXE-bootfähige Ethernet-Karten zum erfolgreichen Booten vom Netz verhilft. Statt eines Bootloaders bootet der Client ein mit dem Programm »mknbi« modifiziertes Kernel-Image. Die in Listing 2 gezeigte Konfiguration erlaubt es dem DHCP-Server zu erkennen, ob PXE oder ein anderer Client nach dem Bootloader fragt, und gibt dann den passenden Dateipfad zurück. Mit Gpxe steht mittlerweile auch eine freie PXE-Implementierung zur Verfügung. Sowohl Etherboot als auch Gpxe finden sich auf [2].

Network File System

Da Thin Clients gewöhnlich ohne eigene Laufwerke daherkommen, müssen sie ihr Root-Dateisystem anderweitig beziehen. Das Network File System (NFS) ist für diesen Zweck das Protokoll der Wahl. Die korrekte Einrichtung eines Terminalservers, der das Root-Dateisystem der beteiligten Thin Clients vorhält, steht in der Datei »/etc/exports«.

Ein derartiger Eintrag gliedert sich in drei Teile: Der erste ist der absolute Pfad zum exportierenden Verzeichnis, anschließend folgt eine Eingrenzung der erlaubten Hosts. Dabei sind sowohl auflösbare Hostnamen als auch IP-Subnetze (wahlweise mit Wildcards) erlaubt. Der letzte Teil enthält in Klammern NFS-spezifische Optionen, die das Verhalten des NFS-Servers bestimmen.

NFS-Exporte

Das Paket »ltps-server« legt bei der Installation folgenden Eintrag in der »/etc/exports« an:

/opt/ltsp       *(ro,no_root_squash,async)

Er erlaubt jedem Host, ausgedrückt durch die Wildcard »*«, auf das Verzeichnis »/opt/ltsp« zuzugreifen. Die Option »ro« (read only) verbietet ihm das Schreiben. Mit »async« puffert der Client die Zugriffe, wodurch sich deren Performance steigern lässt. »no_root_squash« stellt sicher, dass jeder Benutzer eines Clients inklusive »root« auf das Verzeichnis zugreifen darf.

Gerade diese Option zeigt eine allgegenwärtige Schwäche von NFS: Es kennt in der von LTSP verwendeten Version 3 keine Authentifizierung. Dieses gravierende Manko hat NFS schon viele abschätzige Kosenamen wie “No Filesystem Security” und schlimmere eingebracht. Ein Client sagt dem Server einfach die User- und Group-IDs, unter denen er arbeiten möchte, und der Server lässt ihn anstandslos gewähren. Hat ein Angreifer also einen Client unter Kontrolle, steht es ihm frei, die Identität jedes Benutzers anzunehmen.

Sicherheit trotz NFS?

Um wenigstens den gröbsten Unsinn zu vermeiden, mappt NFS den Benutzer »root« normalerweise auf »nobody«. Genau dies schaltet die Option »no_root_squash« allerdings wieder ab. Da es sich in diesem Fall um das Root-Dateisystem für die Clients handelt, müssen diese zwingend auch mit Root-Rechten darauf zugreifen dürfen. Dadurch, dass der Server das Verzeichnis nur lesend exportiert, verhindert der Admin zwar möglichen Schaden auf dem Terminalserver, vertrauliche Dateien haben im Chroot jedoch nichts verloren.

NFS hat noch einen weiteren Nachteil: Die Performance bricht bei sehr vielen simultanen Zugriffen auf kleine Dateien massiv ein. Gerade bootende Thin Clients greifen mit ihren Startskripten auf eine Vielzahl kleinerer Files zu. Wo immer möglich, sollten Administratoren es vermeiden, zu viele Maschinen auf einmal zu booten, und stattdessen besser einzelne Rechnergruppen in Intervallen starten lassen. Weiterführende Informationen zu NFS finden sich in [7].

Individuelle Clients

Und wie kommt der Client jetzt an sein Dateisystem? Über die DHCP-Option »root-path« (siehe Listing 2) stellt er fest, wo sich sein exportiertes Root-Verzeichnis befindet. Er mountet dies zunächst als Root-Filesystem und führt anschließend einen Bind-Mount zu dem Verzeichnis aus, das zu seiner Architektur passt, in der Regel »i386«. An Stellen, die Schreibrechte voraussetzen, mountet er einfach ein im RAM liegendes temporäres Dateisystem darüber.

Alle Thin Clients teilen sich also ein und dasselbe System. Um dennoch individuelle Einstellungen für einzelne Rechner vornehmen zu können, gibt es die Datei »/opt/ltsp/i386/etc/lts.conf«. Neben globalen Einstellungen konfiguriert hier der Administrator auf der Basis von Ethernet-MAC-Adressen Optionen für ausgesuchte Rechner. Listing 3 zeigt ein kommentiertes Beispiel dieser Datei. Eine umfassendere Übersicht und Beschreibung der Optionen in der Datei »lts.conf« findet sich auf [6].

Abbildung 2: Der X-Server verwaltet zentral alle Ein- und Ausgabegeräte. Die X-Clients müssen sich zur Nutzung dieser Geräte mit dem X-Server verbinden. Unerheblich ist, ob die Verbindung lokal oder von einem anderen Rechner erfolgt.

01 [default]
02     # Farbtiefe 16 Bit spart Bandbreite
03     X_COLOR_DEPTH=16
04     # lokale Geräte an Server durchreichen
05     LOCALDEV=True
06     # Soundserver starten
07     SOUND=True
08     # deutsches Tastaturlayout
09     XKBLAYOUT=de
10 
11 [00:11:22:33:44:55]
12     # Vesa-Treiber verwenden
13     XSERVER = vesa
14     # serielle Maus einbinden
15     X_MOUSE_DEVICE=/dev/ttyS0
16     X_MOUSE_PROTOCOL=intellimouse

X-Window

Zentraler Dreh- und Angelpunkt aller Terminalservices ist das X-Window-System X11. Der X-Server läuft auf jedem Terminalclient und verwaltet sämtliche Ein- und Ausgabegeräte eines Rechners wie Monitore, Grafikkarten, Tastaturen und Mäuse. Darüber hinaus stellt er grundlegende Funktionen zum Arbeiten mit Fenstern sowie einfache Zeichenoperationen bereit.

Unter einem X-Client versteht man jede grafische Anwendung, die ihre Inhalte auf dem X-Server darstellen und dessen Geräte nutzen will. Dazu kommunizieren beide über das standardisierte, netzwerktransparente X11-Protokoll. Es spielt dabei keine Rolle, ob eine Anwendung auf demselben Rechner wie der X-Server läuft oder auf irgendeinem anderen Gerät im Netz (siehe Abbildung 2). Diese Eigenschaft ist essenziell für das Server-based Computing, da sie die Trennung zwischen Ausführungs- und Darstellungsort ermöglicht.

Fenster im Netz

Damit ein X-Client weiß, mit welchem X-Server er sich verbinden soll, schaut er in die Umgebungsvariable »DISPLAY«, die in der Form »Host:M.N« vorliegt. Dabei kann »Host« eine IP-Adresse, ein auflösbarer Hostname oder auch einfach leer sein. Wenn der Hosteintrag ausgelassen ist, nimmt der Client den lokalen Rechner als Ziel.

Der Platzhalter »M« bezeichnet die Nummer des X-Servers auf dem jeweiligen Rechner. Im Normalfall ist sie 0, bei Edubuntu 7.04 haben die X-Server der Clients allerdings immer die Nummer 6. Das Anhängsel ».N« bezeichnet die Display-Nummer, falls ein X-Server mehrere Monitore ansteuert. In fast allen Fällen kann sie entfallen.

Sicherheit

Ein X-Server verfügt über einfache Mechanismen, die verhindern, dass sich jeder beliebige X-Client mit ihm verbindet. Einer davon ist der Auth-Modus mit dem so genannten Mit-Magic-Cookie-1, das eine Datei mit Zufallswerten ist, die der X-Server beim Start übergeben bekommt. Es dürfen sich in diesem Modus nur X-Clients mit ihm verbinden, die das Cookie kennen. Es steht bei den Benutzern meist in der Datei »~/.Xauthority«, alternativ verweist die Umgebungsvariable »XAUTHORITY« auf eine andere Datei. Bei einem grafischen Login stattet normalerweise ein Displaymanager den Benutzer automatisch mit einem passenden Cookie aus. LDM, der Displaymanager von LTSP, macht dies bis zum Login genauso, überlässt es anschließend jedoch der SSH, den User mit dem Cookie auszurüsten.

Das Verfahren lindert zwar das Risiko, dass jemand versucht einem Benutzer falsche Passwortdialoge unterzujubeln oder gar dessen gesamte X-Session zu übernehmen. Aber leider kennt das X11-Protokoll von sich aus keine Verschlüsselung, was es Störenfrieden unter Umständen ermöglicht, Tastatureingaben oder auch das Cookie über simple Packet Sniffer mitzuschneiden.

Edubuntu 7.04 verwendet X.org 7.2 als Implementierung des X-Window-Systems. Im Normalfall sind hier keinerlei Anpassungen für die einzelnen Clients erforderlich, die LTSP-Startskripte finden meistens automatisch eine passende Konfiguration. Für jene Admins, die dennoch manuell eingegreifen wollen, finden sich in Tabelle 1 die X11-bezogenen Optionen der Datei »lts.conf« mit der passenden Erklärung.

Secure Shell

Was bei den Fenstern das X-Window-System, das ist bei den Konsolen die Secure Shell (SSH), die mit OpenSSH [8] in einer freien Implementierung vorliegt. OpenSSH arbeitet mit verschlüsselten Verbindungen und ermöglicht ein Befehlszeilen-orientiertes Login auf entfernten Rechnern, kopiert Dateien über Rechnergrenzen hinweg und kann viele IP-basierte Dienste durch das eigene Protokoll hindurch tunneln.

Besonders letztere Eigenschaft ist für Terminalservices interessant, da so das inhärent unsichere X11-Protokoll vor den Augen von Sniffern verborgen bleibt. Dabei tunnelt OpenSSH nicht nur den IP-Traffic, es stellt auch sicher, dass der Benutzer auf der Zielmaschine mit der richtigen »DISPLAY«-Variablen und dem passenden Cookie ausgestattet ist. So lässt sich mit wenig Aufwand eine entfernt gelegene grafische Anwendung starten, deren Ein- und Ausgabe automatisch auf den lokalen X-Server gelangt.

Schlüssel

SSH-Verbindungen authentifizieren sich über kryptographische Verfahren. Ein SSH-Daemon verfügt daher über mehrere Schlüsselpaare, die sich jeweils aus einem geheimen (privaten) und einem öffentlichen Schlüssel zusammensetzen. Darüber hinaus verknüpft ein SSH-Client in der Datei »/etc/ssh/known_hosts« die IPs von entfernten Rechnern mit ihren öffentlichen SSH-Schlüsseln und stellt auf diese Weise die Authentizität eines entfernten Servers sicher.

LTSP stattet das Clientsystem mit den öffentlichen SSH-Schlüsseln des Terminalservers aus und verhindert damit, dass ein Benutzer bei der Anmeldung auf dem falschen Rechner landet. Es bedeutet aber auch: Ändert sich die IP des Terminalservers oder tauschen die Admins seine Schlüssel aus, dann müssen sie auch das Thin-Client-System entsprechend aktualisieren, sonst ist kein Login mehr möglich. Ein Aufruf des Hilfsprogramms »ltsp-update-sshkeys« erledigt dies ohne großen Aufwand.

Der Soundserver: Pulseaudio

Die Audio-APIs von Linux (OSS, Alsa) arbeiten normalerweise nur lokal. Um die Soundausgabe auch über Rechnergrenzen hinweg zu transportieren, sind so genannte Soundserver nötig, die netzwerktransparente Schnittstellen für Audio zur Verfügung stellen. Der von LTSP standardmäßig eingesetzte Soundserver ist Pulseaudio [9], der ursprünglich unter dem Namen Polyaudio als Ersatz für den etwas in die Jahre gekommenen Enlightment Sound Daemon (ESD) entwickelt wurde (Abbildung 3).

Abbildung 3: LTSP kann Drucker, Sound und USB-Laufwerke auf den Clients einbinden. Drucker integriert das Python-Skript Jetpipe, für Sound sorgt der Soundserver Pulseaudio. Änderungen bei den USB-Massenspeichergeräten meldet auf dem Client ein eigener Serverdaemon namens Ltspfsd an den LTSP-Server, der dann über Fuse die Laufwerke mountet.

Über eine ausgefeilte Plugin-Architektur ist Pulseaudio flexibel erweiterbar, emuliert die Schnittstelle des weitläufig unterstützten ESD und stellt selbst ein Plugin für Alsa bereit. Ohne passende Anwendungen nützt das zwar noch nicht viel, aber mittlerweile unterstützen immer mehr Multimediaprogramme diese Interfaces.

Wo der Soundserver zu finden ist, lässt sich aus der Umgebungsvariablen »PULSE_SERVER« für das native Pulseaudio-Protokoll ableiten. Ihr Inhalt hat die Form »tcp:Host:Port«. Alternativ verweist die Variable »ESPEAKER« auf die emulierte ESD-Schnittstelle, die mit der Form »Host:Port« recht ähnlich aufgebaut ist. Um die Soundserver-Unterstützung auf den Clients zu aktivieren, genügt in der Datei »lts.conf« der Eintrag »SOUND=True«.

Client-seitige USB-Laufwerke auf dem Server

Eine Besonderheit von LTSP ist die Fähigkeit, lokale Laufwerke der Thin Clients auf dem Terminalserver einzubinden. Auf den Clients läuft dabei ein Daemon namens »ltspfsd«, der über angeschlossene Laufwerke oder gerade eingestöpselte USB-Sticks wacht. Auf dem Terminalserver werkelt das Gegenstück »ltspfs« aus dem gleichnamigen Paket. Ltspfs reagiert auf Ereignismeldungen des Daemon Ltspfsd und mountet die von ihm erfassten Geräte.

Intern verwendet es dafür das Fuse-Framework [10], um auf die Geräte übers Netz zuzugreifen. Standardmäßig ist es dabei nur Benutzern, die der Gruppe »fuse« angehören, erlaubt, auf Fuse-Verzeichnisse Geräte zu mounten. Auf den Thin Clients muss diese Funktion in der »lts.conf« mit dem Eintrag »LOCALDEV=True« extra aktiviert sein.

Lokale Drucker

Lokale Drucker lassen sich ebenfalls einbinden, wenn auch nicht ganz so dynamisch wie die Laufwerke. Zuerst ist in der »lts.conf« ein Eintrag für die Druckerschnittstelle des jeweiligen Clients anzulegen. In dem Eintrag »PRINTER_0_DEVICE« steht der Device-Node dieser Schnittstelle, zum Beispiel »/dev/usblp0« für einen USB-Drucker.

»PRINTER_0_TYPE« legt den Typ der Druckerschnittstelle fest, wobei die Werte »U« für USB, »P« für parallel und »S« für seriell stehen. Weitere Parameter für die Feinjustierung finden sich in der Edubuntu-Dokumentation [6].

Diese Werte helfen dem Client-seitigen Python-Skript »jetpipe« dabei, die richtige Schnittstelle zu ermitteln. Das Skript lauscht gewöhnlich auf dem TCP-Port 9100 und bildet sämtliche Ein- und Ausgaben dieses Ports auf die tatsächliche Druckerschnittstelle ab. Auf dem Terminalserver lässt sich passend dazu auch ein Drucker in Cups konfigurieren, der als Schnittstelle ein Socket auf die IP des Clients eingestellt hat. In den Gnome-Druckereinstellungen für Cups findet sich diese Konfiguration auch unter dem Namen »AppSocket/JetDirect«.

Das Beispiel funktioniert allerdings nur so lange, wie sich die IP-Adresse des Clients nicht ändert. Soll ein Drucker dauerhaft an einem Client funktionieren, hilft es nur, diesen über den DHCP-Server an eine feste IP-Adresse zu binden. In Listing 2 findet sich in den Zeilen 25 bis 32 ein Beispiel für eine solche feste Zuweisung über den Parameter »fixed-address«.

LDM

Die grafischen Logins wickelt in LTSP 5 standardmäßig der LTSP Display Manager (LDM) ab. Er läuft nicht auf dem Terminalserver, sondern lokal auf den Clients. Die Anmeldung erledigt er im Hintergrund, verschlüsselt über SSH. Dazu startet nach dem Login auf dem Terminalserver die X-Session des Benutzers, anschließend gelangt Gnome – durch die SSH getunnelt – auf den X-Server des Clients. Zusätzlich setzt LDM automatisch die Umgebungsvariablen für den Soundserver. Die Soundausgabe von Anwendungen leitet er direkt auf den Arbeitsplatz um.

Thin Client Manager

Um die Verwaltung der Clients so einfach wie möglich zu gestalten, gibt es in Edubuntu den grafischen Thin Client Manager im Paket »thin-client-manager-gnome«. Damit verschafft sich der Admin einen schnellen Überblick über die Tätigkeiten der angemeldeten Benutzer (Abbildung 4).

Abbildung 4: Der Thin Client Manager vereint in sich Systemüberwachung, Benutzerverwaltung und VNC-Viewer. Ungehörige Client-Benutzer sperrt der Admin hier einfach per Mausklick aus.

Eine Prozessliste – ähnlich der von Gnomes Systemüberwachung – verrät, welche Prozesse wie viel Speicher belegen und welche Systemlast sie erzeugen. Darüber hinaus kann der Admin individuell für jeden Benutzer Prozesse starten oder beenden. Hilfe für die Anwender stellt er über einfache Textbotschaften bereit. Fällt ein Benutzer hingegen aus der Rolle, sperrt er dessen Arbeitsstation einfach per Mausklick oder erzwingt ein Logout.

Im Thin Client Manager ist auch ein VNC-Viewer integriert, womit sich der Admin im wahrsten Sinne des Wortes ein Bild von den Desktops der Benutzer machen darf. Damit das funktioniert, muss er allerdings etwas basteln, da den Clients zunächst ein VNC-Server fehlt. Der Paketmanager im Chroot auf dem Server installiert ihn einfach mit »apt-get install«, zum Beispiel das Paket »x11vnc« aus dem Repository »universe«.

Damit der VNC-Server beim nächsten Booten eines Thin Clients auch startet, muss Root die Datei »/opt/ltsp/i386/etc/rc.local« um folgende Zeile ergänzen und die Startskripte des VNC-Servers anpassen:

x11vnc -display :6 -forever -loop &

Anschließend benennt er die Datei »K99rc.local« im Verzeichnis »/opt/ltsp/i386/etc/rc2.d/« in »S99rc.local« um, damit der Client den VNC-Server auch im Runlevel 2 startet. Weil aber damit jeder beliebige Rechner VNC-Zugriff erhält, sollte diese Methode nur in abgeschirmten und vertrauenswürdigen Netzen zum Einsatz kommen.

Fazit

Insgesamt befindet sich LTSP auf einem guten Weg, um Linux-basierte Terminalservices durch umfassenden Funktionsumfang, gute Wartbarkeit und konsequenten Abbau von Einstiegshürden salonfähig zu machen. Das Linux Terminal Server Project hat mit dem Wechsel zur Version 5 eine große Wandlung vollzogen, das Ergebnis kann sich sehen lassen. Bei Flexibilität und Wartbarkeit haben die Entwickler große Fortschritte erzielt, LTSP profitiert offensichtlich sehr von der Integration in Edubuntu.

Wermutstropfen sind allerdings die durch den allgemeineren Ansatz gestiegenen Hardware-Anforderungen. Der Vorgänger LTSP 4 gibt sich bei den Clients genügsamer und bootet schneller.

Der Gibbon lässt grüßen

Doch auch hier ist Besserung ist bereits in Sicht. Der gegenwärtige Entwicklungsstand der kommenden LTSP-Version für Ubuntus “Gutsy Gibbon” lässt einige sinnvolle Neuerungen erkennen. Die gravierendste Änderung wird der Wegfall von NFS als Root-Dateisystems bringen, was sicherlich sowohl bei Admins als auch sicherheitsbewussten Usern zu großem Aufatmen führt.

Künftig wird das LTSP-Chroot in einem komprimierten Squash-FS-Image abgelegt, das die Clients direkt über ein Network Block Devices [11] ansprechen und das Admins deutlich besser absichern können als dies mit NFS möglich ist. Der geringere Overhead verkürzt dabei auch die Bootzeit erheblich. Als weitere Änderung ersetzt eine in C reimplementierte, performantere Version den ursprünglich in Python geschriebenen LDM.

Dank der Verwendung von SSH ist es in der Praxis zwar nicht mehr möglich, die X11-Verbindung abzuhören. Der Preis für diese Sicherheit ist allerdings eine höhere Belastung der CPU. X-Clients mit regem Datenverkehr, die zum Beispiel Videos oder komplexe Animationen darstellen, sorgen daher schnell für eine deutlich spürbare Auslastung des Terminalservers.

Die neue Version von LTSP soll deshalb unverschlüsselte X11-Verbindungen bei nach wie vor sicherer Authentifizierung ermöglichen und verspricht damit weitere Leistungssteigerungen auch auf schwächerer Hardware. (mfe)