Kapitel 6
Konfiguration der OpenSLX Clients

1. Basis-IP-Konfiguration beim Booten per PXE oder Etherboot/gPXE
2. Auslesen der Konfigurationsdaten, die in einem sehr frühen Stadium benötigt werden, aus der Kernel Commandline und der ins InitRamFS eingepackten initramfs-setup, wobei Einträge in letzterem von ersterem überschrieben werden.
3. Erweiterte Konfiguration innerhalb von Stage3 durch Laden der Client-Daten auf verschiedenen Wegen (TFTP, HTTP, TFTP), je nach eingestellter Konfigurationsart.
4. Anwenden der geladenen Konfiguration innerhalb des InitRamFS und wärend des Stage4 Bootens - dabei stehen dem Administrator mehrere Möglichkeiten offen, eigene Erweiterungen vorzunehmen.

Alle wesentlichen Konfigurationsschritte finden wärend des Ablaufs des InitialRamFS (Stage3 des OpenSLX) statt.

Die zentralen Konfigurationsdateien sind initramfs-setup und machine-setup. Für das einfachere Debugging kann man sich ihren Inhalt zudem noch in Stage4 in /etc/machine-setup des laufenden SLX-Clients ansehen. Sie hat in Stage4 jedoch keine Bedeutung mehr.

Beide Dateien werden durch den slxconfig-demuxer erzeugt und im InitRamFS (initramfs-setup) oder ins ConfTGZ (machine-setup) eingebaut. Die finale /etc/machine-setup wird wärend des Stage3 weiter gefüllt und ausgewertet.

6.1 Konfiguration per Kernel Commandline

Die Kernel Commandline besteht aus statischen und dynamischen Einträgen. Viele Einträge können beispielsweise per PXElinux¹ oder Etherboot² übergeben werden.

Mittels Kernel Commandline kann so bei Bedarf eine Anzahl initialer Konfigurationsparameter an OpenSLX Clients übermittelt werden. Generell existiert eine Beschränkung, welche in der Begrenzung der Kernel Commandline bei Intel-Plattformen auf 256 Zeichen liegt. Deshalb sollte man bei auftretenden Problemen zuerst auf dem Client überprüfen, ob die Commandline mit allen Optionen vollständig vorliegt. Alternativ könnten bestimmte, gemeinsame Variablen in die initramfs-setup verschoben werden, die initial vom slxconfig-demuxer mit dem InitRamFS zusammengepackt wird. Ausführlichere Informationen bietet Abschnitt 6.2.

Die Zuweisung von Variablen und Werten unterscheidet sich zwischen Kernel Commandline und Konfigurationsdatei nicht. Einziger Unterschied: Wärend einige Variablen ohne Zuweisung in der Kernel Commandline definiert werden können, wie beispielsweise ”debug”, geht dieses in der initramfs-setup oder machine-setup nicht. Hier müssen diese leer deklariert werden: ”debug=”.

