Linux-Arbeitskreis Hamburg

Linux Diskless Clients - Erweiterungen

Die Installation spezieller eigener Software ist auch auf LDC-Systemen möglich. Gelegentlich sind diese Erweiterungen aber mit etwas Arbeit verbunden, vor allem wenn Schreibrechte für spezielle Verzeichnisse benötigt werden.

Der vorliegende Text beschreibt die wichtigsten Problemkreise anhand des Windows-Emulators Win4Lin. Diese Software benötigt drei Erweiterungen:

Die einzelnen Schritte können exemplarisch als Vorlage für eigene Erweiterungen dienen.

Hinweis: Aus der vorliegenden Konfigurationsbeschreibung, speziell für Win4Lin, kann nicht geschlossen werden, dass eine derartige Konfiguration rechtlich zulässig ist. Im Zweifelsfall bitte beim Anbieter nachfragen.

1. Ein eigener Kernel

Win4Lin benötigt einen speziellen Kernel, dazu stehen auf der Website von Netraverse zwei Patches bereit, die auf den Standarkernel angewendet werden müssen. Zusätzlich erfordert das LDC-System in der vorliegenden Form einen inittar-Patch. Insgesamt sind also drei Patches anzuwenden, bevor mit dem Compilieren eines eigenen Kernel begonnen werden kann.

Der Ablauf ist also folgendermaßen:

Das fertige Ergebnis  besteht aus der Datei bzImage und dem Modulverzeichnis.

Die Dateien müssen nun an die richtige Stelle kopiert werden:

cp  -a  2.4.19-TMPFS  /tftpboot/dxs/lib/modules/
cp  bzImage  /tftpboot/dxs/boot/bzImage-2.4.19-TMPFS

Nun muss nur noch der Link in /tftpboot/dxs/boot auf diesen Kernel gesetzt werden.

rm bzImage
ln -s bzImage-2.4.19-TMPFS bzImage

Dann müssen noch die richtigen Module in das inittar gepackt werden, also erzeugen wir es neu.

./mkdxsinittar -dxsrd /tftpboot/dxs  -k bzImage

Damit steht der neue Kernel zur Verfügung.

2. Schreibrechte in /var

Win4Lin benötigt Schreibrechte im Verzeichnis /var/win4lin. Eine ähnliche Situation kann auch im Zusammenhang mit anderen Programmen auftreten. Das Verzeichnis /var ist aber nicht exportiert. Es würde auch nicht viel helfen es beschreibbar zu machen, dann würden nur die Schreibzugriffe verschiedener Clients kollidieren.

Ein Weg besteht darin /var/win4lin auf ein lokales Verzeichnis, im RAM zu linken. Um Speicherplatz zu sparen kann man dass alle statischen Verzeichnisse unterhalb von /var/win4lin (solche auf die kein Schreibzugriff erfolgt) auf die Serverplatte verlinken.

Dazu muss die /etc/exports erweitert werden:

/var/win4lin        192.168.1.0/255.255.255.0(ro,no_root_squash)

zum Aktivieren der Änderung wird der NFSServer neu gestartet.

Für das Verlinken legt man sich in /tftpboot/dxs/var noch ein Verzeichnis netra an:

mkdir  /tftpboot/dxs/var/netra

und einen Link für /var/win4lin

ln -s /RAM/win4lin /tftpboot/dxs/var/win4lin

Dann werden noch zwei Dateien benötigt und daher kopiert:

cp /etc/mrgssv.sh /tftpboot/dxs/etc.s
cp /etc/init.d/init.d/Win4Lin  /tftpboot/dxs/etc.s/init.d/Win4Lin

Wenn man die Konfigurationsdatei /etc/default/merge für die Clients unterschiedlich haben möchte, dann sind noch folgende Schritte notwendig:

mv  /tftpboot/dxs/etc.s/default/merge  /tftpboot/dxs/etc.s/default/merge.ldc
ln -s  /RAM/tmp/merge  /tftpboot/dxs/etc.s/default/merge

Dann kann man wie im folgenden Script Teile der Datei beim Booten verändern.

