= ThinClient lokal booten =

Normalerweise ist es am besten, einen ThinClient - wie auf der Seite LinuxTerminalServer beschrieben - über das Netzwerk von einem zentralen LTSP-Server aus zu booten. Auf diese Art und Weise kann man alle Clients im Netzwerk am besten zentral einrichten und verwalten.

Dennoch kann es sinnvoll sein, einen ThinClient von einem lokalen Medium zu booten. Dies kann z.B. sein, wenn das Netzwerk entweder sehr langsam ist oder erst noch richtig eingerichtet werden muss. Auch bei grundsätzlichen Problemen mit dem Netboot kann eine lokale Installation helfen.



== komplette lokale Installation ==

Generell muss man sich überlegen, wie viel man lokal installieren will. Im Grunde kann man einen vollwertigen Linux-Rechner installieren und dann dort einen X-Server mit der "-query ..."-Option starten. Oft reicht es aber auch, viel weniger zu installieren.



== lokale Installation von Kernel und Initramdisk ==

Eine andere Sache ist es, nur den Kernel und die initrd lokal zu installieren. In dieser kann man dann ggf. lokale Einstellungen vornehmen und dann mit Hilfe des bereits funktionierenden Linux-Systems das Netzwerk initialisieren und den Rest des Systems immer noch per NFS vom Server beziehen (um so ein zentrales, identisches System zu erhalten).

Ich habe hier einen ThinClient, der einen internen Flash-Speicher von 32MB hat. Diesen würde ich gerne per WLAN anbinden. In diesen Speicher passt kein komplettes Linux-System - allerdings reicht es, um mit Hilfe einer initrd das WLAN einzurichten und dann dort weiterzumachen.