• aufs=* - schaltet die Verwendung von AUFS³ auf dem Client ein. Ohne Zuweisung wird ein einfaches Layering verwendet: Auf der unteren Ebene das nur lesbare Rootfilesystem über welches komplett ein schreibbares TempFS gelegt wird. Wird eine oder eine Liste von Filesystem-URIs angegeben, wird aus mehreren Komponenten das Rootfilesystem zusammengesetzt. Das Haupt-Rootfilesystem bildet die Basis, das TempFS weiterhin den Top-Layer. Alle anderen Schichten werden dazwischen gestapelt.
• country=* - setzt die Lokalisierung (in der Shell)
• debug=* - setzt den Debuglevel auf den angegeben Integerwert. Für eine Auflistung aller Debuglevel siehe Anhang D.2. Ohne Zuweisung, d.h. ohne Angabe eines Levels, setzt der Client den Debuglevel auf 1.
• nodhcp - verzichte auf DHCP zur Konfiguration; Standard IP und DNS Daten, sowie userspezifische Variablen werden auf alternativem Wege beschafft. Ohne dieses Token erfolgt eine zweite DHCP-Anfrage aus dem Stage3 heraus. Mit ”nodhcp” stehen nur die von PXE oder Etherboot bezogenen IP-Daten zur Verfügung, wenn diese nicht aus der weiteren Konfiguration ergänzt werden.
• ldap=* - verwende LDAP zur Konfiguration (URI Syntax). Die LDAP-Konfiguration ist bisher nicht implementiert.
• file=* - gibt die Quelle zum Beschaffen von Konfigurationsdatei(en) an und definiert dabei Protokoll, Server und Pfad (URI Syntax). Als Protokolle sind TFTP (Standard) aber auch FTP oder HTTP erlaubt. Ohne Zuweisung versucht der Client eine Datei nach dem Muster seiner MAC-Adresse⁴ oder default zu ziehen. In diesem Fall wird als Server-IP die Adresse des DHCP-Servers verwendet. Unterscheidet sich diese, dann kann man alternativ diese auch ohne Pfad angeben: ”file=tftp://1.2.3.4”
• ldsc - sorgt für die Generierung einer aktuellen ld.so.cache. Defaultmäßig wird die vorhandene⁵ aus Stage2 übernommenen. Wenn ein Multilayering durch ”aufs” oder ”unionfs” definiert wurde, ist diese Option eingeschaltet und ein aktuelles ld.so.cache wird im Stage3 generiert.
• unionfs=* - schaltet die Verwendung von UnionFS für das Rootfilesystem ein; es funktioniert analog zu aufs. Multilayer sind durch kommaseparierte Filesystem-URIs erreichbar.
• rootfs=* - Art des zu verwendenden Rootfilesystems des Clients, infrage kommen derzeit NFS, (D)NBD oder ein lokales Blockdevice (lbdev), spätere Erweiterungen sollten AoE, iSCSI erlauben ... Es wird das URI-Format erwartet, beispielsweise ”rootfs=nfs://server/pfad”, ”rootfs=lbdev://sda3/squashfs” oder ”rootfs=nbd://server:port/Filesystem”. Wird das Rootfilesystem aus mehreren Komponenten zusammengesetzt, sollte ”noldsc” nicht gesetzt sein. Statt einer fest eingetragenen Server-IP kann die Variable ”@@@serverip@@@” verwendet werden. Sie wird im Stage3 mit dem via DHCP empfangenen Wert für den DHCP-Server ersetzt.
• nfsroot=* - alte Methode zur Übergabe der NFS-Quelle für das Rootfilesystem der Form ”nfsroot=server:/pfad”. Sie wird nur noch eine gewisse Zeit lang unterstützt. Die Variante ”rootfs” sollte deshalb vorgezogen werden.
• dcsize=* - nur sinnvoll bei definiertem ”rootfs=dnbd://...”, definiert die Größe des Cachefiles für DNBD. Da das Cachefile derzeit im RAM des Clients angelegt wird, sollte es passend zur RAM-Ausstattung gewählt werden.
• ip=* - wird durch PXE-Linux bzw. Etherboot/gPXE bestückt.
• tmpfssize=* - Grösse des max. temporären Speicherplatzes im RAM (tmpfs)
• vci=* - Vendor Code Identifier, nur sinnvoll, wenn DHCP benutzt wird in Netzen, wo die Unterscheidung anfragender Clients notwendig ist.

6.2 Zentrale Konfigurationsdatei machine-setup

Die zentrale Konfigurationsdateien eines OpenSLX Clients sind initramfs-setup und machine-setup, welche im Stage4 in /etc/machine-setup zusammengeführt zu sehen sind. Erstere wird durch den slxconfig-demuxer aus der SLX-Konfigurationsdatenbank erzeugt und ins InitRamFS eingebaut.⁶ direkt in das erzeugte InitRamFS eingefügt wird. Alle Zuweisungen, die in dieser Datei vorgenommen und im Bootverlauf nicht überschrieben werden, wirken auf alle Client, die ein bestimmtes gemeinsames InitRamFS verwenden.

