Kickstart: Linux-Installation für faule Admins

Aber...

Richtig. An dieser Stelle ist ein großes ABER angebracht, denn was bringen die Home-Directories auf dem System, wenn sich bis jetzt noch keine User anmelden können. Für alle ungeduldigen hier ebenfalls noch eine %post-Anweisung, die einen User anlegt.

%post
useradd -M -p \$1\$2KM.PHpx\$.7WMhRLZwIyfQwLly/AgA1 userclient

Bei dieser Anweisung wird das bekannte Kommando für die Benutzerverwaltung verwendet. Da bei diesem Kommando das Passwort verschlüsselt mitgegeben werden muss, habe ich vorher das Passwort start verschlüsselt, mit Escape-Zeichen versehen, damit die Funktionen erhalten bleiben, und dem Kommando übergeben. Hiermit wird nun ein User namens userclient erstellt, der sich über das Passwort start einloggen kann. Die Option -M unterlässt das Erstellen eines Home-Directories (kommt ja vom NFS-Server) Achtung: der User sollte bereits auf dem Server existent sein!

Komfortabler

Schön wäre es doch, wenn auf jedem System der dazugehörige User angelegt wäre. D.h. auf System1 gibt es einen User 1, auf System2 einen User2, usw. Dies ließe sich in der Art gestalten, dass aufgrund von Hostname (PC01, PC02, PC03, ...) die Zahl ausgelesen und dem useradd-Kommando übergeben würde.

sysnr=`hostname`
sysnr=${sysnr:2};
useradd -M -p \$1\$2KM.PHpx\$.7WMhRLZwIyfQwLly/AgA1 $sysnr

Das Ganze in ein Skript eingepackt und ebenfalls als %post-Anweisung eingestellt. Somit bräuchte man keinen "Universal-User", der auf allen Systemen existiert.

X-Window

Grundlagen

Der nächste Schritt befasst sich mit einer grafischen Anmeldung und Authentifizierung am Server selbst. Normalerweise sind auf dem System neben dem eigentlichen X Window auch noch Display Management-Produkte wie KDE oder GNOME installiert, die vorbereitete Applikationen mitbringen, mit denen dann gearbeitet werden kann. Bei älteren Systemen mit weniger Speicher treten daher häufig Probleme und lange Wartezeiten auf, die mit der folgenden Lösung übergangen werden können.

Die ganze Lösung basiert auf der Tatsache, dass X Window eine Client/Server-Struktur besitzt, d.h. der Client-Teil unabhängig vom Server-Teil bestens funktioniert. In unserem Fall wird die eigentliche Arbeit vom Server geleistet (Rechenleistung, Speicherverwaltung, ...) und die grafische Ausgabe findet am Client statt.

Definitionen

Bei X Window müssen nun ein paar Definitionen gemacht werden, da manche Begriffe sehr missverständlich wirken.

X-Server: Der X-Server ist eine Software, die auf dem Client beheimatet ist. Er stellt über die Grafikkarte, Tastatur und/oder Maus die Ein-/Ausgabeeinheit von X Window dar. Sie kann sich auf folgenden Systemen befinden:

X-Terminal: Ein X-Terminal besitzt keinerlei eigene Platten und wird komplett über das Netz gesteuert. Alle auf ihm eingegebenen Daten werden auf einem Hardware-Server bearbeitet und zur grafischen Ausgabe an das X-Terminal gesendet.

X-Station: Die nächste Stufe besitzt ein eigenes lokales Betriebssystem und startet die X-Server-Anwendung, um sich am Applikationsserver anzumelden. Dies wird unsere Beispielkonfiguration.

X Workstation: Dies ist die normale Installation, mit beiden Komponenten (Client und Server) auf der lokalen Platte.

X-Client: Dies ist eine Anwendung, die auf einem Hardware-Server läuft und die Berechnung für den X-Server übernimmt. Bei einer X Workstation befindet sich diese Software auch auf dem lokalen System.

