Linux in den Internet-Räumen

Martin G. Rathmayer

Die derzeitigen Benutzer-PCs in den Internet-Räumen des ZID laufen unter Windows 95 und werden übers Netzwerk gebootet. Das Konzept hat sich bis jetzt sehr gut bewährt, da es relativ gut administrierbar ist und eine sichere und stabile Arbeitsumgebung für den Benutzer bietet. Dieses System kann aus zwei Gründen nicht mehr länger aufrecht erhalten werden:

Zum Ersten ist die bestehende technische Lösung mit neuen Hardware-Komponenten nicht mehr realisierbar. Zum Zweiten ist ein Umstieg auf ein neueres Betriebssystem auf Grund moderner Applikationen dringend notwendig, allerdings wird das Prinzip des "Remote Network Boot" unter Windows ME, Windows 2000 oder zukünftigen Windows-Versionen nicht mehr unterstützt. Da eine lokale Installation bei einer so großen Anzahl von PCs nicht ausreichend wartbar ist, wurde ein anderer Weg, basierend auf Thin Clients unter Linux in Kombination mit Windows Terminal Servern, gewählt. Dieses neue Konzept ist sehr vielversprechend, da es flexibel und gut ausbaubar ist und die beiden zukünftigen großen Welten Linux und Windows miteinander verbindet.

Konzept

Das neue System sieht wie bisher "diskless" PCs vor, die allerdings unter Linux laufen und darüber hinaus per geeigneter Client Software Zugriff auf eine spezielle Auswahl aktueller Windows-Applikation haben. Diese so genannten Thin Clients werden ebenfalls übers Netzwerk gebootet und greifen auch auf das "Home Directory" des jeweiligen Benutzers am UNIX Studentenserver zu. Das Konzept ist ähnlich der derzeitigen LBR/Mars alternative und wird diese auch zur Gänze ablösen.

Die Bedienung einer Linux Workstation ist heutzutage bereits sehr komfortabel und nahezu "Windows like", sodass ein Umstieg auf dieses Betriebssystem ohne Probleme von einem Studenten der Technischen Universität Wien zu bewältigen ist. Auch steht bereits eine große Anzahl von guten Linux-Applikationen zur Verfügung, sodass der Standardbenutzer damit sicherlich sein Auslangen finden wird. Zusätzlich gibt es eine Citrix Windows Terminal Server Farm, auf der per ICA (Independent Computing Architecture) Client eine ausgewählte Anzahl von Standard Windows-Applikationen und eine Reihe spezieller Windows-Programme (z. B. für Übungen) ausgeführt werden können.

Thin Client Hardware

Die eingesetzten PCs haben alle 128-256 MB Hauptspeicher, Pentium II oder Celeron Prozessoren und teilweise CDROM-Laufwerke und Wheel-Mäuse. Einige Clients sind bereits mit 100 MBit/s ans TUNET angebunden und bieten sogar Audio-Unterstützung. Ein Parallel oder USB ZIP Drive kann überall angeschlossen werden. Alle Geräte besitzen deutsche Tastaturen und 17" Monitore. alte, langsamere Geräte werden vollständig ersetzt. In Zukunft wird überall eine maximale Ausbaustufe angestrebt. Es ist ebenfalls geplant, die VT100 Terminals durch Kiosk PCs zu ersetzen.

Remote Boot Server Hardware

Die Linux Boot Server besitzen eine gute Netz- und I/O Performance für die NFS Verbindungen, d. h. schnelle SCSI-Platten und eine gute Bus-Bandbreite (Dual Pentium III mit mindestens 512 MB und zwei Netzwerkkarten). Ausfallssicherheit und Leistungssteigerung wird durch mehrere redundante Server (derzeit zwei Stück) erreicht, die von einem Master Server ihre Konfigurationen und von einem Reference Client ihre zu exportierenden Daten laden. Die Windows-Applikationen liegen auf einer eigenen Server Farm (derzeit drei Rechner), die unter Windows 2000 mit Citrix Metaframe XP betrieben wird (siehe "Citrix Terminal Server für die Internet-Räume").