Die Datei wird mehrfach im Laufe der Stage3-Setup-Prozedur aufgerufen. Durch den Aufruf zu Beginn des SLX init können Zuweisungen bestimmter für viele Clients gemeinsamer Parameter aus der Kernel Commandline auch in die machine-setup verschoben werden.

Die im Anschluss beschriebenen Konfigurationsmethoden hängen an diese Datei ihre Ergebnisse an: So dass beispielsweise die DHCP-Konfiguration die evtl. vorbelegten Variablen für Hostname, DNS-Server, ... überschreiben können. Später kann der Client via ConfTGZ neben weiteren Konfigurations- und anderen Dateien ein neues machine-setup erhalten, welches hinten an das initial vorhandene angefügt wird.

Variablen sind dann unter Umständen mehrfach definiert. Es gilt jedoch immer nur die letzte, so dass die Datei von hinten her zu lesen ist, wenn man eine bestimmte Zuweisung sucht.

Statt einer fest eingetragenen Server-IP für die verschiedenen Quellen oder Services kann die Variable ”@@@serverip@@@” in machine-setup verwendet werden. Sie wird im Stage3 mit dem via DHCP empfangenen Wert für die Adresse des DHCP-Servers ersetzt. Damit kann man sich statische Einträge sparen, wenn sowieso für wichtige bzw. alle SLX-Services die identische IP gilt.

Obwohl in den meisten Umgebungen OpenSLX Clients sehr einheitlich gehalten werden, kann es doch von Interesse oder notwendig sein, für einzelne Clients separate Festlegungen zu treffen. Das wird insbesondere in größeren Netzwerken mit Gruppen von Clients immer wichtiger. Alle der im Folgenden genannten Konfigurationsarten greifen in Stage3 des Client-Starts.

Derzeit sind drei (vier) Konfigurationswege vorgesehen, wenn auch noch nicht alle implementiert:

• via TFTP (configuration plus extensions - ConfTGZ) file get - ist wesentlicher Bestandteil der aktuellen Version 4. Ergänzungen zur machine-setup, wie User-Authentifizierung, Home-Verzeichnisse und admin-spezifische Skripten (zusammengefasst als TGZ) versucht der Client (MAC sei 00:11:43:7c:da:ff) nacheinander in der Form 01-00-11-43-7c-da-ff.tgz und default.tgz zu beschaffen. Die Dateien werden am Anfang der Services-Konfiguration eingespielt (servconfig), können also u.U. noch von dieser modifiziert werden. Dazu muss in der Kernel Commandline das Token ”file” aktiviert sein. Dateien können explizit angegeben werden: ”file=tftp-server/srv/dxs/client-config/ <system-name>/01-00-11-43-7c-da-ff.tgz” oder sollten nach einem speziellen Schema präsent sein. Man kann natürlich auch die Basis-IP und DNS-Daten auf diesem Wege transportieren. Wobei in einem normalen Setup diese Daten sicherlich weiterhin per DHCP kommen. Man kann sich aber auch Fälle vorstellen, wo nur die IP-Daten per Kernel Commandline benutzt werden und die restliche Konfiguration unter Umgehung eines weiteren DHCP-Schrittes erfolgt (weil bspw. der DHCP-Server im Netz eigentlich für andere Systeme konfiguriert wurde und nicht die richtigen Daten bereit hält). Siehe hierzu auch B und 6.3.
• via FTP/HTTP - ist als Erweiterung der TFTP (file get) Methode vorgesehen und damit lediglich eine Abwandlung des vorher genannten Punktes. Hierzu wird ein wget benötigt, welches beispielsweise schon Bestandteil der Busybox ist.
• via DHCP - die klassische Methode, wie seit DXS Version 2 im Einsatz ist. Neben den vordefinierten DHCP-Variablen zu IP- und DNS-Basiskonfiguration, können NTP-, NIS-Server und -Domain können auch selbstdefinierte Variable verwendet werden (dieses funktioniert jedoch nur mit dem Kommando dhclient), die dann im Header der dhcpd.conf auf dem Server und der dhclient.conf auf dem Client (letztere via functions im InitialRamFS) deklariert werden müssen. Langfristig wird diese Konfigurationsoption entfallen.
• via LDAP - ist noch nicht implementiert, aber für die aktuelle Version geplant. Hierarchische Datenbanken eignen sich gut für die Ablage von Konfigurationsdaten: Beispiel Microsoft ADS. Die LDAP-Quelle wird in URI-Syntax durch ”ldap=...” in der Kernel Commandline angegeben. Einige Ausführungen hierzu finden sich im Teil zur Steuerung größerer Setups.

