|
|
Linux-Arbeitskreis Hamburg |
Die Installation eines Thin-Client mittels LTSP ist eine einfache und schnelle Lösung für kostenbewuste Netzbetreiber. Leider stellt dieser Ansatz relativ hohe Anforderungen an die benötigten Server, da alle Anwendungen dort ablaufen.
Inzwischen gibt es z.B. mit den Mini-ITX Systemen Geräte, die performant genug sind, um Anwendungen auch lokal auf dem Client ausführen zu können. Ein derartiges Gerät ist für ca. 300 Euro (ohne Monitor) zu bekommen. Leider unterstützt LTSP das lokale Ausführen von Anwendungen nur auf dem Umweg über eine rsh-Sitzung. Von daher muss man sich eine andere Lösung suchen.
Für Linux Diskless Clients (LDC) gibt es aber bereits eine funktionsfähige Lösung von Studenten/Mitarbeitern der Universität in Göttingen. Auf den dortigen, sehr ausführlichen Beschreibungen von Dirk v. Suchodoletz beruht auch diese Anleitung.
Der typische LDC-Rechner verfügt über eine bootfähige Netzwerkkarte, entweder mit einem Etherboot-ROM oder einfacher einem PXE-Rom. Bei den Mini-ITX Systemen ist eine PXE-fähige Netzwerkkarte mit auf dem Motherboard.
Die Konfiguration gemäß Anleitung von Dirk v. Suchodoletz beruht auf einem SuSE-System. Hier ist eine ganz normale Server-Installation notwendig, sowie einige Pakete, die der Client benötigt. Folgende Pakete müssen nachinstalliert werden, falls sie nicht schon vorhanden sind:
All diese Pakete befinden sich auf der SuSE-Distribution.
Das in der Dokumentation ebenfalls genannte Paket busybox sollte besser nicht installiert sein, da sonst aufgrund eines Syntaxfehlers der Rechner nicht bootet.
Von den Seiten der Göttinger bezieht man sich dann das
Archiv mit einem Dateisystem
und den notwendigen Scripten. Das Archiv ist etwa 30 MByte gross. Die
Beschreibung bezieht sich auf die Version 0.5.1d vom 06.02.2003.
Die Datei entpackt man in einem beliebigen Verzeichnis, z.B. /tmp mittels:
tar xvfz dxs-install.tgz
Es entsteht ein Verzeichnis linux-diskless, in das man mit
cd linux-diskless
wechselt. Speziell, wenn man zusätzlich auch LTSP arbeiten möchte, dann sollte man an dem Installationsscript aus Göttingen eine kleine Verädnerung vornehmen. Als Wurzelverzeichnis für das Client-Filesystem auf dem Server dient dort /nfsroot, es macht aber Sinn, das Filesystem ebenfalls unter /tftpboot anzulegen, dann liegt alles beieinander. Zeile 47 der Datei
linux-install/mk_dxsfs.sh
sollte also lauten
NFSROOT="/tftpboot"
Da diese Variable aber nicht in allen Scripten konsequent genutzt wird sollte man vorsichtshalber noch einen Softlink setzen (in Hamburg legt man sich nicht gern fest, lässt daher beide Wege zu):
ln -s /tftpboot /nfsroot
Einen kleinen Fehler in den Installationsscripten kann man dann gleich einmal
korrigieren. In
linux-install/mk_dxsfs.sh
fehlt das Verzeichnis /etc/SuSEconfig in der Liste der Unterverzeichnisse
von /etc. Ohne dieses Verzeichnis funktioniert aber KDE nicht richtig, weil
Profileinstellungen fehlen:
linux-install/mk_dxsfs.sh (ab Zeile 57)
PROGRESS=0 ETCSUBDIRS="/etc/cron.daily /etc/cups /etc/default /etc/java /etc/profile.d \ /etc/unixODBC /etc/gimp /etc/gtk /etc/pam.d /etc/skel /etc/iproute2 /etc/xml \ /etc/WindowMaker /etc/ssl /etc/security /etc/alsa.d /etc/gpm /etc/openldap \ /etc/opt /etc/postfix /etc/ssh /etc/cron.d /etc/sane.d /etc/libiodbc \ /etc/radiusclient /etc/diameter /etc/raddb /etc/ipsec.d /etc/texmf \ /etc/samba /etc/ximian /etc/stunnel /etc/hotplug /etc/vmware /etc/SuSEconfig"
Danach kann der eigentliche Installationsvorgang durch einen Aufruf des Scriptes gestartet werden:
./mk_dxsfs.sh
Das Script erstellt nun das Client-Dateisystem unterhalb von /tftpboot/dxs und kopiert einige Dateien aus dem Server-Betriebssystem dort hinein.
Folgende Einstellungen müssen nach der Installation korrigiert werden.
Die Beschreibung geht davon aus, dass die Homeverzeichnisse unterhalb von /home/users liegen. Bei den üblichen SuSE-Installationen ist es aber /home. Daher muss die zugehörige Automount-Datei angepasst werden:
/tftpboot/dxs/etc.s/auto.master
# Sample auto.master file # Format of this file: # mountpoint map options # For details of the format look at autofs(8). /misc /etc/auto.misc /home /etc/auto.home
Die dritte Änderung betrifft ein Problem mit dem Inittar. Hier sind mehrere Versionen vorhanden, von denen aber nicht alle auf allen Systemen laufen. Das hängt damit zusammen, dass SuSE ab Version 8.1 unterschiedliche glibc-Versionen für Systeme mit i586 und i686 installiert (siehe hierzu auch 6.). Das eingestellte Standard-Inittar stammt wohl von einem 8.1 System und ist mit Servern unter 7.x und 8.0 nicht kombatibel. Hier hilft eine Änderung der Datei
/tftpboot/dxs/boot/pxelinux.cfg/default
# pxelinux.cg/default file
# for instructions see syslinux package by Peter Anvin
#
# Generic setup for linux diskless clients
#
# Dirk von Suchodoletz <dirk@goe.net>, 20-01-2003
#
# any label may be present more then one configuration is possible
label linux
# the plain kernel image
kernel bzImage
# append line (is not transported via pxe-dhcp)
# use the same values as within dhcpd.conf
append vga=0x301 initrd=inittar.nosplash
# other possible configuration
#label linux-lpp
# kernel bzImage-lpp
# append vga=0x301 initrd=inittar.nosplash
Die Grafikauflösung bei diesem System ist in der Regel zu hoch, 1280x1024 ist für TFT-Monitore und auch viele andere Monitore nich optimal. Zwar kann man die Grafikauflösung auch über DHCP-Optionen setzen, dann erfolgt aber keinerlei automatische Erkennung mehr, was nicht ganz ohne Risiko ist, wenn die Wiederholraten nicht stimmen.
Man kann zur Problemlösung in der Datei /ftfpboot/dxs/sbin/hwsetup einfach die zu hohen Auflösungen entfernen.
/ftfpboot/dxs/sbin/hwsetup (ab Zeile 361)
# compute max resolution #for MR in 640x480 800x600 1024x768 1280x1024 1400x1050 1600x1200 for MR in 640x480 800x600 1024x768 do MODES="\"$MR\" \"lcd$MR\" $MODES" if [ $MR = "$MAXRES" ] ; then break ; fi done
Mit dieser Modifikation wird als maximale Auflösung 1024x768 vorgegeben.
Schwierigkeiten gibt es auch mit TFT-Bildschirmen. Für die wird keine geeignete Modeline gefunden. Mit etwas experimentieren ergibt sich die folgende Modeline-Zeile (/ftfpboot/dxs/sbin/hwsetup ca. ab Zeile 120)
\tModeline "1024x768" 65.0 1024 1047 1184 1344 768 771 777 806\n
für einen TFT-Monitor und 60 Hz.
Auf dem Server muss eine Reihe von Diensten aktiviert und konfiguriert werden.
Die Grundlagen dieser Dienste sind im Linuxbu.ch und auf den Seiten von Linux-Hamburg zu finden.
An den Nameserver stellt LDC keine besonderen Anforderungen, er muss nur so konfiguriert sein, dass die Client-Adressen auflösbar sind.
Der NFSserver ist für LDC ein sehr wichtiger Server. Auf aktuellen Systemen stehen zwei Versionen alternativ zur Verfügung, einerseits das modernere Kernelnfs, andererseit das User-Space NFS. Üblicherweise ist auf den meisten Systemen Kernelnfs installiert. Leider sind selbst die aktuellen Versionen anscheinend nicht fehlerfrei. Auf allen bisher installierten Systemen gibt Probleme, die nicht immer nachvollziehbar sind.
Daher muss für LDC der User-Space NFSserver installiert werden. Dazu stoppt man den vorhandenen NFSserver und installiert mittels YaST das Paket nfs-server neu. YaST fordert dabei dazu auf das Paket nfs-util zu deinstallieren, welches zum Kernel-NFS gehört. Nach der Installation kann man den NFSserver neu starten.
Die wichtigsten NFS-Einstellungen erfolgen in der Datei /etc/exports.
/etc/exports
# See exports(5) for a description. # This file contains a list of all directories exported to other computers. # It is used by rpc.nfsd and rpc.mountd. /home 192.168.1.0/255.255.255.0(ro) /cdrom *(no_root_squash) # ldc-Erweiterungen /tftpboot/dxs 192.168.1.0/255.255.255.0(ro,no_root_squash) /tmp/dxs 192.168.1.0/255.255.255.0(rw,no_root_squash) /usr 192.168.1.0/255.255.255.0(ro) /opt 192.168.1.0/255.255.255.0(ro)
Die ersten Zeilen sollten in irgendeiner Form vorhanden sein, vor allem der Export des home-Zweiges. Die letzten Zeilen sind für LDC notwendig, hier wird das benötigte Dateisystem zur Verfügung gestellt. Auf die Verzeichnisse /usr und /opt muss der Client nur lesend zugreifen, von daher werden sie auch nicht zum Beschreiben freigegeben. Generell wird das eigentliche Dateisystem des Servers nur zum Lesen genutzt. Lediglich in den beiden speziellen LDC-Verzeichnissen (dxs) bekommt der Client auch Schreibrechte.
Die Konfiguration des NIS-Server erfordert keine LDC-spezifischen Einstellungen.
Dem DHCPD kommt bei diesem System eine sehr große Bedeutung zu, da ein großer Teil der Konfigurationseinstellungen als DHCP-Parameter übermittelt werden.
# /etc/dhcpd.conf
#
# Configuration file for ISC dhcpd
#
# Automatically generated by dhcp-generate.pl
#
# --> 2003/1/25 14:5
#
# (c) Dirk von Suchodoletz <dirk@goe.net>, 2002
#
# -- user defined vendor options --
# Deklarationen
option o128 code 128 = string;
option o129 code 129 = string;
option menudflts code 160 = string;
option motdline1 code 184 = string;
option menuline1 code 192 = string;
option menuline2 code 193 = string;
option menuline3 code 194 = string;
option bootlocal-script code 221 = string;
option x-server-defs code 222 = string;
option start-x code 223 = string;
option start-snmp code 224 = string;
option start-sshd code 225 = string;
option start-xdmcp code 226 = string;
option start-cron code 227 = string;
option crontab-entries code 228 = string;
option start-rwhod code 229 = string;
option start-printdaemon code 230 = string;
option dxs-debug-level code 231 = unsigned integer 8;
option tex-enable code 232 = string;
option netbios-workgroup code 233 = string;
option start-vmkernel code 234 = string;
# -- global options --
option o128 E4:45:74:68:00:00;
# deny unknown-clients;
default-lease-time 160000;
max-lease-time 200000;
use-host-decl-names on;
option dhcp-max-message-size 1024;
ddns-update-style none;
# das brauchen wir immer
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.40 192.168.1.160;
server-identifier 192.168.1.1;
}
# -- client specific --
#
# Rechner -> epia
#
group ldc_itx {
filename "/dxs/boot/pxelinux.0";
# die folgenden beiden Zeilen sind notwendig, wenn dhcp- und tftp/nfs-Server nicht identisch sind
next-server 192.168.1.1;
server-identifier 192.168.1.1;
option root-path "/tftpboot/dxs";
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option domain-name "hsan.hh.schule.de";
option nis-domain "lokales-netz";
option nis-servers 192.168.1.1;
option x-display-manager 127.0.0.1,192.168.1.1;
option start-x "query";
option start-xdmcp "xdm";
option start-rwhod "no";
option start-cron "no";
option start-snmp "no";
# option x-server-defs "de imps/2 psaux 50 80 1024x768";
option bootlocal-script "";
#
host epia2 {
hardware ethernet 00:40:63:C0:59:9C;
fixed-address 192.168.1.31;
}
}
Das DHCP-Protokoll erlaubt die Übermittlung von sog. Optionen. Ein Teil dieser Optionen ist standardisiert, ein weiterer Teil frei definierbar. Für die frei definierbaren Optionen sind die Codenummern 128-255 reserviert. Jeder dieser Codenummern kann ein Bezeichner und ein Datentyp zugeordnet werden. Diese Deklarationen erfolgen am Anfang der Konfigurationsdatei in einem globalen Teil.
Später werden dann diese Optionen bei Bedarf initialisiert. In der vorliegenden Beispielkonfiguration erfolgt die Initialisierung für eine Gruppe von Rechnern mit Mini-ITX Board. Innerhalb der Gruppe ist dann ein konkreter Rechner mit seiner MAC-Adresse angegeben, der dann nur noch die Angabe einer IP-Adresse benötigt.
Alle Programminstallationen in das Verzeichnis /opt auf dem Server sind auch für die Clients sofort gültig, da dieses Verzeichnis insgesamt zur Verfügung steht. Bei Programmen in anderen Verzeichnissen kann zusätzliche Handarbeit notwendig werden.
Für Systeme mit Thin-Clients bzw. LTSP ist ICEWM eine interessante Alternative zu kde, da er sehr schlank und sehr einfach zu konfigurieren ist. Die Konfigurationsdateien von ICEWM liegen im Verzeichnis /etc/X11/icewm und stehen dem Client damit nicht zur Verfügung (wohl aber die Icons und Themes unterhalb von /usr/X11R6/lib/X11/icewm/).
Man muss also dieses Verzeichnis in den Verzeichnisbaum für den Client einbinden:
cp -a /etc/X11/icewm /tftpboot/dxs/etc.s/X11/
diese statischen Dateien müssen nun für jeden Client zugänglich gemacht werden, per Softlink:
ln -s /etc.s/X11/icewm /tftpboot/dxs/var/ram/etc/X11/icewm
Zum Aktivieren dieser Veränderungen muss das inittar neu erzeugt werden, wie immer bei Änderungen unterhalb von /tftpboot/dxs/var/ram/. Dazu ruft man aus dem Installations-Verzeichnis linux-diskless (siehe 2.) heraus mkdxsinittar auf:
./mkdxsinittar -dxsrd /tftpboot/dxs -k bzImage
Danach steht dem Client auch icewm zur Verfügung.
Theoretisch könnte man an den Client auch einen lokalen Drucker anschließen. Die folgende Beschreibung geht aber davon aus, dass der Client über den Server druckt. Dabei muss dann der Drucker noch nicht einmal physikalisch an dem Drucker angeschlossen sein, es langt wenn man vom Applikationsserver aus drucken kann.
Auf dem Server selber muss der Zugriff auf die Druckerschlange erlaubt sein. Dazu muss in der Datei /etc/hosts.lpd erlaubt sein.
/etc/hosts.lpd (komplett)
# # hosts.lpd This file describes the names of the hosts which are # to be considered "equivalent", i.e. which are to be # trusted enough for allowing remote lpr(1) commands. # # hostname 192.168.1
hiermit wird allen Rechnern deren IP-Adresse mit 192.168.1 beginnt der Zugriff erlaubt
Auf das Client-System müssen drei Dateien kopiert und teilweise angepasst werden.
cp /etc/printcap /ftfpboot/dxs/var/ram/etc/ cp /etc/lpd.conf /ftfpboot/dxs/var/ram/etc/ cp /etc/lpd.perm /ftfpboot/dxs/var/ram/etc/
Die printcap-Datei kann man drastisch vereinfachen, es muss nur der Name des Druck-Servers und des Druckers angegeben werden.
/ftfpboot/dxs/var/ram/etc/printcap
# lp_brother|lp1:\ :lp=/dev/null:\ :rm=192.168.1.1:\ :rp=lp_brother:\ :sd=/var/spool/lpd/lp_brother:\ :sh:
In der lpd.conf muss ein einziges Zeichen ergänzt werden:
/ftfpboot/dxs/var/ram/etc/lpd.conf
# See "man lpd.conf" for a list of options you can set here. # check_for_nonprintable # means the 'check_for_nonprintable' option default value is on or 1 # To set it to OFF or 0, change this to read: # check_for_nonprintable@ check_for_nonprintable@ # If you don't want to have local spooling (in case you wish to send the job # to a global print server or direct to the adressed printer) append a "@" to # the following line: force_localhost@ client_config_file=/etc/lpd.conf filter_ld_path=/lib:/usr/lib:/usr/X11R6/lib:/usr/local/lib filter_path=/bin:/usr/bin:/usr/local/bin:/usr/sbin:/usr/local/sbin:/usr/lib/filters:/usr/X11R6/bin mail_operator_on_error=root pr=/usr/bin/pr printcap_path=/etc/printcap # If you distribute your printcap entries through NIS, # use the following line instead: #printcap_path=|/usr/lib/yp/match_printcap printer_perms_path=/etc/lpd.perms server_config_file=/etc/lpd.conf server_user=lp user=lp group=lp # If your printer doesn't print the job remove the "@" from the following # line. (for example necessary for HP4M with a JetDirect Card) send_data_first@
In der hervorgehobenen Zeile fehlt normalerweise das @-Zeichen am Zeilenende.
Damit müßte der lpd eigentlich funktionstüchtig sein und man kann ihn mit
rclpd start
starten. Damit er zukünftig automatisch startet muss man noch zwei Änderungen vornehmen.
In der Datei /etc/dhcpd.conf auf dem DHCP-Server muss die folgende Zeile auftauchen:
option start-printdaemon "lpd";
Zur Auswahl stehen hier die Optionen lpd und cups. Leider ist in der Datei /tftpboot/dxs/var/ram/sbin/dhclient-script ein kleiner Dreher bei yes und no:
/tftpboot/dxs/var/ram/sbin/dhclient-script (ab Zeile 118)
if [ "x$new_start_printdaemon" != "x" ] && \ [ "x$new_start_printdaemon" != "xno" ]; then case $new_start_printdaemon in yes|cups*|CUPS*) start_lpd="no" start_cups="yes" ;; lp*|LP*|PLP*) start_lpd="yes" start_cups="no" ;;
Nun sollte das Drucken vom Client aus möglich sein.
Die Beschreibungen aus dem vorangegangenen Abschnitt gelten nur dann, wenn auf dem Server der lpd installiert ist. Bei Systemen mit cups weicht die Beschreibung ab.
Eine cups Beschreibung folgt
Die glibc ist eine der wichtigsten Systembibliotheken. Im Zusammenhang mit der Version 8.1 liefert SuSE zwei verschiedene Versionen dieser Bibliothek. Die Version glibc-2.2.5-152 ist für Computer mit i686 Prozessoren gedacht und die Version glibc-2.2.5-151 für Prozessoren unterhalb von i686. Die VIA Mini-ITX Systeme benötigen leider die Version für den i586.
Damit taucht ein Problem auf, wenn der Server den i686 Spezifikationen genügt, die Clients aber nicht. Bei der SuSE-Installation wird dann auf dem Server immer die i686 Version der glibc installiert und dann auch in das Dateisystem für den Client kopiert. Der Client bleibt damit beim Booten hängen.
Die einfachste Lösung besteht darin auch auf dem Server die i586-Version zu installieren, der Performance-Verlust dürfte nicht erheblich sein, zumal auf dem Server kaum noch Anwendungen laufen. Leider bietet SuSE keine Möglichkeit die Version der glibc zu wählen.
Hinweis: Die folgenden Schritte können theoretsich dazu führen, dass das System nicht mehr funktionsfähig ist. Von daher kann keine Garantie für den Erfolg übernommen werden.
Man kann aber auf dem Server die glibc-Version nachträglich ersetzen. Dazu muss man den Rechner mit einem Rettungssystem vom CD booten und die Festplatte z.B. nach /mnt mounten.
mount /dev/hda1 /mnt
Falls die Rootpartition auf hda1 liegt. Sollte man das Dateisystem auf mehrere Partitionen verteilt haben, so kann zusätzlicher Aufwand entsehen, da diese z.T. auch benötigt werden, z.B. /var. Man muss dann diese Partitionen auch mounten und zwar richtig ins Dateisystem:
mount /dev/hda2 /mnt/var
Wenn /var auf hda2 liegt.
Nun kann man das vorhandene Paket löschen:
rpm -e --nodeps --root /mnt glibc
Der Schalter -e veranlasst das Entfernen des Paketes. Der Schalter --nodep bewirkt dass das Paket gelöscht wird, obwohl andere Pakete es benötigen. Mit --root /mnt gibt man an, dass das zu bearbeitende Dateisystem bei /mnt beginnt.
Wenn die CD1 der SuSE-Distribution nach /cdrom gemountet ist, dann erfolgt die Installation der einfacheren glibc mittels:
rpm -ivh --root /mnt /cdrom/suse/i586/glibc-2.2.5-151.i586.rpm
Nach dem Einspielen des Paketes erneuert man die Paketbibliothek mit:
ldconfig -r /mnt
Danach kann man das System wieder normal booten und dann mit der Installation von ldc beginnen. Sollte man das System vorher schon einmal installiert haben, so muss man /tftpboot/dxs und /tmp/dxs löschen und das System erneut installieren.
Variation
Wer noch mutiger ist, der kann die Änderung auch direkt, ohne den Umweg über das Rettungssystem versuchen. Dazu geht man zuerst mit
init 1
in den Single-User Modus. Danach erzwingt man dann mit
rpm -Uvh --force /cdrom/suse/i586/glibc-2.2.5-151.i586.rpm
die Aktualisierung des glibc Paketes mit der niedrigeren Versionsnummer. Danach muss das System dann unbedingt sofort rebootet werden.
Manche Programme, wie z.B. der Windows-Emulator Win4Lin benötigen Schreibrechte in Verzeichnissen unterhalb von /var. Wie man solche Probleme meistern kann beschreibt ein weiterer Text.