Verwendete Begriffe¶
Das OpenSLX-Projekt verwendet einige Begriffe (eine ausführliche Begriffsreferenz findet sich im Glossar der Dokumentation):
StageN¶
Es sind verschiedene Stadien in einer OpenSLX-Umgebung definiert, die jeweils spezifische Aufgaben haben. Bisher sind vier bzw. fünf Stadien definiert: Das erste Stadium ist Stage1 und beinhaltet die Installation in ein Unterverzeichnis, das "System" entspricht Stage2. Wenn nicht die klassische PXE/PXELinux-Boot-Umgebung verwendet wird, kann ein PreBoot vorgeschaltet werden. Der initialisierende Client wird als Stage3 (InitialRamFS) und das Native-Init als Stage4 bezeichnet.
Stage1¶
Im ersten Stadium wird das System initial aufgesetzt:- Auspacken der Pakete: Dieses passiert in speziellen Chroot-Umgebungen. Dazu ist Stage1 in Substages (1A-1D) aufgeteilt, siehe dazu auch SlxInstallation. Am Ende wird jeweils ein gültiger/vollständiger Library-Cache erstellt (ldconfig).
- Einrichten der Komponenten (Fontcaches, Anpassungen, ...), wenn nicht schon im ersten Schritt erreicht.
- Admin-spezifische Zusätze (eigene TGZ nachrüsten, ...). Hierfür wird es in Zukunft die Möglichkeit geben eigene Module zu ergänzen.
Das System ist in sich vollständig, wird aber in diesem Zustand nicht exportiert. Direkte Tests sind nur per NFS-Export möglich. An dieser Stelle ist ein beschreibbares Mounten erlaubt, um weitere Komponenten zu installieren oder das System anderweitig zu erweitern. Eine Option ist hier der VM-Player. Stage1 ist der Ausgangspunkt für ALLE Zieldevices und Varianten (Stage2).
PreBoot¶
Umfasst einen generischen Kernel und ein spezielles InitRamFS. PreBoot kann dabei dem Nutzer analog zu PXELinux eine Auswahl verschiedener Systeme anbieten und ihn nach Konfigurationseinstellungen für den gerade startenden Client fragen.
Distribution (oder auch 'Distro')¶
Eine Distribution ist eine Zusammenstellung von Softwarepaketen (auf CD/DVD oder auch auf einem FTP-Server), welche dazu dient, ein Betriebssystem mit zusätzlicher Software installieren zu können. Bei den meisten Distributionen hat der Hersteller bereits eine Reihe von unterschiedlichen Softwarekonfigurationen namentlich benannt, aus denen man bei der Installation wählen kann (z.B. 'Minimalsystem', 'GNOME-Desktop', 'KDE-Desktop').
Ziel von OpenSLX ist es, jede dieser vom Hersteller der Distribution vorgesehenen Konfigurationen zur Installation als Vendor-OS (siehe unten) anzubieten.
Vendor-OS¶
tragen diesen Namen, weil sie von einem Vendor (dem Hersteller der Linux-Distribution) stammen. Ein Vendor-OS bezeichnet eine Installation einer bestimmten, mit einer Distro kommenden Softwarekonfiguration in einem Verzeichnis und entspricht daher der "Stage1" im OpenSLX-Betriebskonzept.
Es gibt grundsätzlich zwei Möglichkeiten, ein Vendor-OS auf einem SLX-Server zu installieren: Einerseits direkte Installation aus den Paketquellen (also über das Internet oder von lokal vorhandener DVD) oder als Klon eines bestehenden (installierten) Referenzsystems.
Das Tool slxos-setup zeigt die bislang unterstützten Varianten an:
x60s:~ # slxos-setup list-supported
List of supported distros:
debian-3.1 (clone,install)
debian-4.0 (clone,install)
debian-4.0_amd64 (clone,install)
fedora-6 (clone,install)
fedora-6_x86_64 (clone,install)
gentoo-2006.X (clone)
gentoo-2007.X (clone)
mandriva-2007.0 (clone)
suse-10.0 (clone)
suse-10.0_x86_64 (clone)
suse-10.1 (clone,install)
suse-10.1_x86_64 (clone,install)
suse-10.2 (clone,install)
suse-10.2_x86_64 (clone,install)
suse-10.3 (clone)
suse-10.3_x86_64 (clone)
suse-9.3 (clone)
ubuntu-6.06 (clone)
ubuntu-6.10 (clone,install)
ubuntu-6.10_amd64 (clone,install)
ubuntu-7.04 (clone,install)
ubuntu-7.04_amd64 (clone,install)
Export¶
Als Export (Kurzform für 'exportiertes Vendor-OS') bezeichnet man die konkrete - über das Netz zugreifbare - Form des späteren Rootfilesystems. Zur Zeit können NFS- und NBD/!SquashFS Rootfilesysteme angeboten werden. Das Erzeugen eines Exports übernimmt slxos-export (Parameter u.a. nfs, nbd-squash). Es sollte nach jedem Vendor-OS-Update aufgerufen werden, um die mit dem Update durchgeführten Änderungen am Dateisystem des Vendor-OS an die Clients durchzureichen.
System¶
Ein System ist bei OpenSLX ein bootfähiges Objekt, das den Clients ihr (Readonly-)Rootfilesystem zur Verfügung stellt und die zentral eingestellte Konfiguration vornimmt. Es ist das Ergebnis des slxconfig-demuxers. Zuvor muss ein Vendor-OS installiert (slxos-setup) und anschließend exportiert (slxos-export) werden.
Jedes System beinhaltet eine für sich bootbare Einheit (ein lauffähiges Betriebssystem), die aus dem RO-Rootfs, einem bestimmten Kernel, einem zu diesem Kernel passenden Initialramfs und der PXE-Bootkonfiguration (ein oder mehrere Menüeinträge) besteht. Ein System entspricht also einem vollständigen "Stage2" des OpenSLX-Betriebskonzeptes.
Die Konfiguration eines Systems über die Datenbank hinaus kann ein Admin in:
/var/opt/openslx/config
/var/opt/openslx/config/<system>
/var/opt/openslx/config/<system>/default/{initramfs,rootfs}
/var/opt/openslx/config/<system>/<client-name>/{initramfs,rootfs}
vornehmen. Nach dem Aufruf des slxconfig-demuxers wird die Konfiguration nach:
(/srv/openslx)/tftpboot/client-config/<system>/default.tgz (/srv/openslx)/tftpboot/client-config/<system>/01-<Client-MAC>.tgz
geschrieben.
Client¶
Ein Client bei OpenSLX ist eine konkrete (PC-)Hardware mit (mindestens einem) zugeordneten System(en). Ein in Betrieb befindlicher Client entspricht "Stage3" (InitRamFS) und "Stage4" des OpenSLX-Betriebskonzeptes.
Server(komponenten)¶
Zum Betrieb von Clients in einer OpenSLX-Umgebung werden einige Dienste benötigt. Dazu gehört üblicherweise ein DHCP-Service, TFTP (für PXElinux, Kernel, Initialramfs, Konfiguration(en)). Für das Rootfilesystem der Clients kommen diverse System-Export-Dienste in Frage (NFS, (D)NBD, iSCSI, AoE, ...), die auf irgendeinem Server zur Verfügung stehen müssen.
Prepare Server¶
Auf dem Prepare Server erfolgt die Vorbereitung eines Systems (Stage1). Hier liegt die OpenSLX Filesystemstruktur, die die Grundlage für den Export, TFTP, DHCP Server bildet. Sie kann mit slxsettings angepasst werden.
... /opt/openslx /opt/openslx/share/distro-specs /opt/openslx/share/templates ... /var/opt/openslx /var/opt/openslx/config /var/opt/openslx/db /var/opt/openslx/stage1
Export Server¶
Der Export Server stellt mindestens Rootfilesysteme (Systeme, Stage2) für die Clients bereit. Er kann dazu auch die Aufgaben des DHCP und TFTP Servers übernehmen.
InitialRamFS¶
Ein InitialRamFS existiert als Konzept seit dem 2.6er Kernel. Es verwendet TempFS und CPIO und ist damit in der Benutzung deutlich einfacher als die traditionelle Initial Ramdisk. Vielfach wird deshalb das moderne Initialramfs auch als InitRD bezeichnet, was aber nicht ganz korrekt ist, da sich konzeptionell einiges geändert hat. Hierzu zählt beispielsweise die Ablösung des pivot_root durch run-init. Ein Initialramfs bei OpenSLX gehört immmer zu einem Kernel eines Systems dazu. Es beinhaltet die Kernelmodule für Netzwerk und RootFS-Setup und die OpenSLX-Skripten.
OpenSLX-Init ("Stage3") ist das Vorbereitungsskript, welches von Anfang bis Ende im Initialramfs läuft und alle Vorbereitungsvorgaenge für Rootfs, Software-, Hardware-Setup steuert. Das Native-Init ("Stage4") ist das klassische (Linux-)Init, welches im später betriebenen System gestartet wird und welches die Runlevel verwaltet.
Thin Client¶
Ein Thin Client meint hier eine gegenüber der traditionellen PC-Hardware abgespeckte Variante, die oft viel kleiner ist, einige Devices (Festplatte, CD/DVD, ...) nicht enthält, weniger CPU und RAM hat. OpenSLX Clients sind eher nicht unter dem Aspekt der Hardware "abgespeckt", sondern hier bezieht sich "Thin" in erster Linie auf den deutlich reduzierten Administrationsaufwand. Ein Grund der Reduktion kann die fehlende Festplatte sein (oder eine auf nicht zentrale Funktionen beschränkte Festplatte).
Tool- und Programmnamen¶
Alle Programme des OpenSLX-Projekts fangen mit dem Prefix "slx*" an.
slxconfig-demuxer¶
slxconfig-demuxer liest Informationen über alle Systeme, Gruppen und Clients aus der Config-DB und generiert aus diesen Daten sämtliche SLX-Konfigurationsdateien (Systemdefaults und systemspezifische Client-Konfigurationen). Jede dieser Dateien wird unter dem Namen initramfs-setup zusammen mit den erweiterten Konfigurationsdateien (/var/opt/openslx/config/<system-name>) in ein TGZ-Archiv verpackt und nach /srv/openslx/tftboot/client-conf/<system-name>/01-<Client-MAC>.tgz verschoben.
Außerdem werden noch die generell von PXElinux benötigten Dateien (menu.c32 sowie pxelinux.0) an die entsprechende Stelle kopiert sowie alle PXE-Konfigurationsdateien (Bootmenüs) generiert.
slxos-setup¶
Je nach Linux-Distribution stehen ein oder zwei Wege des Stage1-Setups zur Verfügung: Entweder man installiert ein neues System aus den Paketquellen (bisher nur RPM) oder klont eine bereits fertig eingerichtete Maschine, die
unter der Wahldistribution läuft. Beides übernimmt das Kommando slxos-setup, siehe dazu auch SlxInstallation. (Nicht alle gelisteten Systeme werden vom SLX-Stage3 unterstützt.)
slxos-export¶
slxos-export realisiert den Übergang von Stage1-Installationen in Stage2-Exports.
slxconfig¶
Das Werkzeug slxconfig stellt die Benutzerschnittstelle zur Datenbank dar. Damit
können Sie sich alle Einstellungen anzeigen lassen und Änderungen vornehmen. So
bereitgestellten SLX-Systeme an. h3. slxsettings Passen einem die Festlegung der verschiedenen Verzeichnisse nicht, so kann man diese mit dem Skript *slxsettings* anpassen. So läßt sich beispielsweise dafür sorgen, dass die Stage1-Daten nicht im Server-Rootfilesystem sondern beispielsweise auf einer separat gemounteten <pre>