Software

Als Basis dient die komplette Linux RedHat Distribution Version 7.x (Kernel 2.4.x) mit KDE  (Version 2.x) als Desktop-Empfehlung. Im Wesentlichen werden die wichtigsten KDE-Applikationen für Mail/News/WWW vom ZID unterstützt sowie einige ausgewählte Applikationen wie Netscape, Acrobat Reader usw. Darüber hinaus sind natürlich weitere Software-Pakete wie z. B. Star/Open-Office installiert, diese werden derzeit aber vom ZID nicht unterstützt. Die Aktualisierung von System und Applikationen erfolgt je nach Verfügbarkeit und Sinnhaftigkeit. Bei den Windows-Applikationen wird hauptsächlich das MS Office Paket angeboten. Eine vollständige Liste aller installierten bzw. vom ZID unterstützten Programmen wird auf den Web-Seiten des ZID veröffentlicht.

Services

Die Thin Clients haben wie bisher je nach Zugangsberechtigung vollen Zugang zum Internet und den Services des ZID (UNIX Account, Mailbox, News Server, White Pages, Drucken über Copy Card). In einer ersten Testphase wird es für die Benutzer des neuen Systems keine Kernzeitbeschränkung geben.

Linux Remote Boot

Linux Remote Boot in den Internet-Räumen

Technische Realisierung

Nach dem Einschalten des PC-Arbeitsplatzes wird übers Netzwerk ein DHCP Server kontaktiert, der dem Client alle notwendigen Boot-Informationen (IP-Konfiguration, Bootfile und notwendige Start-Parameter) mitteilt. Danach wird je nach Methode (PXE oder Etherboot) per TFTP ein komprimiertes Image (ca. 1.5 MB) vom Boot Server geladen, welches Kernel, Netzwerktreiber und ein minimales Root Filesystem enthält. Nach Dekomprimieren und Ausführen des Kernels wird das Root Filesystem in einer wenige MB großen Ramdisk entpackt und der Init-Prozess wird gestartet. Dieser führt sofort alle notwendigen NFS Mounts durch (/usr, /bin, /sbin, /lib, ...), startet wichtige System-Prozesse und wartet auf die User-Validierung. Diese erfolgt durch einen authentifizierten Mount des Home-Filesystems am Studentenserver per "NFS On Demand" (s. u.). Danach werden noch einige Jobs durchgeführt (z. B. Initialisierung des User Directories, Hardware-Erkennung, Starten von Services) und schließlich wird der Desktop gestartet. Das Gerät kann jederzeit ohne weitere Aktionen einfach abgeschaltet werden.

Server

Die Redundanz der Boot Server wird dadurch bewerkstelligt, dass mehrere Server auf DHCP Requests lauschen und bei Ausfall eines Servers einfach der nächste antwortet. Die Boot-Information enthält auch eine Liste von NFS-Servern, welche für das Mounten zur Verfügung stehen. Damit kann eine Lastaufteilung, die ja eigentlich nur für NFS relevant ist, erzielt werden. Sollte allerdings ein bereits gemounteter NFS-Server ausfallen, wird der Client inoperabel und muss neu gebootet werden. Für Client-übergreifende Informationen steht noch ein Scratch Space am Boot Server zur Verfügung.

Client

Die Ramdisk des Clients, die das Root-Filesystem enthält, ist so groß gewählt, dass für /boot, /etc, /dev und /var genügend Platz ist. Dafür reichen in der Regel 3- 5 MB aus. /tmp wird ebenfalls im Memory realisiert und /var/tmp liegt am Boot Server. Da Swappen über Netz nahezu unbrauchbar ist, wird darauf verzichtet und jeder Client mit ausreichend viel Hauptspeicher ausgestattet (in Zukunft alle PCs mit 256 MB).

User Validierung