6.3 Paket von Konfigurationsdateien und Erweiterungen

Nicht alle Konfigurationen eines Clients lassen sich durch mehr oder weniger einfaches Skript-Setup abdecken, wie es durch servconfig innerhalb des Initialramfs erledigt wird. Für diese Fälle besteht die Möglichkeit Konfigurations- und weitere Dateien vorzupaketieren, die dann wärend des Stage3 auf das spätere Rootfilesystem des Clients für Stage4 ausgepackt werden.

Die Vorbereitung dieser Dateien erfolgt unterhalb von /var/opt/openslx/config:

Hier wird für jedes installierte System (Stage1) ein Unterverzeichnis angelegt. Auf dieser Ebene und unterhalb jedes Systemverzeichnisses gibt es ein Unterverzeichnis default oder Unterverzeichnisse, die mit 01-MAC der jeweiligen Clients kodiert sind. Unterhalb dieser Verzeichnisse gibt es:

• initramfs - in diesem Verzeichnis landen alle Dateien, die wärend des Initramfs (Stage3) ausgeführt werden. Hierzu zählen preinit.local welches ins Initialramfs via slxmkramfs bzw. mkdxsinitrd aufgenommen wird. Hier kann man auch eine machine-setup ablegen, die dann die Default-Datei gleichen Namens im Initramfs erweitert.⁷
• rootfs - dieses Unterverzeichnis nimmt alle Daten auf, die auf das spätere Rootfilesystem der Clients kopiert werden sollen. Dieser Kopiervorgang wird durch servconfig am Anfang dieses Skriptes ausgeführt. Hierbei muss man jedoch beachten, dass nur Dateien für schreibbare Bereiche⁸ des späteren Rootfilesystems kopiert werden können.

Wärend einfache Konfigurationen wie beispielsweise das traditionelle NIS⁹ für die Benutzerauthentifizierung und NFSv3/Automount für die Homeverzeichnisse¹⁰ einfach per Eintrag in der machine-setup oder per Konfigurationsvariable aktiviert werden können, fällt diese Option für komplexere Setups weg.

So sind die Benutzerauthentifizierung per LDAP und das gesicherte Einbinden von Homeverzeichnissen typische Kandidaten für die Paketierung. Hierzu kopiert man alle benötigten Dateien und Verzeichnisse in ihrer späteren Lage in das jeweilige Unterverzeichnis rootfs:

6.3.1 Eigene Konfigurationserweiterungen

Ein Administrator hat eine Reihe verschiedener Möglichkeiten Erweiterungen neben den vordefinierten Einstellungen vorzunehmen. Dabei ist es jedoch eine schlechte Idee diese Erweiterungen direkt am Stage1 vorzunehmen. Sie könnten bei Updates oder Neuinstallationen unbemerkt verloren gehen. Deshalb sollten Ergänzungen, die nicht direkt durch Programme oder Skripten des jeweiligen Systems abgebildet werden, ausserhalb abgelegt werden. Das gilt ebenso für sämtliche Konfigurationen, die nicht durch die Stage1-Installation automatisch korrekt generiert werden. Änderungen, die man am Stage1 vornehmen möchte, werden in einem eigenen Abschnitt behandelt.

Erweiterungen können in verschiedenen Stadien (Stage3 oder Stage4) des Client-Bootprozesses greifen:

1. Die früheste Möglichkeit den Bootprozess zu beeinflussen besteht mit preinit.local. Dieses Shellskript wird zu Beginn des SLX init innerhalb des Initialramfs ausgeführt. Hier stehen nur die Kommandos des InitialRamFS zur Verfügung, das spätere Rootfilesystem der Clients ist zu diesem Zeitpunkt noch nicht gemountet. Es können jedoch durch das Laden von /etc/functions bzw. /etc/distro-functions alle definierten Hilfsfunktionen genutzt werden. Die Datei sollte unterhalb von /var/opt/openslx/config/<system-name>/default/initramfs (oder entsprechend) bei Bedarf angelegt werden.
2. Mit postinit.local besteht am Ende des SLX init Laufes innerhalb des Initialramfs die nächste Möglichkeit des Eingriffs. Zu diesem Zeitpunkt bestehen zwar weiterhin die Einschränkungen bezüglich der verfügbaren Kommandos. Das Rootfilesystem ist aber komplett eingerichtet und kann unterhalb von /mnt erreicht werden. Wie bei preinit.local können Hilfsfunktionen benutzt werden, für das Anlegen gilt dies ebenso.
3. Werden weitere Programme oder Skripten im Initialramfs benötigt, kann man diese ebenfalls via ConfTGZ¹¹ hinzuladen.
4. Da nicht alle Konfigurationen sinnvoll innerhalb des InitialRamFS erledigt werden können,¹² kann man weitere Prozesse mittels boot.local wärend Stage4 anstoßen.

Erweiterungen im InitialRamFS sind nur über die beiden lokalen *init-Skripten möglich.

6.3.2 Das InitRamFS Skript preinit.local

Dieses Skript kann dazu genutzt werden, eigene Erweiterungen oder Einstellung zu einem sehr frühen Boot-Zeitpunkt vorzunehmen. Zu diesem Zeitpunkt steht jedoch nur das Toolset des InitRamFS zur Verfügung und es sind lediglich /proc und /dev (mit Minimalausstattung) gemountet.

Für alle Vorgänge, die das gemountete spätere Rootfilesystem des Clients voraussetzen, Module laden, Mountvorgänge anstoßen sollen, verwendet man postinit.local.

6.3.3 Das InitRamFS Skript postinit.local

Das Skript postinit.local findet ein weitgehend konfiguriertes System vor. Die automatisch erkannte Hardware und alle definierten Services wurden eingerichtet. Das Stage4-Rootfilesystem ist unterhalb von mnt erreichbar und kann bei Bedarf weiter modifiziert werden. Die Auswahl der zur Verfügung stehenden Kommandos ist weiterhin beschränkt, jedoch lässt sich durch das Einbinden einiger Dateien das Set der für Stage3 definierten SLX-Funktionen einbinden:

Die Verwendung von UnionFS erlaubt es bequem für Clients das Rootfilesystem zu erweitern. So kann man ausgehend von einem Basissystem bestimmte Software und Komponenten aus einer anderen Quelle hinzufügen. Das ergibt im wesentlichen zwei Szenarien:

1. Ergänzung eines bestehenden Systems: Es werden zusätzliche Bibliotheken und Programme hinzugefügt. Dann sollte auf jeden Fall dafür gesorgt werden, dass der Library-Cache auf entsprechendem Stand ist.
2. Austausch von bereits vorhandenen Komponenten: Es wäre möglich bereits im Grundsystem vorliegende Programme und Bibliotheken durch andere Versionen zu ersetzen und per Whiteout¹³ zu entfernen.

6.4 Die Clientseite in der Konfigurationsdatenbank

Ein OpenSLX-Client kann in der Konfigurationsdatenbank mit individuellen Einstellungen versorgt werden. Das betrifft alle Daten zum Betrieb des Clients, die nicht schon mittels DHCP direkt oder mittelbar per DNS zur Verfügung gestellt werden. Hierzu zählen beispielsweise die verschiedenen privaten Schlüssel oder Samba-Secrets.