Applikationsserver: Dieser Server stellt den X-Client allen X-Servern zur Verfügung (bspw. GNOME, KDE, ...), die damit arbeiten können.

Sehr verwirrend...

Kickstart-Konfiguration

Um eine zentrale grafische Anmeldung durchzuführen, muss zuerst auf allen Clients das X Window-Paket installiert werden. Alle, die dies bereits einmal lokal durchgeführt haben, wissen, dass dies zu einigen Schwierigkeiten führen kann.

Grafikkartentyp und Monitor werden bei der Installation zwingend verlangt, was ebenfalls in die ks.cfg eingefügt werden kann. Eine beispielhafte Zeile könnte in etwa so aussehen.

# skipx => bitte auskommentieren
xconfig --server "S3" --monitor "philips brilliance 105(15inch/cm2200)"

Mit der Option --server "XXX" wird der Grafikkarten-Chipsatz angegeben und --monitor dürfte selbsterklärend sein. Wer nichts von seinen Chips weiß, kann sich mit verschiedenen Tools (SuperProbe o.ä) behelfen, um diese Informationen zu gewinnen.

Neben den bisher installierten Paketen setzen wir auch noch X Window, da es den benötigten X-Server enthält.

%packages
@ Base
@ X Window System

XDM

Unter XDM versteht man den X Display Manager. Dieser sorgt dafür, dass ein grafischer Login erfolgen kann. Bei unserer Konfiguration soll der XDM des Hardware-Servers den Hardware-Clients ein Login von sich zur Verfügung stellen, damit die User auf dem Server arbeiten können. Dies geschieht, indem auf dem Hardware-Server einige XDM-Konfigurationsdateien angepasst werden.

Grundlegend gibt es zwei Möglichkeiten der Konfiguration. Zum einen kann der X-Server (Hardware-Client) beim X-Client (Hardware-Server, Applikationsserver) anfragen und ihn bitten, einen graphischen Login anzubieten (Pull). Zum anderen kann der XDM-Daemon auf dem Hardware-Server dem X-Server (Hardware-Client) beim Netzzugriff ein Login zuteilen (Push). Ich habe mich für die Push-Methode entschieden, da ich keine Änderung am Hardware-Client durchführen muss und alles über den Hardware-Server läuft.

Konfigurationsdateien X-Client

Unter /etc/X11/xdm auf dem Hardware-Server können die benötigten Dateien gefunden werden. Wir benötigen zuerst die Files xdm-config, Xaccess und Xservers.

xdm-config

Die xdm-config ist etwa eine zentrale Konfigurationsdatei. In ihr sind alle Verweise auf die restlichen Dateien wie Log-File, PID-File oder Access-File eingetragen. Am Dateiende ist ein Sicherheitsfeature, das sämtliche Verbindungen zum XDM unterbinden soll. Dies sollte einfach mit einem Ausrufezeichen auskommentiert werden.

! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
! DisplayManager.requestPort: <strong>0</strong>

Xaccess

In dieser Datei wird festgelegt, welche Systeme Zugriff auf den X-Client (Hardware-Server) erlangen dürfen. Dies kann einerseits durch einen Broadcast stattfinden, oder man stellt sich eine Hostlist zusammen.

# The nicest way to run the chooser is to just ask it to broadcast
# requests to the network - that way new hosts show up automatically.
# Sometimes, however, the chooser can't figure out how to broadcast,
# so this may not work in all environments.
#
* CHOOSER BROADCAST #any indirect host can get a chooser
#
# If you'd prefer to configure the set of hosts each terminal sees,
# then just uncomment these lines (and comment the CHOOSER line above)
# and edit the %hostlist line as appropriate
#
#%hostlist host-a host-b
%hostlist 10.100.0.2 10.100.0.3 10.100.0.4 ...
* CHOOSER %hostlist