Vom Alt-PC zum X-Terminal
Viele PC sind für aktuelle Anwendungen einfach nicht mehr so recht
geeignet, obwohl sie noch ordentlich funktionieren. Der Prozessor ist zu
langsam, der Hauptspeicher ist nicht ausbaufähig, die Platte ist viel zu
klein. Aber eigentlich ist es viel zu schade, das Gerät wegzuwerfen.
Auch aus dem Blickwinkel des Umweltschutzes ist die Vermeidung von
Elektronikschrott wünschenswert. Und oft, gerade auch an Schulen, fehlen
finanzielle Mittel, das Alteisen durch neue Rechner zu ersetzen. Linux
ist ein probates Mittel, die Geräte als X-Terminals weiter zu benutzen.
Hier soll im folgenden gezeigt werden, wie dabei vorgegangen werden
kann. Dabei sollen die nötigen Schritte genau genug und nachvollziehbar
dargestellt werden. Viele Abwandlungen und Verbesserungen sind denkbar
und beim konkreten Einsatz auch nötig.
- Grundlagen: X als netzwerkfähiges Grafiksystem
- Voraussetzungen, Vor- und Nachteile
- Kernel für das X_Terminal übersetzen
- netboot, Packet-Treiber, Boot-PROM
- bootp
- tftp
- NFS
- minimales Root-Filesystem für das X-Terminal
- xdm
- xfs
Einige Begriffe:
- X-Server
- Ein Programm, das die grafische Anzeige von Informationen und die
Entgegennahme von Tastatur- und Mauseingaben leistet. Es stellt diese
Dienste lokal und im Netz zur Verfügung.
- X-Client
- Eine Anwendung, die irgendeine Arbeit verrichtet und dazu dem Benutzer
Informationen anzeigt oder Eingaben von diesem benötigt. Es bedient sich
dazu der Dienste eines X-Servers und kommuniziert
mit diesem über das X-Protokoll.
- X-Protokoll
- X-Client und X-Server
müssen eine gemeinsame Sprache sprechen, um miteinander kommunizieren zu
können. Diese gemeinsame Sprache ist das X-Protokoll. Das X-Protokoll
kann seinerseits wieder auf verschiedenen Verbindungsprotokollen
aufsetzen. Lokal (X-Client und X-Server laufen auf dem gleichen Rechner) geschieht
das über UNIX Domain Sockets, im Netz über normale TCP sockets.
- libX11 und Co.
- Damit das X-Protokoll nicht von jedem
X-Client wieder neu implementiert werden muss,
ist dieses in Bibliotheken implementiert. Die Anwendungen werden meist
dynamisch gegen diese Bibliotheken gelinkt.
- X-Terminal
- bezeichnet ein Gerät, ausgerüstet mit Bildschirm, Tastatur und Maus,
auf dem ein X-Server läuft. Direkt als X-Terminals
gefertigte Geräte zeichnen sich meist durch kleine Gehäuse ohne Lüfter
und Festplatten aus. Manche davon stellen auch weitere Funktionen zur
Verfügung, etwa Sound oder lokale Windowmanager.
Die in letzter Zeit in Mode gekommenen Thin Clients verfügen darüber
hinaus über lokale Verarbeitungsleistung, meist in Form eines
Java-Interpreters und sprechen zusätzliche Protokolle (ICA, RDP).
- Windowmanager
- Ein Windowmanager ist ein X-Client mit der
speziellen Eigenschaft, das äußere Erscheinungsbild des Desktops zu
bestimmen und die Fenster der anderen X-Clients zu managen.
Wichtig ist, hier zu verstehen, daß der X-Server auf dem Client-Rechner
und die X-Clients auf dem fetten Server laufen.
Server
- Schneller Prozessor
- Für jedes aktive X-Terminal einige MB Hauptspeicher, je nach Art
der Nutzung zwischen 8 MB (ein paar xterms mit shell) und deutlich
über 30 MB (KDE, StarOffice)
- Je X-Terminal ab ca. 4 MB Plattenplatz.
- Software: X-Bibliotheken, xdm, NFS-Server,
bootp-Server,
tftp-Server, u.U. Fontserver. Diese können auch problemlos auf
mehrere Server verteilt werden.
Client
- Ethernetkarte mit Boot-PROM oder Diskettenlaufwerk
- möglichst Koprozessor (387, 486DX)
- 8 MB RAM. Große Bitmaps, viele Fonts, höhere Farbauflösung
erfordern mehr. 16 MB reicht meist aus. Bei Anwendungen, die viele
Fonts, Pixmaps usw. im Server abladen (Netscape), ist unter
Umständen auch mehr erforderlich.
Alternativen:
- swappen auf Platte: langsam, laut
- swappen über Netz: noch langsamer, nicht ganz einfach einzurichten
- möglichst gute Grafikkarte und Monitor, bei ISA-Bus problematisch.
Vorteile
- geringe oder keine Investition
- Ruhe am Arbeitsplatz (keine Platte, bei alten CPU's kein
Prozessorlüfter
- zentrale Daten- und Programmhaltung, geringer admin. Aufwand
Nachteile
- langsamer Bildaufbau, besonders bei großen bitmaps
- etwas fummelige Einrichtung, keyboard-mapping usw.
- bei vielen Clients und Nutzung von KDE, StarOffice usw.
fetter Server mit viel RAM notwendig
- Bei 386er und 486-SX ohne CoPro die MathEmulation einschalten
- Loadable Module Support kann raus
- Block Devices können alle raus. Ausnahmen: Swappen auf Platte,
Zugriff auf Floppy und/oder CD. Für Booten von Floppy wird der
Floppy-Support nicht benötigt.
- Networking options: IP: kernel level autoconfiguration ein
- BOOTP-Support ein
(alternativ kann RARP verwendet werden, das wird
hier aber nicht weiter besprochen.)
- Network device support: Ethernetkarte fest einkompilieren
- Character devices: Standard serial support für Maus
- Mouse Support: PS/2, falls vorhanden
- Filesystems: Alle lokalen Filesysteme, einschl. proc abwählen.
- Network File Systems: NFS fest eincompilieren
- Root file system on NFS ein
Wichtig: NFS-Filesystem und Ethernetkarte müssen fest in den
Kernel rein, nicht als Modul übersetzen.
Übersetzen mit make zImage. Den Kernel zunächst in
arch/i386/boot liegenlassen.
- Komerziell vertriebene Boot-PROMs kaum verwendbar
- Zwei Packete: etherboot (Markus Gutschke) und
netboot (Gero Kuhlmann).
- ich verwende hier netboot.
- Datei INSTALL in netboot-Quellen
erklärt alles folgende sehr genau (in englisch)
- Quellen auspacken (tar -xvzf netboot...)
- Zuerst Hilfsprogramme auf dem Server übersetzen:
cd netboot...
./configure
vi Makefile config.h (meist unnötig)
make clean ; make
su -c "make install"
- Dann mit deren Hilfe ein network bootable image des Linux-Kernels
erzeugen und nach /boot legen (mein Client-Rechner heißt
jojo):
mknbi-linux -d rom -i rom \
-k /usr/src/linux/arch/i386/boot/zImage \
-o bootImage
su
cp bootImage /boot/bootImage-jojo
- Einen Boot-ROM erzeugen. Dazu wird ein Packettreiber benötigt.
Einige Packettreiber sind in netboot bereits enthalten, andere
können dem crnwyr-Packet entnommen werden, das auf jedem
Simtel-Mirror zu finden ist. Am einfachsten hat man
es, wenn auf der Setup-Diskette der Ethernet-Karte des Clients
einer vorhanden ist. Liegt meist im Verzeichnis PKTDRV.
Meist sind
ein oder mehrere Parameter zu übergeben - Doku der Karte bzw.
readme lesen. Den Treiber über das Filesystem zugreifbar machen:
mount -t msdos /dev/fd0 /floppy
Jetzt:
make bootrom
- Standard-Kernel auswählen
- "look for boot drives first" mit "n" beantworten. Wenn
alternativ ein OS von der lokal vorhandenen Platte gebootet
werden soll, dann hier mit "y" antworten.
- "user defined packet driver" auswählen.
- Vollen Pfad angeben (im Bsp: /floppy/PKTDRV/pcipkt.com).
- Bei "command line arguments" ist wohl immer zumindest
ein "Software Interrupt Vector" anzugeben, wobei es sich
um ein Relikt aus finsteren DOS-Zeiten handelt.
Standard ist hier 0x60.
- Den ANSI display driver und weitere Optionen lasse ich hier
weg. Wenn auch lokale Systeme gebootet werden sollen, so läßt
sich mit dem ANSI-Driver ein schönes Boot-Menü bauen.
- netboot hat jetzt zwei Dateien erzeugt:
image.rom ist das eigentliche Boot-ROM,
image.flo eine Variante
davon, die von Diskette lädt. Letztere ist sehr sinnvoll, um
erstmal zu testen.
- image.flo auf leere Diskette kopieren:
dd if=image.flo of=/dev/fd0
- Später kann man dann image.rom in einen EPROM brennen.
Dafür wird
ein 32 kByte EPROM benötigt, die Bezeichnung enthält
normalerweise ein 27256. Vorsicht: Manche alte Netzwerkkarten
unterstützen nur 16 kByte ROMs. Im Packet etherboot gibt es die
Möglichkeit, komprimierte Images zu schreiben, die dann auch dort
reinpassen.
Portmapper und NFS-Server müssen gestartet sein.
Damit Hostnamen zu IP-Adressen aufgelöst werden können, sollten
sowohl Server als auch Clients in /etc/hosts eingetragen sein
oder ein Nameserver verwendet werden.
vi /etc/exports:
/var/tftpboot/jojo jojo(rw,no_root_squash)
no_root_squash ist wichtig, sonst werden Berechtigungen
auf nobody gemappt. Der Hostname muß explizit eingetragen sein, sonst
wird no_root_squash ignoriert.
Konzept:
- keine Kernelmodule, alles notwendige fest drin
- absolut minimale Umgebung
- init startet direkt den X-Server
- X keyboard extensions sind eigentlich sinnvoll,
aber: mehr Dateien zu kopieren
deshalb: mapping auf Konsole laden, X übernimmt dieses
mkdir /var/tftpboot/jojo
cd /var/tftpboot/jojo
mkdir etc
mkdir dev
mkdir bin
mkdir lib
mkdir sbin
Welche binaries werden gebraucht?
cp /usr/X11R6/bin/XF86_S3 bin
cp /bin/loadkeys bin
cp /sbin/init sbin
Devices?
for d in console tty tty0 tty1 tty2 ttyS0 ttyS1 psaux mem null
do
cp -a /dev/$d dev
done
shared libs? -- mit ldd herausfinden
cp /usr/lib/libz.so.1 lib
cp /lib/libm.so.6 lib
cp /lib/libdl.so.2 lib
cp /lib/libc.so.6 lib
cp /lib/ld-linux.so.2 lib
cp /lib/libcrypt.so.1 lib
Einstellungen in etc?
- vi etc/inittab
# default runlevel: S
id:S:initdefault:
# load a keyboard map
kb:S:once:/bin/loadkeys /etc/default.map
# directly start X and broadcast for an xdm server
sj:S:once:/bin/XF86_S3 -nolock -broadcast
- Vollständige Tastaturtabelle übernehmen (unter der Voraussetzung,
daß auf Server und Client dasselbe Mapping verwendet wird.)
dumpkeys > etc/default.map
- Einstellungen X11?
cp /usr/X11R6/lib/X11/rgb.txt etc
mkdir etc/X11
(bei Debian liegt XF86config dort, bei SuSE-Servern oder
direkt von www.xfree86.org
besorgten Servern liegt XF86Config direkt in /etc.)
vi /etc/X11/XF86config
Section "Files"
RgbPath "/etc/rgb"
FontPath "tcp/truckle:7100"
FontPath "tcp/truckle:7101"
EndSection
#
Section "Keyboard"
Protocol "Standard"
AutoRepeat 300 30
LeftAlt Meta
RightAlt ModeShift
ScrollLock Compose
XkbDisable
EndSection
#
Section "Pointer"
Protocol "Microsoft"
Device "/dev/ttyS0"
Emulate3Buttons
Emulate3Timeout 50
EndSection
#
Section "Monitor"
Identifier "moni"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 31.5 - 64.3
VertRefresh 50-100
#
# 800x600 @ 85 Hz, 55.84 kHz hsync
Modeline "800x600" 60.75 800 864 928 1088 600 616 621 657 -HSync -VSync
# 1024x768 @ 70 Hz, 56.5 kHz hsync
Modeline "1024x768" 75 1024 1048 1184 1328 768 771 777 806 -hsync -vsync
EndSection
#
Section "Device"
Identifier "S3"
Vendorname "S3"
BoardName "unknown"
EndSection
#
Section "Screen"
Driver "accel"
Device "S3"
Monitor "moni"
DefaultColorDepth 16
Subsection "Display"
Depth 16
Modes "1024x768" "800x600"
ViewPort 0 0
EndSubsection
EndSection
Wenn man noch keine geeigneten Modelines hat, so kann man
xf86config verwenden, die Ausgaben statt nach
/etc/X11/Xf86Config in eine andere Datei schreiben lassen und
die Modelines von dort kopieren.
- Fertig ?
-
du -s . ergibt bei mir ca. 3.3 MB
- je nach Vorkonfiguration durch Distribution reicht es meist, den
runlevel in /etc/inittab des Servers auf 3 (SuSE, Debian)
bzw. 5 (RedHat) zu setzen.
- Weitere Einstellungen unter /etc/X11/xdm (Debian) bzw.
/usr/X11R6/lib/X11/xdm (SuSE)
- Dateien:
- xdm-config
- Pfade für andere Config-Dateien, binaries etc.
- xdm.options
- globale Optionen für xdm
- Xaccess
- Berechtigungen für Login, chooser,
broadcast, indirect
- Xresources
- Aussehen, keyboard für Login-Fenster, xconsole und
chooser
- Xservers
- lokal zu startende XServer oder X-Terminals,
die kein XDMCP verstehen
- Xsetup
- Shellscript zum Einstellen nicht lokaler XServer
- Xstartup
- utmp-Eintrag anlegen, /etc/nologin auswerten etc.
läuft unmittelbar nach dem login mit root-Berechtigung.
- sehr sinnvoll, damit Fontdateien nicht kopiert und auch nicht per
NFS freigegeben werden müssen. Fonts werden einmal zentral
installiert.
- normaler xfs für bitmap- und Type1-Fonts zuständig.
- Type1-Fonts werden von xfs gerastert, der X-Server muß nur noch
mit Bitmap-Fonts hantieren. Vor allem für schwächliche Clients sehr
sinnvoll (386 ohne CoPro).
- xfstt macht das gleiche für True-Type-Fonts.
- xfs auf Port 7100, xfstt auf 7101
- xfs-Einstellungen in /etc/X11/xfs (Debian) bzw.
/usr/X11R6/lib/X11/xfs (SuSE).
- wichtigste Einstellung ist "catalogue=". Gibt Pfade an, unter denen
Fonts gefunden werden. Wie bei X muß dort eine Datei fonts.dir
bzw. bei Type-1 Fonts fonts.scale existieren.
Autor: Frank Richter,
frichter@truckle.in-chemnitz.de