Die ”Verknüpfung” mit bestehenden DNS bzw. DHCP-Servern erfolgt über die MAC-Adresse des Clients. Aus Sicht der Administration der OpenSLX-Seite kann dem Rechner eine Kurzbeschreibung bzw. ein Name verpasst werden. Dieser Name sollte nicht unbedingt der FQDN des Clients sein. Dann gibt es keine Probleme einen Rechner ohne Änderung von wichtigen Konfigurationsparametern zwischen verschiedenen IP-Netzen¹⁴ zu bewegen.

Einen Überblick zu allen jeweils verfügbaren Optionen erhält man, indem man sich die Einstellungen des SLX-Default-Systems, welches immer vorhanden ist, ansieht:

Dabei haben die Optionen die nachfolgend erläuterte Bedeutung und möglichen Werte.

6.4.1 Einstellungen für Stage4

attr_ramfs_fsmods hält die Liste der zu ladenden Blockdevice- und Filesystem-Kernelmodule vor. Im Stage3 müssen vor dem Mounten des Rootfilesystems die entsprechenden Module verfügbar sein. Für ein SquashFS auf Basis eines Network Block Device (NBD) also die Module ”squashfs.ko” und ”nbd.ko”.

attr_ramfs_nicmods bestimmt die zu unterstützenden Netzwerkkarten. Da in den meisten Kernels keine Unterstützung für die verschiedenen Ethernet-Adapter fest einkompiliert ist, müssen diese als Modul rechtzeitig bereitgestellt werden, damit alle Netzwerkoperationen stattfinden können. Die Default-Liste umfasst die Module ”forcedeth.ko”, ”e1000.ko”, ”e100.ko”, ”tg3.ko”, ”r8169.ko” und ”pcnet32.ko”. Die Netzwerkfähigkeit durch PXE oder Etherboot zum Übertragen von Kernel und InitRamFS überträgt sich nicht auf den laufenden Kernel.

attr_ramfs_screen wählt das zu verwendende Splash-Theme aus. ”default” ist das OpenSLX-Theme.

6.4.2 Einstellungen für Stage4

Die nachstehenden Werte erlauben eine Einrichtung des Stage4-Zustandes von Systemen allgemein oder Clients im speziellen.

attr_automnt_dir legt fest, an welches Verzeichnis im Stage4 des Clients die User-Homes gehängt werden. Üblicherweise wird der Wert mit ”/home” belegt sein. Jedes andere erreichbare und existierende Verzeichnis ist ebenso zulässig.

attr_automnt_src bestimmt die Quelle, von der die Homeverzeichnisse importiert werden, typischerweise ”nfs://Server-IP/Pfad”. Andere Quellen sollen in Zukunft möglich werden ...

attr_country

attr_dm_allow_shutdown

attr_hw_graphic

attr_hw_monitor

attr_hw_mouse

attr_late_dm kann unter bestimmten Umständen abgeschaltet werden und damit den Start der grafischen Oberfläche etwas beschleunigen.

attr_netbios_workgroup slx-network

attr_nis_domain setzt die sogenannte NIS-Domain, ein String für die Benutzerverwaltung auf Basis des veralteten und recht unsicheren Network Information Service (NIS). Diese Variable kann alternativ auch per DHCP verteilt werden. Dann sollte der Wert in der Datenbank leer bleiben.

attr_nis_servers enthält die Liste der NIS-Server, die auch aus einer einzigen IP bestehen kann. Diese Variable kann, wie auch ”attr_nis_domain”, per DHCP verteilt werden. Dann sollte der Wert in der Datenbank nicht gesetzt sein.

attr_sane_scanner

attr_scratch erlaubt das Einbinden von temporärem Speicher von einem zentralen Server. Stateless Clients haben oft keine eingebaute Festplatte oder keinen Zugriff darauf, so dass es in /tmp für einige Anwendungen, wie k3b oder VMware ¹⁵ eng werden könnte. ”attr_scratch” erlaubt die Angabe eines URIs, welcher dann auf /tmp eingehangen wird. Eine Alternative ist die Definition einer leeren Partition mit der ID44. Sie wird im Stage3 als SLX-Partition erkannt, bei jedem Start frisch formatiert und als Temp eingehangen. Diese Option ist für hohe Last im Temp vorzuziehen.