Tips zum Thema habe ich mir aus dem [LTSP-Wiki|http://wiki.ltsp.org/twiki/bin/view/Ltsp/BootingFromLocalDevice] geholt (ist leider viel zu kompliziert, weil der Autor mehrere Dinge gleichzeitig gemacht hat).

Als erstes habe ich den Client an einem normalen Netzwerk normal gebootet, um mich auf ihm einloggen zu können. Der Flash-Speicher ist wie eine gewöhnliche Festplatte angebunden, also habe ich ihn mit '''cfdisk''' eingerichtet und mit '''mke2fs''' formatiert. Ich habe die Partition danach gemountet und dann den '''grub-Bootloader''' installiert. Zum Abschluss habe ich alle boot-Dateien des Clients kopiert:

 mke2fs /dev/hda1
 mount /dev/hda1 /mnt
 grub-install --root-directory=/mnt /dev/hda
 cp -a /boot/* /mnt/boot/

Dabei ist zu beachten, daß ich in meinem LTSP-Client die ganz normalen Debian-Kernel-Pakete installiert habe. Beim Booten per LTSP werden nämlich der Kernel sowie die initrd per tftp vom LTSP-Server geholt. Ich habe in meinem System aber dennoch (quasi unbenutzte) Dateien mit gleichem Inhalt in ''/boot/''. (Bei Kernel-Updates kopiere ich diese dann jeweils in das tftp-Verzeichnis.)

Nun legen wir eine grub-typische Datei ''/mnt/boot/grub/menu.lst'' an. Diese sieht z.B. so aus:

 default=0
 timeout=0
 title ThinClient
       root (hd0,0)
       kernel /boot/vmlinuz ro root=/dev/hda1
       initrd /boot/initrd.img

Als nächstes habe ich den Client rebootet, im BIOS-Menü die Bootreihenfolge umgeschaltet und siehe da: Der Client hat ruck-zuck gebootet. Er hat ohne Probleme den Anschluss ans NFS gefunden, als wäre nichts gewesen.

Eventuell sollte man anhand seiner bisherigen Enistellung noch die Kernel-Aufrufzeile anpassen. Oben steht z.B. hda1, obwohl das offensichtlich nicht als root-Device genommen wird. Dennoch lief es erstmal so. :-)



== Manipulation der initramdisk ==

Bisher ist ja eigentlich noch nichts spannendes passiert. Nun will ich jedoch, daß die Initramdisk meinen WLAN-Adapter initialisiert, sich in ein WLAN einhängt, eine OpenVPN-Verbindung aufbaut (weil wir ja wohl einem WLAN nicht über den Weg trauen) und dann darüber das NFS-Laufwerk einbindet.

Grundsätzlich empfehle ich das Studium folgender manpage:

 man initramfs-tools

Wichtig zu wissen ist, daß man mit dem Parameter '''break''' in der Kernel-Startzeile den Startvorgang an verschiedenen Stellen unterbrechen kann. Das hilft beim Debuggen ungemein!



=== Installation zusätzlicher Treiber in der Initramdisk ===

Ich habe einen WLAN-Adapter von "hama" in Form eines USB-Sticks. Das ist insoweitinsoweitganz>> <<ganz >>praktisch, als im Grunde alle [ThinClient]s einen USB-Port besitzen. Er läuft mit dem '''rt73'''-Treiber. Dieser ist leider in Debian Etch nicht standardmäßig vorhanden. Ich musste auf ein Paket '''rt73-source''' aus "experimental" zurückgreifen, das <<(am besten auf einem anderen System) >>mit

 module-assistant build rt73 -l 2.6.18-4-486

in ein Modul-Paket übersetzt wurde. Die Angabe der Kernelversion ist nötig, weil der Kompilierungsrechner in der Regel einen anderen Kernel benutzt als die Thin Clients.

Ansonsten sei hier <<generell >>gesagt, daß für irgendwelche andere Hardware natürlich im LTSP-Client-System alle benötigten Treiber installiert sein sollten. Damit <<solltekann>> man ggf. auch erstmal <<testentesten,>> <<können, >>ob man den Adapter überhaupt "von Hand" in Betrieb nehmen kann.

Ich habe <<dann (im LTSP-chroot) >>das folgende Hook-Skript ''/etc/initramfs-tools/hooks/wirelessboot'' (mit gesetzten x-Bit) angelegt:

 #!/bin/sh
 . /usr/share/initramfs-tools/hook-functions

 PREREQ="lvm"
 prereqs()
 {
       echo "$PREREQ"
 }

 case $1 in
       prereqs)
               prereqs
               exit 0
       ;;
 esac

 echo "rt73-Modul einbinden..."
 force_load rt73
 cp -a /root/wireless/* "${DESTDIR}/"

Wie man sieht, kopiere ich ein Verzeichnis ''/root/wireless'', das ich folgendermassen gefüllt <<habe (auch im LTSP-chroot):habe:>>

 <<mkdir -p /root/wireless/etc/Wireless/RT73STA/
 cp /etc/Wireless/RT73STA/rt73.bin /root/wireless/etc/Wireless/RT73STA/
 mkdir /tmp/wireless
 >>cd <</tmp/wireless/tmp>>
 aptitude download wireless-tools libiw28<< openvpn>>
 <<fordpkg>> <<package-x>> <<inlibiw28*>> <<*.deb/root/wireless
>> <<; do  >>dpkg -x <<$packagewireless-tools*>> <</root/wireless/ ; done/root/wireless>>
 <<rmmkdir>> <<-r-p>> <</usr/share/doc/root/wireless/etc/Wireless/RT73STA/>>
 <<rmcp>> <<-r/etc/Wireless/RT73STA/rt73.bin>> <</usr/share/man/root/wireless/etc/Wireless/RT73STA/>>

Man kann nun noch nach eigenem Ermessen wieder Dateien löschen (die manpages brauchen wir wirklich nicht in der ramdisk), aber das sollte selbsterklärend sein.

Obiges Hook-Skript wird nun während der Installation ausgeführt und bindet sowohl das Kernel-Modul als auch mein wireless-Verzeichnis in die ramdisk ein. Die eigentliche Erzeugung starte ich <<(wieder auf dem chroot-System) >>mit

 <<cd /root/
 >>mkinitramfs -o initrd.img-2.6.18-4-486 2.6.18-4-486

Der letzte Parameter ist übrigens wieder dem Umstand geschuldet, daß ich diesen Befehl ja in einem chroot-Jail auf meinem LTSP-Server gebe, der einen ganz anderen Kernel haben kann als mein Client-System benutzt. Die neue initramdisk wird so im aktuellen Verzeichnis erzeugt und kann ggf. an Ihren Platz kopiert werden (''/mnt/boot/'', wenn man obige Vorbereitungen getroffen hat).

Zum Debuggen ist evtl. der Parameter "-k" interessant, der den Inhalt der ramdisk als Verzeichnis erhält, so daß man diesen nochmals kontrollieren kann.



=== automatischer Aufbau einer WLAN-Verbindung ===

<<Die Basiskonfiguration von mkinitramfs steht in ''/etc/initramfs-tools/initramfs.conf''. Allerdings kann man die dortigen Einstellungen wie z.B. das Device, von dem wir booten möchten, überladen. Dazu erstellen wir eine Datei: ''/etc/initramfs-tools/conf.d/wireless''

 DEVICE=rausb0

''(Hier sollte zumeist sowas wie eth1 stehen, aber der rt73-Treiber nennt sein Device nun mal rausbX.)''
y
>>Grundsätzlich liegen die boot-Skripte in ''/etc/initramfs-tools/scripts/''. Hier gibt es Unterverzeichnisse für verschiedene Stadien des Bootvorgangs.<< In ''/usr/share/initramfs-tools/init'' kann man im Sourcecode sehen, in welchem Stadium des Bootvorganges welche Skripten aufgerufen werden müssen (''maybe_break ...-Zeilen''). Im konkreten Fall des wireless Adapters ist das '''mount'''-Stadium das richtige. In den vorherigen premount-Skripten wird udev geladen, das uns hilft, die USB-Module richtig zu laden. Nach den mount-Skripten wird dann im nfs-Skript das Interface, das wir bei DEVICE angegeben haben, per DHCP eingerichtet und benutzt.


...to be continued

=== OpenVPN ===

...to be continued
<<
=== Auf welchem System erzeugt man das alles? ===

Eigentlich ist es nicht so sinnvoll, das reguläre LTSP-System mit all diesem Installations-Kram vollzumüllen. Die Erzeugung des KErnel-Modul-Paketes mit Hilfe von module-assistant ging auch gut auf einem anderen System. Für die übrigen Sachen habe ich mir einfach eine Kopie des chroot-Verzeichnisses angelegt, mit der ich dann experimentiert habe.

Im Grunde reicht es dann, wenn man später die entstandene initrd in den TFTP-Server kopert und fertig. Man muss also das Client-System gar nicht verändern. Darüberhinaus halte ich es ggf. für sinnvoll, die verwendeten Treiber und Tools (z.B. das rt73-Kernelmodul sowie die wireless-tools in obigem Beispielfall) auf dem echten LTSP Client-System zu installieren, um ggf. im laufenden Betrieb Konfigurationen ändern zu können.

Ein Problem hierbei entsteht bei einem Kernel-Update. Dann wird nämlich in der Regel auch die initrd automatisch neu gebaut. Hier ist zu überlegen, ob man diese jeweils komplett neu erzeugt oder doch obige Skripten und Verzeichnisse auf dem Produktivsystem belässt (womit die erzeugte initrd dann natürlich nur noch für wireless Terminals taugt und nicht mehr für normale...).