|
Linux-Arbeitskreis Hamburg |
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.
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.
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
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.
.