Der Terminalserver läuft unter Suse 10.1. Der Server verfügt über zwei Netzwerkkarten mit den festen Adresse 192.168.0.2 und 192.168.1.2. Die gesamte Installation und die Anbindung an Arktur 4.0rc1 wurde von der Firma Kogo DV (http://www.kogo-dv.de/) durchgeführt. Nach der Erstinstallation wurde er in das Gesamtsystem mit folgenden Grundeinstellungen integriert.
Arktur stellt über den LDAP-Server alle wichtigen Informationen zur Verfügung. Die folgenden Abbildungen zeigen die entschrechenden Schritte zur Übernahme der Nutzer auf den Terminalserver:
Unter dem Reiter Verwaltungseinstellungen müssen folgende Schritte durchgeführt werden.
Nach dem Klick auf "Einstellungen für die Benutzerverwaltung konfigurieren ... " gibt man nichts weiter ein und wählt man "Anonymer Zugang"
und ein Click auf "Übernehmen" beendet die Konfiguration.
Damit können sich alle User von Arktur auf dem Terminalserver normal als User anmelden.
Da es mit Arktur nicht möglich war, den SCSCI-Kontroller für das EONStor in Gang zu bekommen, übernimmt der Terminalserver auch die Funktion als Fileserver und gibt das EONStor im Netz frei. Dies enthält alle Userverzeichnisse und ein Verzeichnis für Unterrichtssoftware. Der Homezweig wird auf Arktur auf /home gemountet und steht damit den Windows Clients ganz normal per samba zur Verfügung. Auf Arktur kann somit der NFS-Server ausgeschaltet bleiben, da ein „Weiterreichen“ per NFS nicht möglich ist und die Linux Clients /home direkt vom Terminalserver beziehen. Die Installation von LTSP und das Aktivieren des TFTP-Servers per YAST
führen
dann zu folgender exports-Datei
/home 192.168.0.0/255.255.255.0(rw,no_root_squash,sync) /home 192.168.1.0/255.255.255.0(rw,no_root_squash,sync) /tftpboot *() /opt/ltsp-4.1 192.168.1.0/255.255.255.0(ro,no_root_squash,sync) /var/opt/ltsp/swapfiles 192.168.1.0/255.255.255.0(rw,no_root_squash,async)
Die Freigabe von /home mit der Option no_root_squash stellt ein Sicherheitsrisiko dar, ist aber für einige unserer Linux Clients notwendig, da sonst KDE nicht korrekt startet.
Diese Einstellungen reichen aus, um die Windows und Linux Clients zu betreiben. In unserer Anlage liegen die Terminals im 192.168.1.0 Netz. Dieser Punkt ist für die Konfiguration des DHCP Daemons wichtig.
Da wir unterschiedliche Clients als Terminals einsetzen, geben wir jedem Terminal eine feste IP und alle weiteren Informationen per DHCP. Der Weg, dies über den DHCP Daemon auf Arktur zu erreichen, war anfangs mit Problemen verbunden, da alle notwendigen Änderungen per ldapadmin in der LDAP Datenbasis gemacht werden mussten. Auch Hilfe aus der Liste – an dieser Stelle sei allen Kolleginnen und Kollegen für ihre schnelle und kompetente Hilfe gedankt – führte nicht zum gewünschten Erfolg.
In der FAQ des LTSP Projekts (www.ltsp.org) fand ich dann eine Anleitung für den Betrieb eines zweiten DHCP Servers. Diese Lösung verursacht zwar mehr Netzverkehr, ist aber etwas einfacher zu konfigurieren. Die Redundanz stört zur Zeit noch nicht.
Nun zur Lösung.
Per ldapadmin wird auf Arktur der Bereich der zu vergebenden Adressen im 192.168.1.0 Netz eingeschränkt.
Wie man sieht ist für Arktur bei 192.168.1.198 Ende des Adresspools. Alle Adressen darüber verteilt der DHCP Daemon des Terminalservers. Dieser kann per YAST konfiguriert und gestartet werden oder händisch per Editor.
Die eingesetzte dhcp.conf sieht zur Zeit so aus.
option root-path "192.168.1.2:/opt/ltsp-4.1/i386/"; hier findet das Terminal sein Linux
option domain-name "paradies.net";
option domain-name-servers 192.168.1.1;
option routers 192.168.0.1;
ddns-update-style none;
next-server 192.168.1.2; eigentlich unnötig, der Tserver hat diese IP, muss aber sein
allow booting; damit wird booting erlaubt
allow bootp; und das bootp Protokoll unterstützt
default-lease-time 7200;
subnet 192.168.1.0 netmask 255.255.255.0 {
default-lease-time 14400;
max-lease-time 36000;
}
host TS1-1 {
hardware ethernet 00:14:c2:05:c3:57;
fixed-address 192.168.1.201;
filename "lts/2.4.26.1-ltsp-3/pxelinux.0";
}Wichtig für den Betrieb sind die kommentierten Zeilen.
Für jedes Terminal muss ein entsprechender Eintrag vorgenommen werden, das ist zwar bei 50 Terminals/Clients mühsam aber praktisch für das Testen spezieller Konfigurationen einzelner Clients.
Nach der Installation von LTSP können dann die Terminals endlich ans Netz gehen.
LTSP kommt in der Version 4.1 zum Einsatz. Sie hatte sich vorab auf einem Testsystem unter Suse 9.1 bereits bewährt. Außerdem machen einige unserer alten PC als Terminal mit einem 2.6-Kernel Probleme.
Die Installation läuft nach der Anleitung auf (www.ltsp.org) und es muss nur noch unter /opt/ltsp/i386/etc die Datei lts.conf den jeweiligen Bedürfnissen angepasst werden.
#
# Copyright (c) 2003 by James A. McQuillan (McQuillan Systems, LLC)
#
# This software is licensed under the Gnu General Public License.
# The full text of which can be found at http://www.LTSP.org/license.txt
#
#
# Config file for the Linux Terminal Server Project (www.ltsp.org)
#
[Default]
SERVER = 192.168.1.2
X_VIDEORAM = 16384
X_MOUSE_PROTOCOL = "IMPS/2"
X_MOUSE_DEVICE = "/dev/psaux"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 3
XkbModel = pc105
XkbSymbols = de(pc105)
XkbLayout = de
USE_XFS = N
HOTPLUG = Y
SCREEN_01 = startx
SCREEN_02 = shell
[TS1-1]
SERVER = 192.168.1.2
X_VIDEORAM = 16384
X_MOUSE_PROTOCOL = "IMPS/2"
X_MOUSE_DEVICE = "/dev/input/mice"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 3
XkbModel = pc105
XkbSymbols = de(pc105)
XkbLayout = de
USE_XFS = N
HOTPLUG = Y
SCREEN_01 = startx
SCREEN_02 = shellHier sieht man einen Ausschnitt für HP Compaq t5125 Thin Clients. Diese Rechner benötigen einen Videoram Eintrag, da sonst KDE nicht startet. Die Default Einstellung gilt für alle und ist inzwischen weiter verändert. Zusätzlich setzt man für spezielle Clients dann noch weitere Parameter (Mausanschluß, Tastatur, Hotplug also USB, ...) Diese Konfiguration ermöglicht auf jedem Terminal eine grafische Session und eine shell Session, die man z.B. bei Schwierigkeiten mit dem grafischen System zum händischen Starten mit startx und Analyse der Fehlermeldungen gut verwenden kann.
Die Thin Clients und praktisch alle modernen Rechner haben Netzwerkkarten mit PXE und bieten ein Bootmenü, so dass man einfach den Terminalbetrieb auswählen kann.
Bei alten Rechnern ohne PXE gibt es mehrere Möglichkeiten sie als Terminals zu betreiben. Bootdisketten bzw. BootCDs sind für den Schulbetrieb nicht besonders geeignet, weshalb entweder ein GRUB mit Netzwerkunterstützung zum Einsatz kommt oder man auf Etherboot ausweicht. Grub mit Netzwerkunterstützung muss man selbst aus den Quellen kompilieren, was vielleicht aber nicht nach jedermanns Geschmack ist. Deshalb sei hier der Weg über Etherboot beschrieben.
Unter rom-o-matic-net erstellt man sich das passende ROM Image für die eingebaute Netzwerkkarte. Dazu muss man eventuell ein wenig suchen. Unter Linux gibt man als root lspci ein
sucht sich die Ethernetkarte – hier 0000:00:09.0 aus und gibt dann lspci -n -s 09 ein
und erhält damit die relevanten Daten, um auf rom-o-matic-net das passende ROM zu erzeugen. Wenn die Standardeinstellungen nicht ausreichen, wählt man den Weg über die optionale configure Möglichkeit.
Wählt man das .zlilo Format, reicht bei Maschinen mit Bootmanager ein einfacher Menüeintrag aus, um den Terminalbetrieb zu starten. Selbst für XP-Maschinen ist ein passender Weg beschrieben. Da unsere Clients praktisch alle mit Grub ausgestattet sind, musste nur noch die menu.lst Datei unter /boot/ grub editiert werden.