Setup eines SLX-Clients¶

Für eine flexible Konfigurierbarkeit einer grösseren Anzahl von Systemen (exportierbare Linux-Varianten = "Vendor-OS", die von Clients gebootet werden können, siehe auch VerwendeteBegriffe), wurde ein komplett neuer Installer entwickelt, der sich um die ersten beiden Stadien (Stage1 und Stage2, siehe BetriebsKonzept) einer OpenSLX Umgebung kümmert. Der modulare Installer deckt dabei folgende Aufgaben ab:

Stage1¶

Im ersten Stadium erfolgt die Installation oder das Cloning einer beliebigen Distro (Vendor-OS) in ein Unterverzeichnis auf dem Prepare Server (/var/opt/openslx/stage1/<vendor-os>), beispielsweise einer SuSE10.2. Diese würde sinnvollerweise in /var/opt/openslx/stage1/suse-10.2 landen. Bei einem Klon sollte dieses durch ein Suffix wie "-<source>" kenntlich gemacht werden, was slxos-setup übernehmen kann. Dieses System ist nicht dafür gedacht, direkt exportiert zu werden, sondern die Grundlage für Erweiterungen (seitens des Admins) und Updates zu dienen. Ausgehend von diesem System werden dann exportfähige Einheiten auf dem Prepare oder dem Export-Server bereitgestellt.

Dieses Stadium unterteilt sich in vier Substadien:

• Stage1A - hier wird mithilfe der Unix-Basis-Tools aus dem OpenSLX-Paket und dem Host-System eine Chroot-Umgebung mit Busybox aufgebaut.
• Stage1B - Wechsel in die Busybox-Umgebung und Laden der Initial-Pakete des Zielsystems und damit erstellen einer zweiten Chroot-Umgebung diesmal aus den Zielsystempaketen. Verwendung von rpm in RPM-basierten Umgebungen und von dpkg für Debian-basierte Installationen. Gentoo o.ä. sollten sich hier ebenfalls nicht zu schwer integrieren lassen.
• Stage1C - Wechsel in die Zielsystemumgebung (chroot) und Start eines regulären Zielsystem-Setups.
• Stage1D - Zielsystemumgebung ist soweit komplett, um einen Meta-Installer für alle weiteren Pakete zu starten. Dieses ist dann auch der Moment, in dem verschiedene SLX-Plugins (siehe dazu auch PluginKonzept) dem installierten System hinzugefügt werden können. Dieses muss immer vor dem Export (Stage2) erfolgen.

Stage1A¶

Stage1A ist der erste Schritt des Setups eines Systems im Stage. Hier werden als Tools lediglich die üblichen Shells (beliebig: sh, ...), Shell-Kommandos (cp & Co.) und Perl erwartet. Perl dient zum einen zur Kommunikation mit dem Konfigurator-Backend und zum anderen als zu kopierende Komponente für die Installation Debian-basierter Systeme. Im Stage1A wird eine Chroot-Umgebung bestehend aus einer Busybox (Bestandteil des OpenSLX-Paketes), Perl (kommt aus dem Host-System) und den dazu benötigten Bibliotheken zusammengestellt. An dieser Stelle wird ebenfalls das Stage1B/C Skript incl. notwenidiger Konfigurationsdateien kopiert. Sollte eine lokale Installationsquelle (Verzeichnis) verwendet werden, muss diese von "aussen" in die Busybox-Chroot-Umgebung gemountet werden. Eventuell kann man stattdessen den in der Busybox einzuschaltenden HTTP-Server für eine Übersetzung einer lokalen NFS, Pfad oder CD/DVD-Quelle benutzen, um im Chroot per Netzquelle installieren zu können. Das würde ersparen die jeweilige Quelle in die Chroot-Umgebung einzubinden.

Diese Aufgaben erledigt slxos-setup: Anlegen der notwendigen Verzeichnisse, Kopieren der Busybox und notwendiger Bibliotheken (C-Bibl. und Zusätze, wie libresolv, libnss*), Anlegen der Links für die Busybox-Applets.

Stage1B¶

Wechsel in das frisch erzeugte Chroot und Aufruf des Stage1B-Skriptes, welches entweder ein dbootstrap für Debian-Systeme oder eines RPM2CPIO-Skripts für RPM-basierte Systeme anschiebt. Ein Teil der Konfigurationsoptionen wird per Konfigurationsdatei (etc/bootstrap.settings) oder per Environment übergeben.

Im RPM-Fall werden insgesamt nur einige Pakete (glibc, rpm, zlib, bzip2, popt) initial benötigt, um im Stage1C ein rpm erfolgreich ausführen zu können.

Stage1C¶

Dieses Stadium spielt die Basis-Installationen der jeweiligen Distribution ein. Hierfür wird in das neue Chroot gewechselt, welches nun eine voll-funktionale APT- bzw. RPM-Installationsumgebung zur Verfügung stellt. Wärend in Debian-basierten Systemen Updates und weitere Pakete direkt durch apt-get im Chroot installiert werden kann, nutzen RPM-Systeme dazu die Dienste von Smart (smartpm).

Stage1D¶

In diesem Stadium greifen dann je nach System verschiedene Meta-Packager zur Vervollständigung der Basisinstallation auf das jeweils gewünschte System. Hier kann der Administrator selbst noch Pakete und Software nachpflegen und die Konfiguration ergänzen. Dann funktioniert aber nicht mehr unbedingt der SLX-Update-Mechanismus.

Die Grundinstallation sorgt für ein nach dem Export bootfähiges SLX-System. Einige Komponenten, die über den Basisbetrieb hinausgehen, werden als PluginKonzept Plugin hinzugefügt. Dazu existiert bereits eine Liste von
verschiedenen SLX-Plugins.

Stage2¶

Im nächsten Schritt wird mit slxos-export ein Export (=bootfähiges Rootfilesystem für Clients) erzeugt.

Am Ende des zweiten Stadiums werden ausgehend von Stage1 und den Konfigurationsinformationen alle Export-Daten generiert (slxconfig-demuxer):

• Kopieren des Stage1-Images auf den Export Server (Rsync für NFS, Anlegen des SquashFS-Containers, ...). Dabei müssen irrelevante Daten aus Stage1 möglichst unterdrückt werden.
• Füllen des Konfigurationsverzeichnisses aus /opt/openslx/share/distro-specs/files und weiteren Quellen (Templates, Dateien des Admins in /var/opt/openslx/config/<system-name>/{default,<client-name>}, ...)
• Festlegen eines Kernels und Erzeugen einer oder mehrerer passender Initialramfs (slxconfig-demuxer)
• Erstellen von passenden Boot-Menüs für die Clients (~/tftpboot/pxelinux.cfg, Generierung mind. eines Eintrages oder Default-Boots)
• Bereitstellen des TGZ-Containers (generiert aus /var/opt/openslx/config/<system-name>/{default,<client-name>}) nach /srv/dxs/tftpboot/client-conf/<system-name>/default.tgz bzw. ~/01-00-00...tgz

Zudem sollte auch ein Setup der notwendigen Export-Dienste (NFS-, (D)NBD-Server, iSCSI, ...) erfolgen.