attr_slxgrp definiert eine Gruppe von Clients unabhängig vom SLX-System. Diese Gruppen-ID kann beispielsweise dazu benutzt werden, festzulegen, was für eine Auswahl virtueller Maschinen ein Benutzer an seinem Client beim grafischen Login zu sehen bekommt.

attr_start_alsasound Einige Distributionen benutzen ein Runlevel-Skript um Voreinstellungen der Audioausgabe einzustellen. Üblicherweise ist der Sound auf einem SLX-Client stummgeschaltet.

attr_start_atd

attr_start_cron

attr_start_dreshal legt fest, ob die Dienste für D-Bus, Resource-Manager (einige Distros, wie SuSE) und Hardware Abstraction Layer (HAL) gestartet werden. Das macht für Desktop-Systeme auf jeden Fall sind, kann aber in Rechnen-Cluster unnötig sein.

attr_start_nfsv4 Das NFS in der neuesten Version 4 verfügt über eine Reihe neuer Eigenschaften. Für seine gegenüber Version 3 signifikant verbesserten Sicherheitsfunktionen greift es üblicherweise auf Kerberos und weitere Dienste zurück, die ebenfalls gestartet werden sollten.

attr_start_ntp Anders als die meisten Start-Service-Einstellungen kann hier neben ”yes” und ”no” alternativ ”initial” eingetragen werden. Dann wird im boot.slx im Stage4 des Clients ein ntpdate -bs Server-IP ausgeführt.

attr_start_printer

attr_start_samba Werte ”yes”, ”no” und ”may”. Letzteres hat die Aufgabe den Dienst zwar für eine spätere Nutzung zu konfigurieren, ihn aber nicht zu starten.

attr_start_snmp Werte ”yes” und ”no”

attr_start_sshd Werte ”yes” und ”no”

attr_start_syslog Werte ”yes” und ”no”

attr_start_x Neben den Werte ”yes” und ”no” sind weitere Einstellungen möglich, siehe dazu Abschnitt 6.5. So lassen sich ”direct”, ”indirect” und ”broadcast” festlegen, sowie der Name von Startskripten beliebiger grafischer Oberflächen eintragen. Letzteres ist für Kiosk-Modi interessant.

attr_start_xdmcp kennt die Werte ”kdm”, ”gdm”,”xdm” und ”no” und arbeitet eng mit ”attr_start_x” zusammen (siehe dazu auch Abschnitt 6.5).

attr_tex_enable

attr_timezone Europe/Berlin

attr_tvout Für spezielle Grafikkarten Default ist no.

attr_vmware kann die Einstellung ”yes” und ”no” und ein URI für eine Quelle mit Images virtueller Maschinen aufnehmen.

clients enthält die Liste aller Clients für die das System angeboten werden soll. Ist diese Liste leer, gibt es jedoch immer ein PXE-Default-Menü zum booten.

comment internal system that holds default values

export_id

hidden

id ist ein datenbankinternes Feld.

kernel

kernel_params ”vga=0x317 splash=silent”

label bestimmt das Aussehen des Eintrags im PXE-Bootmenü. Wenn dort nicht einfach nur der automatisch generierte Systemname enthalten sein soll, empfielt es sich eine ”sprechende” Bezeichnung zu wählen, die von den Nutzern verstanden wird, beispielsweise ”Standard-Linux-System mit ...”.

name <<<default>>>

6.5 Betriebsmodus einstellen

OpenSXL Clients können in verschiedenen Betriebsarten betrieben werden. So stehen neben dem klassischen Workstation-Modus auch verschiedene Kiosk- oder X-Terminal-Varianten zur Verfügung. So läßt sich jede Betriebsart einer Linux-Workstation auch im stateless Betrieb realisieren.