Die Benutzervalidierung geschieht nach Mounten der R/O Filesysteme und vor dem Mounten des Home-Filesystems. Im Prinzip existiert auf dem Boot Server für jeden Remote Client und jeden User ein Datensatz, der Informationen über Konfiguration und Zugriffsrechte enthält. Dadurch ist es einerseits möglich, mehrere Benutzergruppen mit verschiedenen Berechtigungsprofilen (Student, Kursteilnehmer, Tagungsbesucher) zu verwalten, und andererseits unterschiedliche Hardware Konfigurationen und Zugriffsmechanismen (Multimedia PC, Übungs PC, Kiosk PC, X-Terminal) zu ermöglichen. Im Normalfall geschieht die Validierung eines Studenten implizit durch den NFSOD Mount am Studentenserver. Es ist aber auch ein Zugriff auf andere Server bzw. per alternativem Protokoll (z. B. SMB) möglich.

Windows Applikationen

Das technische Prinzip einer Windows Terminal Session sowie die Integration in das Linux-Umfeld (Session Window, Home Directory, Drucken etc.) werden in einem separaten Artikel erläutert (siehe nächste Seite).

Security

Da es sich bei den Client PCs um UNIX-Systeme handelt, könnte ein Benutzer das System theoretisch hacken und Root-Berechtigung erlangen. Dieses "Privileg" bringt ihm aber nicht viel und ist spätestens nach dem nächsten Reboot wieder weg. Auf alle Fälle zieht es keine Session-übergreifenden Beeinträchtigungen für den nächsten User nach sich, da dieses System ja "remote" gebootet wird. Die Möglichkeit, dass der Client während einer Session von außen gehackt wird, und dadurch ein Datenverlust für den aktuellen Benutzer entsteht, ist sicherlich geringer als auf einem Studentenserver direkt.

Ein Problempunkt ist noch die Art und Weise, wie Home Directories gemountet werden. Da nicht 100-prozentig auszuschließen ist, dass sich doch ein User Root-Berechtigung am Client verschafft, kommt ein normaler NFS Mount nicht in Frage. Deshalb muss eine Methode verwendet werden, die auf alle Fälle eine Validierung erfordert. AFS und DCE scheiden aus administrativen und technischen Gründen aus. Bleibt eigentlich nur noch Samba, das leider einige sehr gravierende Nachteile besitzt (keine Symlinks, kein File Locking, ...). Da gerade viele der neuen KDE- und Gnome-Applikationen diese Features benötigen, kommt es sehr schnell zu einem in-stabilen Betrieb. Da es NFS4 noch nicht gibt, wurde eine eigene Variante (unter Verwendung von NFS3) entwickelt. Das Ganze nennt sich NFSOD (NFS On Demand) und basiert auf einem Client-Server-Mechanismus, bei dem nach einem Validierungsschritt das User Home-Verzeichnis explizit für den Remote Client exportiert wird. Dann wird per Keep-alive Mechanismus die Existenz des Clients überwacht und bei Terminierung desselbigen der Export sofort entfernt. Ein zusätzlicher Überwachungsjob verhindert die Ausnutzung möglicher Sicherheitslücken von NFS durch abgestürzte Daemons oder andere Probleme.

Ausblick

Das neue Konzept ist teilweise bereits im Zuge einer Java-Übung im Internet-Raum Favoritenstraße im Einsatz. Ende November wird der Internet-Raum FHBR2 (Freihaus, 2. Stock) zur Gänze umgestellt und es wird dort nur noch Linux zur Verfügung stehen. Danach werden schrittweise die anderen Internet-Räume dazu kommen. Hinweise und Einführungsunterlagen werden rechtzeitig im Web zur Verfügung gestellt. Die Tutoren werden auf das neue System eingeschult und geben Auskunft über unterstützte Applikationen und einfache Linux-Fragen.

TopSeitenanfang | ZIDline 6 - Dezember 2001 | ZID | TU Wien