Lokale Erweiterungen

Neben der Grundfunktionalität (siehe ClientConfiguration) der OpenSLX Linux Diskless Clients ist es für viele Anwender von Interesse, dass sie eigene Anwendungen und Erweiterungen hinzufügen können. Diese sollten dann auch nicht bei Updates verschwinden. Erweiterungen direkt im Code fallen deshalb aus. Direkte Änderungen im exportierten Rootfilesystem der Clients sollte man ebenfalls vermeiden, da diese leicht Updates zum Opfer fallen könnten. Anzumerken ist hier, dass evtl. gesetzte Runlevellinks (in boot.d, rcS.d, rcN.d) keine Funktion haben, da sie im InitialRamFS (Stage3) komplett neu erzeugt werden.

Beispiele für solche Erweiterungen liefert PostinitSnipplets.

InitalRamFS

Zusätzliche Skripten oder Kommandos, die im InitialRamFS aufgerufen werden sollen, müssen dieser am besten direkt hinzugefügt werden. Hier muss dann auch der Anwender sicherstellen, dass alle benötigten Komponenten aufgenommen werden. Es gibt die Möglichkeit die beiden Skripten preinit.local und postinit.local zu benutzen. Diese werden einmal zu Beginn des InitialRamFS (noch nichts gemountet) und einmal ziemlich zum Schluss (kurz bevor switch_root das Hauptskript des InitialRamFS beendet) ausgeführt.

# Beispiel für postinit.local
# zum Anlegen des Runlevellinks eines eigenen Skripts (vorher Variablen und Funktionen laden)
. /etc/sysconfig/config
. /etc/distro-functions
rllinker eigenes-skript 25 02
# etwas in eine Datei des späteren Stage4 schreiben
echo "Das steht nun im motd des Clients" > /mnt/etc/motd
# mounten einer NFS-Quelle
mkdir /mnt/var/ziel
mount -n -t nfs -o ro,nolock,tcp 10.8.1.2:/quelle /mnt/var/ziel

Erwartet werden sie von mkdxsinitrd in /var/opt/openslx/config/default/initramfs oder spezifischer in /var/opt/openslx/config/<system-name>/default/initramfs. (Statt des system-name>/default kann das auch per Client definiert werden, der anhand seiner MAC identifiziert wird: system-name>/01-<MAC>. Ersetzen von ":" durch "-") Nachdem Änderungen an diesen Skripten erfolgt sind, muss auf jeden Fall ein neues InitialRamFS erstellt werden (immer notwendig für preinit.local, nur notwendig für postinit.local wenn kein file get benutzt wird). Siehe dazu auch: MkinitrdHowto. Möchte man bestimmte Kommandos in das "normale" Init verschieben (nach dem Beenden des InitialRamFS - hier stehen dann alle gewohnten Programme zur Verfügung und man ist nicht auf das begrenzte Subset angewiesen) kann man das über generierte Einträge in die boot.slx erreichen:

echo -e "# entry added by $0: $date" \
  >>/mnt/etc/${D_INITDIR}/boot.slx

Bootup Skripten

Eine klassische Erweiterung bei den Bootup-Skripten (je nach Distribution rcS.d, boot.d, ...) ist die Datei boot.local. Diese wird nach den anderen Bootup-Skripten ausgeführt. In diesem Skript steht die volle Funktionalität eines Systems zur Verfügung. Soll hier eine andere Reihenfolge eingestellt werden, kann auch ein eigenes Skript angelegt werden, welches dann über die Variable D_INITSCRIPTS (einzustellen in distro-specs/ distro /config-version) gestartet werden kann.

Runlevel Skripten

Soll ein spezieller Dienst wärend der normalen Runlevel gestartet werden, wird dafür ein Runlevel-Skript benötigt. Die Start- und Stop-Links sollten wärend des Laufes des InitialRamFS in postinit.local erzeugt werden. In diesem Stadium gibt es nur eine eingeschränkte Auswahl an Programmen ("busybox" mit mount, sed, cp, ...). Zudem ist zu beachten, dass das Rootverzeichnis von Stage4 noch unterhalb von /mnt hängt. Wenn man in postinit.local /etc/functions einbindet, kann man spezielle SLX-Funktionen, wie "waitfor datei", "nfsmnt quelle ziel", "usleep NNNNN", ... verwenden.

Die Runlevel-Skripten selbst und evtl. Hilfsskripten stellt man via /var/opt/openslx/config/default/rootfs oder spezifischer in /var/opt/openslx/config/<export-name>/{default,<client-name>}/rootfs bereit. Aus /var/opt/openslx/config/<system-name>/default wird (in Zunkunft automatisch) in Stage2 eine Konfiguration nach /tftpboot/client-config/<system-name>/default.tgz oder client-spezifisch erzeugt. Für den Überblick zu den verschiedenen Verzeichnissen siehe auch BootRootVerzeichnisse.