Für die verschiedenen Modi sind in erster Linie zwei Konfigurationsvariablen bestimmend, ”start_x” und ”start_xdmcp”, welche in der zentralen Konfigurationsdatei /etc/machine-setup bestimmt und im Stage3 ausgewertet werden.

6.5.1 Klassischer Workstation-Modus

In den meisten Fällen werden Clients im Workstation-Modus arbeiten, d.h. der Benutzer bekommt einen grafischen Login, wie xdm oder gdm gezeigt. Wenn komfortable grafische Display-Manager verwendet werden, besteht auch die Option die Art der Session auszuwählen. Diese Auswahl wird üblicherweise durch die jeweilige Distribution festgelegt, kann aber durch die Komponente der virtuellen Workstation¹⁶ erweitert werden.

6.5.2 X-Terminal

Clients können auch im X-Terminal-Mode betrieben werden. Dann ist nur eine minimale Software-Ausstattung erforderlich. Jedoch müssen die in der Variable ”start_xdmcp” angeforderten Display-Manager auch tatsächlich ausführbar, d.h. alle notwendigen Bibliotheken vorhanden,¹⁷ sein.

Im indirekten X-Server Modus liefert der Display-Manager einen Chooser. In diesem Chooser werden alle in der Variable ”x_display_manager”¹⁸ definierten Server angezeigt, so diese online sind und antworten. Für einen Mischbetrieb aus lokalem und Remote-X-Betrieb nimmt man in die Liste der IP-Adressen zusätzlich die 127.0.0.1 für die lokale Maschine mit auf.

Die DHCP-Variable ”x-display-manager” wird nur vom dhclient angefordert und anschliessend im Stage3 zur Verfügung gestellt. Der udhcpc kennt sie nicht.

6.5.3 Kiosk-Modi

OpenSLX Clients können direkt in eine bestimmte, festlegbare grafische Benutzerumgebung gestartet werden. In diesem Modus wird kein Displaymanager benötigt und konfiguriert.

In der Variable ”start_x” wird das Programm oder Skript hinterlegt, welches automatisch beim Hochfahren des grafischen Systems gestartet werden soll. Das kann kde oder gnome sein, aber auch beliebige andere Programme. Es ist notwendig die Variable ”start_xdmcp” auch tatsächlich auf no zu konfigurieren.

• VMware/Player - hier spielen sicherlich zwei Setups eine Rolle: Es wird in ein dediziert ausgewähltes VMware-Image gebootet oder alternativ eine Auswahl verschiedener Images zur Verfügung gestellt.
• Citrix-Client - in einem solchen Setup startet man direkt oder mit Auswahlmöglichkeit den entsprechenden Client.
• RDP-Client - hier gilt das für den Citrix-Client Gesagte.

Zum Teil werden in diesem Modus Programme oder Produkte verwendet, die nicht Bestandteil der gewählten Distribution sind. Diese müssen entsprechend in Stage1 installiert worden sein. Für den reinen Terminal-Betrieb aus Citrix- oder RDP-Client kann sich die Verwendung des LTSP¹⁹ als Alternativlösung anbieten.

6.5.4 Cluster-Node

Für den Cluster-Betrieb von Linux-Maschinen für Number-Crunshing oder ähnliche Anwendungen benötigt man üblicherweise keinerlei grafische Konsole. Deshalb schaltet man den X-Server aus und startet zudem keinen Displaymanager.

Cluster-Nodes verwenden üblicherweise eine sehr eingeschränkte Software-Auswahl. Auf Programme für grafische Oberflächen kann in den meisten Setups komplett verzichtet werden.

6.5.5 Terminal-Server

Ein recht spezieller Einsatzzweck können Terminal- bzw. X-Display-Server sein. Dieses sind Maschinen, auf die sich remote Clients verbinden, so dass der User auf dem Terminalserver statt lokal seine Sitzung ablaufen lässt. In diesem Fall werden ein Displaymanager aber kein lokales grafisches Display benötigt.

Auf diesen Maschinen sollte dann eine für den Anwendungszweck vollständige Installation des Exportsystems vorliegen.