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 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 insoweitganz praktisch, als im Grunde alle ThinClients 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 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 gesagt, daß für irgendwelche andere Hardware natürlich im LTSP-Client-System alle benötigten Treiber installiert sein sollten. Damit kann man ggf. auch erstmal testen, ob man den Adapter überhaupt "von Hand" in Betrieb nehmen kann.

Ich habe 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:

  cd /tmp
  aptitude download wireless-tools libiw28
  dpkg -x libiw28* /root/wireless
  dpkg -x wireless-tools* /root/wireless
  mkdir -p /root/wireless/etc/Wireless/RT73STA/
  cp /etc/Wireless/RT73STA/rt73.bin /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 mit

  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 #

Grundsätzlich liegen die boot-Skripte in /etc/initramfs-tools/scripts/. Hier gibt es Unterverzeichnisse für verschiedene Stadien des Bootvorgangs.

...to be continued

OpenVPN #

...to be continued