Nun kann man mit dem folgenden Shell-Programm den Win4Lin Dämon vnetd starten

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin
mount 192.168.1.1:/var/win4lin /var/netra
mkdir /RAM/win4lin
ln -s /var/netra/* /RAM/win4lin
ln -s /var/netra/.[^.]* /RAM/win4lin/
hier=$(pwd)
cd /RAM/win4lin
rm -f log memfs mnt mrgdev tmp console.disp
mkdir memfs mnt log tmp
cd $hier
sed -e "s/MERGE_NODENAME=.*/MERGE_NODENAME=\"$HOSTNAME\"/" /etc.s/default/merge.ldc > /RAM/tmp/merge
cp /etc.s/mrgssv.sh /etc/
/etc/init.d/Win4Lin start

Das Script mountet das (nicht beschreibbare) Verzeichnis /var/win4lin vom Server nach /var/netra und legt dann unter /RAM ein Verzeichnis an. Für alle Dateien und Verzeichnisse unterhalb von /var/netra kommt dann ein Link nach /RAM/win4lin. Für die Dateien und Verzeichniss, die beschreibbar sein müssen werden die Links anschließend gelöscht und leere Verzeichniss angelegt.
Dann wird noch die Konfigurationsdatei merge kopiert, wobei auch gleich der Rechnername angepasst wird, das Shellscript mrgssv.sh wird einfach nur nach /etc/kopiert. Danach kann dann der Dämon starten.

Diese Progammzeilen lassen sich gut in ein Startscript win4lin (jetzt klein geschrieben) einbinden, für das man unter /etc/init.d/skeleton ein Muster findet. Das Startscript kann dann über die entsprechenden Links auch automatisch starten.

Das Mounten des Verzeichnisses /var/win4lin an dieser Stelle ist nicht optimal, besser wäre

3. Homeverzeichnisse per NFS

Eigentlich müßte Win4Lin jetzt starten können. Leider hat das Programm eine kleine Schwäche. Win4Lin kann nich starten, wenn das Windowsverzeichnis mit dem Homeverzeichnis per NFS exportiert wurde. Die Beschreibung für dumme Terminals funktioniert trotzdem, da zwar das Homeverzeichnis per NFS bezogen wird, der dortige Link auf win aber auf ein lokales Laufwerk zeigt.

In Falle der Diskless Clients muss aber beides per NFS bezogen werden. Auch wenn das Problem nach Auskunft des Netraverse-Supports nicht lösbar ist, gibt es einen einfachen Weg. Win4Lin benötigt nämlich nur in der Wurzel von win lokale Schreibrechte, um dort eine Lock-Datei anzulegen. Der Rest darf per NFS gemountet sein.

Also kommt der gleiche Trick zur Anwendung, wie bei /var/win4lin, wobei eine Einschränkung bleibt, die Installation darf nicht wirklich im Home-Verzeichnis des Benutzers liegen, zumindest nicht unter win. Sehr einfach ist ein Serverlaufwerk wie /thintelligent, das beschreibbar gemountet wird, oder auch ein Verzeichnis im Homeverzeichnis, wenn es dann aber einen anderen Namen hat, hier z.B. win.ok.

Dann kann man mit dem folgenden Script Windows starten:

rm -rf /tmp/win4lin
rm -f ~/win
rm -f ~/.merge
mkdir -p  /tmp/win4lin/win
mkdir /tmp/win4lin/.merge
ln -s ~/win.ok/* /tmp/win4lin/win/
ln -s ~/.merge.ok/* /tmp/win4lin/.merge/
ln -s /tmp/win4lin/win ~/win
ln -s /tmp/win4lin/.merge ~/.merge
win

Die Programmzeilen lassen sich gut in das Startprogramm für den Emulator integrieren, das auf den zugehörigen Seiten beschrieben ist.

Auf diese Art kommt der gleiche Emulator zum Start, wie auf dem Applikationsserver. Das schafft eventuell lizenzrechtliche Probleme, vor allem da hier in der Regel die Server-Version startet und nicht die Arbeitsplatzversion.

.


Kritik, Anregungen und Ergänzungen willkommen. Zusammengestellt von Uwe Debacher und Bernd Burre, letzte Änderung am 27.01.2006
Impressum