Automatische Installation

Übersicht

Standen Sie schon einmal vor der Aufgabe, ein Computerkabinett mit Linux zu bestücken? Gelangen Sie oftmals in diese Situation, weil in der einen Woche Linux und in der anderen ein anderes System benötigt wird?

Spätestens hier bieten sich erste Überlegungen an, wie man den Installationsprozess automatisieren könnte. »Diskette rein und [Enter]« sollte doch genügen, um die unbeaufsichtigte Linuxeinrichtung auf einem Rechner in Gang zu setzen.

Und genau diese Möglichkeiten der Installation bringen nahezu alle heutigen Distributionen mit. Mit ein wenig einmaligem Aufwand reduziert sich das Prozedere auf das Einlegen einer Diskette...

Installationsserver?

Die gebräuchlichste - und bei Fai einzige - Methode ist wohl der Zugriff auf einen Installationsserver. Dieser Server besitzt die komplette zu installierende Software (und noch einige Skripte mehr); im einfachsten Fall werden die CD-ROMs der Distributionen in einem Verzeichnis des Serverrechner abgelegt.

Für Clients ohne Netzanbindung nützt ein Server herzlich wenig. Hier hilft nur die Beschränkung auf die Software, die die einzelnen Distributionen mit der ersten CDROM ausliefern (zumindest das Basissystem sollte vollständig enthalten sein). Der Client ist nun quasi sein eigener Server und das CDROM-Laufwerk das Quellverzeichnis.

Bei SuSE-Linux zieht diese Beschränkung leider auch eine Einschränkung nach sich - die Partitionierung der Festplatte kann nun nicht automatisiert ablaufen, da die notwendige Beschreibungsdatei auf der CDROM fehlt.

Wem allerdings die dargebotene Software ohnehin nicht genügt, der kommt um eine eigene Kreation einer Installations-CD nicht umhin; ergänzt man diese im Falle von SuSE-Linux um die Datei mit den Partitionierungsdaten, so steht einer Kaffeepause nichts im Wege...

Für die nachfolgenden Anleitungen gehen wir vom Zugriff auf einen Installationsserver aus; der Leser sollte die notwendigen Anpassungen bei rein lokalem Zugriff leicht nachvollziehen können.

Debian

Fai Fully Automatic Installation ist durchaus keine Floskel, erlauben die Routinen von Debian selbst die automatische Konfiguration zu installierender Anwendungsprogramme. Darüber hinaus lässt sich Fai ebenso als Recovery-Werkzeug nach einem Plattenausfall »missbrauchen«.

Fai automatisiert all jene Schritte, die der Administrator zum Aufsetzen eines kompletten Linuxsystems zu absolvieren hat. Ist die Konfiguration für einen Rechner erst einmal vollzogen, erfordert die Anpassung auf weitere »Clients« kaum Mehraufwand. Fai entfaltet seine Wirksamkeit umso eindrucksvoller, je größer der zu administrierende Rechnerpool ist. Fai kann prinzipiell auf jeder Distribution eingesetzt werden; die dafür notwendigen Eingriffe in die Shell- und Perlskripte bleiben jedoch dem Experten vorbehalten.

Ein wesentlicher Unterschied zu den von RedHat und SuSE entwickelten Mechanismen ist die Lage der Konfigurationsdateien. Fai speichert sie konsequent auf dem Installationsserver, womit das Erstellen einer einzigen Bootdiskette (bzw. mehrerer Kopien) für die Clients genügt.

Installationsserver

Beim Server muss es sich nicht zwingend um ein Linuxsystem handeln, auch wenn die nachfolgende Darstellung in manchem Punkten davon ausgeht. Weiterhin nehmen wir vereinfachend an, dass alle notwendigen Dienste durch einen einzigen Server bereit gestellt werden. Aber auch das ist kein Muss. Wer sich in der Netzwerkadministration etwas auskennt, wird dem Text entnehmen können, welche Bestandteile auch andere Rechner übernehmen könnten.

Ein via Fai zu konfigurierender Client kennt in der Bootphase weder seinen Rechnernamen noch seine IP-Adresse. Beide Parameter (und ggf. anderes mehr) erfragt er anhand der weltweit eindeutigen MAC-Adresse seiner Netzwerkkarte bei einem DHCP- oder einem BOOTP-Server. Ein solcher muss somit vorhanden sein und seine Datenbasis muss Einträge für jeden Client umfassen. Ein Client mountet während der Installation sein Root-Dateisystem über das Network File System. Der Fai-Server ist als NFS-Server einzurichten. Des Weiteren benötigt der Client Zugang zu einem Archiv mit den Debian-Paketen. Im einfachsten Fall bietet gleich der Installationsserver ein solches via NFS an. Alternativen (denen wir nicht folgen werden) sind der Zugriff zu einem Debian-Spiegel über FTP oder HTTP.

Paketinstallation

Neben dem eigentlichen Fai-Basis-Paket empfiehlt sich die Installation des Pakets mit speziellen Fai-Kerneln, die die Fähigkeiten zum Booten übers Netz bereits enthalten. Es spricht natürlich nichts dagegen, einen solchen Kernel selbst zu erzeugen.

Ein lokaler Spiegel

Für die weiteren Aussagen nehmen wir an, dass der lokale Spiegel aus den Debian-Installations-CD's erzeugt werden soll. In den meisten Situationen dürfte dies wohl zutreffen.

Wie ist eine Debian-Installationsquelle aufgebaut? Unterhalb eines mit »dist« benannten Verzeichnisses existieren immer (mindestens) 4 Einträge:

»potato« ist der Name der aktuellen Debian-Distribution (ein Synonym für die sonst gebräuchliche Versionsnummer, dieser Name kann sich ändern). »frozen«, »stable« und »unstable« sind auf den CD's symbolische Links auf »potato«; sie sind als Verweise auf Entwicklerversionen einer Distribution gedacht.

Der Aufbau unterhalb eines solchen Verzeichnisses ist wiederum identisch (bei symbolischen Links erübrigt sich die Aussage):

Hiermit realisiert Debian eine strikte Trennung der GPL-Software vom »Rest«. Unter »main« sammelt sich die Software, die der GPL und vergleichbarer freier Lizenzen unterliegt. »contrib« beinhaltet freie Software, die allerdings von »nicht freier« Software abhängt (bspw. KDE von der Freigabe der QT-Bibliotheken). »non-free« enthält schließlich die »nicht freien« Pakete.

Eventuell finden Sie noch ein Verzeichnis »non-US«, das Software enthält, deren Export durch US-Gesetze beschränkt ist (bspw. kryptografische Programme).

»Contents-i368.gz« enthält eine Zuordnung zwischen jeder im Debian-System verfügbaren Datei (mit Pfadangabe) und dem Paket, das diese enthält. Sie dient einzig der Information.

Eine weitere Stufe enthält für eine i386-Distribution folgende Verzeichnisse:

»binary-all« umfasst die Architektur unabhängigen Pakete, wie Schriften, Dokumentationen... und »binary-i368« beinhaltet - analog zum Serienkonzept von SuSE - Verzeichnisse, in denen letztlich die Pakete nach ihrem Verwendungszweck gruppiert sind:

Das Anlegen eines lokalen Spiegels läuft also darauf hinaus, die Verzeichnisstruktur der Installationsquelle auf dem Server nachzubilden und alle benötigten Pakete in das entsprechende Verzeichnis - laut Debian »Sektion« genannt - zu kopieren.

Einziger Haken ist die Beschreibungsdatei »Packages.gz«, die die Informationen zu den auf dieser CD befindlichen Paketen enthält:

Debian benötigt während der Installation die Beschreibung aus der »Packages«-Datei. Für den Fall, dass der Inhalt mehrerer CD's komplett in den lokalen Spiegel übernommen wurde, lassen sich die verschiedenen Beschreibungsdateien einfach verketten (»zcat«).

Eine Möglichkeit, den Inhalt der Datei auf die tatsächlich gespiegelten Debian-Pakete abzustimmen, besteht im Auslesen der Paketinformationen und daraus generierter »Packages«-Datei:

Die zentrale Konfigurationsdatei /etc/fai.conf

Die Konfiguration von FAI nimmt das Skript fai-setup anhand der Angaben in der Datei /etc/fai.conf vor. Vermutlich sind einige der Variablen auf die lokalen Gegebenheiten anzupassen:

Das folgende Beispiel einer Datei »fai.conf« sollte leicht an die eigenen Bedürfnisse anzupassen sein:

fai-setup

Nachdem die Konfigurationsdatei (fai.conf) für fai-setup angepasst wurde, erledigt der Aufruf des Skripts die eigentliche Einrichtung auf Serverseite:

Im Einzelnen vollbringt das Skript Folgendes:

1. Erstellen des Benutzers fai
2. Einrichten des NFS-Wurzelverzeichnisses mit
3. • Installation des Basispakets basexxx.tgz
   • Installation der zusätzlichen Pakete
   • Ggf. Einrichten der SSH
   • Einbinden von Fai-Diensten in den Bootprozess (faireboot, faillog, fai_config,...)
4. Ggf. Anpassung der Datei /etc/exports und Neustart des NFS-Servers

fai-setup ist somit immer zu starten, sobald Sie Änderungen an der Datei /etc/fai.conf vorgenommen haben oder einen neuen Kernel installieren möchten.

Den Bootp-Server einrichten

Der Server selbst befindet sich bei Debian im Paket »net-boot.deb«. Details zum Aufsetzen eines Bootp-Servers erfahren Sie im Abschnitt DHCP&Co. unter Netzwerk-Server. Dort finden Sie auch die Erläuterungen zu den im nachfolgenden Beispiel verwendeten Optionen.

Ein Fai-Client benötigt Informationen, die über den üblichen Informationsgehalt eines Bootp-Servers hinausgehen. Um diese dennoch bereit zu stellen, greift der Server auf »Hersteller spezifische« Erweiterungen zurück, die sich hinter den mit T.. beginnenden »Tags« verbergen.

Die derzeit von Fai verwendeten Tags sind:

Die Bootdiskette

Dem Fai-Paket liegt ein Programm zum Erzeugen der Bootdiskette bei, sodass sich die ganze Arbeit auf das Einlegen einer leeren Diskette und den Aufruf eines Kommandos reduziert:

Kopieren und Bearbeiten der Templates

Die bisherigen Vorarbeiten ermöglichen es einem Client, seine IP-Adresse von einem Server zu beziehen, den Kernel vom Server zu laden, zu booten und sein Root-Dateisystem via NFS zu mounten.

Das Ziel von Fai ist jedoch, auf Clientseite ein vollständiges Linuxsystem zu installieren. Der Client startet hierzu im folgenden Schritt das Programm /sbin/rcS_fai. Dieses Skript erzeugt zunächst eine Ramdisk und mountet diese nach /tmp - das vorerst einzig beschreibbare Verzeichnis auf dem Client.

Vom Fai-Server wird über NFS nun das Verzeichnis (vergleiche FAI_CONFIGDIR in fai.conf) mit den eigentlichen Konfigurationsdateien nach /fai gemountet. Genau jene Dateien beschreiben die Schritte, die ein Client nachfolgend zu vollziehen hat.

Natürlich steht es jedem frei, die Konfiguration komplett selbst zu erstellen. Einfacher ist jedoch die Verwendung der Templates aus /usr/share/doc/fai/templates und das Anpassen von Kopien an die eigenen Gegebenheiten:

Ein Blick unter /usr/local/share/fai fördert einige Verzeichnisse zu Tage:

Schritt 1: Definition der Klassen

Jeder Konfigurationsschritt, der auf dem Client zu vollziehen ist, wird durch eine so genannte Klasse beschrieben. Da für verschiedene Clients sicherlich verschiedene Konfigurationen sinnvoll sind, ermitteln Skripte die Klassennamen, die nachfolgend gelten sollen. rcS_fai arbeitet hierzu - ähnlich dem Ressource Control Script eines »normalen« Linux-Bootvorgangs - die im Verzeichnis /fai/class(nach dem Mounten liegt es dort!) liegenden und mit "S[0-9][0-9]" beginnenden Skripte in der durch die alphabetische Anordnung gegebenen Reihenfolge ab.

Bei den Skripten kann es sich wohl um Bash- (Endung *.sh) als auch um Perlskripte (Endung. *pl) handeln; jedes Wort, das ein Skript auf die Standardausgabe schreibt, wird als Klassenname interpretiert.

Beispiel: Ein typisches Skript könnte anhand des Rechnernamens gleichnamige Klassen definieren, um für jeden Client oder eine Gruppe von Clients eine dedizierte Konfiguration vorzunehmen:

Etwas vereinfacht ausgedrückt, testen die Skripte unter class im Wesentlichen die lokale Hardware und ermitteln daraus die Klassenname zur Steuerung der weiteren Konfiguration. Zusätzlich werden immer die Klassennamen $HOSTNAME und LAST gesetzt.

Schon der nächste Schritt von rcS_fai verdeutlich das Konzept der Klassennamen. Das Skript sucht im Verzeichnis /fai/class nach Dateien mit dem Namen Klassenname.var und führt sie aus, wodurch bestimmte Shellvariablen mit konkreten Werten belegt werden. Folgendes Beispiel (aus den Quellen des Fai-Pakets) setzt eine Variable hdparm, um Festplattenparameter zu konfigurieren:

Schritt 2: Partitionieren der Festplatte(n), Erzeugen der Dateisysteme

Existiert das Skript /usr/local/bin/my-fdisk, so übernimmt dieses die Partitionierung und das Einrichten der Dateisysteme. Auf diese Weise kann die Ausführung von setup_harddisks durch rcS_fai verhindert werden. Letzteres Skript durchsucht das Verzeichnis /fai/disk_config, ob ein Klassenname mit dem Namen einer Datei übereinstimmt. Die erste passende Datei (bei sauberer Konfiguration sollte es nur eine geben) wird eingelesen und anhand der Angaben die Festplatte(n) eingerichtet:

Schritt 3: Software-Installation

Zunächst wird das Basissystem (vergleiche FAI_BASETGZ aus /etc/fai.conf) entpackt und installiert. rcS_fai liest nachfolgend jede in /fai/package_config enthaltene Datei ein, deren Name einem definierten Klassennamen entspricht. Auf diese Art und Weise kann einfach eine clientabhängige Software-Ausstattung erzielt werden:

Schritt 4: Lokale Konfiguration

Zu einem kompletten System gehört noch die Konfiguration verschiedenster Dienste. So ist das Netzwerk einzurichten, der Druckerzugriff zu gewährleisten oder die Uhrzeit zu setzen...

Zuständig für diesen abschließenden Schritt sind die Skripte im Verzeichnis /fai/scripts. Auch hier werden wiederum genau jene Skripts zur Ausführung gebracht, deren Namen mit eingangs definierten Klassennamen übereinstimmen. Zulässig sind Bash-, Perl-, Expect- und Cfengine-Skripts. Manche dieser Skripts werden vorgefertigte Konfigurationsdateien ins System einspielen. Solche Vorgaben können im Verzeichnis /fai/files gesammelt werden.

Der letzte Schritt

Nach Abschluss werden die Protokolldateien des Installationsvorgangs nach /var/log/fai/$HOSTNAME/install/ geschrieben und der Rechner neu gebootet.

Der Installationsvorgang beim Client

Genau genommen sind drei Handlungen von Nöten:

1. Bootdiskette einlegen
2. BIOS auf »Booten von Floppy« einstellen
3. Abwarten und Tee trinken

Die im Verborgenen ablaufenden Vorgänge sind dann doch um Einiges komplexer:

1. Booten des Kernels (Rechnername und IP-Adresse wird über BOOTP/DHCP ermittelt)
2. Mounten des Root-Dateisystems via NFS
3. Start von Fai (Mounten von /fai)
4. Bestimmen der Klassen
5. Ggf. Laden von Kernelmodulen
6. Partitionierung der Festplatte(n)
7. Erzeugen der Dateisysteme
8. Installation des Grundsystems
9. Installation zusätzlicher Pakete
10. Anpassung der Konfiguration
11. Sicherung der Protokolldateien sowohl lokal als auch auf dem Installationsserver
12. Reboot des neu installierten Systems

RedHat

Für die unbeaufsichtigte Installation hat sich bei RedHat der Name Kickstart eingebürgert. Die Tätigkeit des "Installationsservers" beschränkt sich hier einzig auf die Bereitstellung der RPM-Pakete; die gesamte Steuerung der Installation liegt in der Hand des Clienten; er bestimmt über die Aufteilung der Festplatte, über den Umfang der Installation usw.

Echte administrative Arbeit steht somit nur bei der Erzeugung der Bootdiskette und der Anpassung der darauf befindlichen Konfigurationsdateien an.

Installationsserver

Wie schon angedeutet, stellt der Server einzig die Software-Pakete zur Verfügung. In den meisten Fällen wird es sich um einen NFS-Server handeln, so dass die Schritte:

1. Einrichten eines NFS-Servers
2. Anlegen eines Verzeichnisses (bspw. /export/RH_70)
3. Kopieren aller notwendigen Software-Pakete nach /export/RH_70:
   • Die komplette CDROM 1
   • Den Inhalt aus dem Verzeichnis "images" der CDROM 2
   • Weitere Pakete nach Bedarf
4. Exportieren des neuen Verzeichnisses

durchzuführen sind.

Alternative Quellen für die Pakete sind lokale CDROMs, lokale Festplatten oder eine Webseite (URL).

Die Bootdiskette

Auf der zweiten CDROM Ihrer RedHat-Distribution finden Sie im Verzeichnis "images" die beiden Dateien boot.img und bootnet.img. Erstere Datei sollten Sie auf die Bootdiskette kopieren, wenn sich die zu installierenden Pakete auf einem lokalen Medium (CDROM, Festplatte) befinden; letztere, falls Sie auf ein Verzeichnis im Netz zugreifen:

Auf der Diskette finden Sie nun im Wurzelverzeichnis die Datei syslinux.cfg (es handelt sich um die Konfigurationsdatei für den syslinux-Bootloader), die Sie ggf. an Ihre Umgebung anpassen müssen;

Erläuterung: Der Name des Eintrags lautet "linux" (die "default"-Zeile ist genau genommen unsinnig, da nur ein einziger Kernel gebootet werden kann). Der zu startende Kernel ist "vmlinuz". Die "append"-Zeile definiert die Parameter, die dem Kernel beim Start als Argumente zu übergeben sind. Hier wird eine Ramdisk verwendet, Informationen dazu finden Sie im Kapitel Systemadministration unter Der Bootvorgang. Die Anzeige eines Prompts wird abgeschaltet und mit "timeout" wird die Verweildauer (in Milisekunden; 0 bedeutet "Warten auf eine Eingabe") des Eingabeprompts angegeben.

Die wesentliche Administration findet in der Datei ks.cfg statt, die Sie ebenfalls im Wurzelverzeichnis auf der Diskette finden. Hier wird sowohl die Partitionierung der Festplatte beschrieben, als auch die Liste zu installierender Pakete spezifiziert. Des Weiteren lassen sich Skripte angeben, die unmittelbar vor bzw. nach der Installation auszuführen sind.

Auf Einhaltung einer bestimmten Reihenfolge der Einträge in der Datei ist dringend zu achten:

1. Angabe der Schlüsselworte, wobei die zugehörigen Parameter auf einer Zeile stehen müssen (die Reihenfolge der Anordnung der Schlüsselworte untereinander spielt keine Rolle):

   # ALLGEMEINE ANGABEN # Auswahl der Sprache # lang : en_US, fr_FR, it_IT, ru_RU.KOI8-R, .. lang de_DE # Auswahl der Zeitzone (Angaben analog zu 'timeconfig') # --utc :                               # BIOS Uhr auf GMT timezone --utc Europe/London # HARDWAREKONFIGURATION # Auswahl der Tastatur # keyboard : azerty, uk, us, fr, ... keyboard de-latin1-nodeadkeys # Auswahl der Maus # mouse # --device <Mausgerät> :                # ps/2, logitech, microsoft, none .. # --emulthree :             # Emulation einer 3-Button-Maus mouse --device ps/2 # KERNELMODULE # Die Angaben sind optional, da versucht wird, die Hardware automatisch zu erkennen und notwendige Module zu laden (eine Angabe kann dem "Autoprobing" in manchen Fällen "auf die Sprünge" helfen) # Netzwerk und SCSI # device [eth|scsi] <module>            # entsprechende Kernelmodule device eth pcnet32 # device scsi aic7xxx # SICHERHEIT # Authentifizierung # auth : Default : verschlüsselt, aber kein shadow # --enablemd5 :                         # md5 Verschlüsselung # --useshadow :                         # Shadow Passwörter # NIS (Network Information System) # # --enablenis :                         # NIS einschalten # --nisdomain :                         # NIS Domäne # --nisserver :                         # NIS Server auth --useshadow --enablemd5 # Passwort von Root # rootpw <Passwort> # --iscrypted <Verschlüssltes_Passwort> rootpw Guiness # NETZWERK # Diese Angabe ist nur bei Installation übers Netz notwendig; die Parameter bedeuten: # --device : eth0, ..                   # Device-Name # --ip :                                # IP-Adresse # --hostname :                          # Name des Rechners # -- netmask :                          # Netzmaske # --bootproto : dhcp, bootp, static     # Bootmethode; Default : dhcp network --device eth0 --ip 172.16.91.100 --hostname pc20 --netmask 255.255.255.0 --gateway 172.16.91.100 --nameserver 172.16.91.1 --bootproto static # INSTALLATIONSMETHODE # Entfällt die Angabe, wird die CDROM als Installationsmedium angenommen # Mögliche Paketquellen sind: # CDROM :                               # Voreinstellung # NFS :                                 # NFS-Server # HARDDRIVE :                           # lokal auf der Festplatte # URL :                                 # aus dem Internet nfs --server 172.16.91.1 --dir /export/RH_70/ # cdrom # harddrive --partition <Verzeichnis> dir <Verzeichnis> # url --url http://<Server>/<Verzeichnis> # X WINDOW # Diese Angaben sind optional und machen nur Sinn, wenn die X-Pakete installiert wurden # Falls nicht angegeben, dann manuelle Konfiguration # xconfig : # --card <Karte aus Xconfigurator>      # Grafikkarte # --monitor <Monitor aus Xconfigurator> # Monitor # oder # --hsync <Wert> mit --vsync <Wert>     # Frequenzwerte des Monitors # --defaultdesktop=[GNOME|KDE]          # Standarddesktop # --startxonboot                        # Grafisches Login # xconfig # Falls X Windows installiert, aber keine Konfiguration gewünscht skipx # LILO # Konfiguration von LILO # --location : mbr, none, partition (auf Partition mit Kernel) # --append :                            # Kernelparameter lilo --location mbr --append mem=128M # Mit den optionalen Parameter "lilocheck" kann geprüft werden, ob der Linux Loader bereits installiert ist. Falls ja, wird keine Installation vorgenommen (Verhinderung einer Neuinstallation!) # lilocheck # NACH DER INSTALLATION... # Falls ein automatischer Neustart am Ende der Installation erfolgen soll (ohne die Angabe wird der Benutzer gefragt): # reboot # PARTITIONIERUNG # Die optionale Angabe von "clearpart" ermöglicht das vorherige Löschen von Partionen (Voreinstellung: kein Löschen) clearpart --linux                       # nur Linux-Partitionen # clearpart --all                       # alle Partitionen # Für jeder anzulegende Partition ist deren Mountpunkt, deren Lage (welches Device) und die Größe in MByte anzugegebn: part /boot  --ondisk hda --size 10 part swap   --ondisk hda --size 128 part /      --ondisk hda --size 1024

2. Liste der zu installierenden Pakete oder Serien; eine Beschreibung befindet sich auf der CDROM unter "/RedHat/base/comps":

   # Eine vorangestellten "@" deklariert den Namen als eine Serie; sonst werden die Angaben als Paketnamen interpretiert %packages @ Base @ X Window System # @ Printer Support # @ GNOME # @ Mail/WWW/News Tools # @ Multimedia Support # @ Networked Workstation # @ Dialup Workstation tcsh XFree86-xf86cfg XFree86-VGA16 XFree86-Mono XFree86-SVGA

3. Optionales Pre- und Post-Install-Skript:

   # Die beiden Skripte werden direkt in der Datei formuliert # Das Pre-Install-Skript: %pre echo "Pre-Install-Skript!" # Das Post-Install-Skript %post echo "Post-Install-Skript!"

   Eine typische Anwendung des Preinstall-Skripts ist das Anlegen einer Sicherungskopie der durch den Installationsvorgang zu überschreibenden Partitionen. In einem Postinstall-Skript ließen sich bswp. erste Benutzer im System einrichten...

Der Installationsvorgang beim Client

Die Schritte, die der Client ab dem Booten von der Diskette durchläuft, sind:

1. Booten des Kernels (mit bzw. ohne Netzwerk)
2. Anlegen einer Ramdisk
3. Start von linuxrc
4. Auslesen der Datei ks.cfg
5. Zugriff auf das Installationsverzeichnis (bei Zugriff auf einen NFS-Server wird dieses als Rootverzeichnis gemountet)
6. Start von Anaconda (RedHat-spezifisches Konfigurationstool)
7. Partitionieren der Festplatte
8. Skripte, die vor der Installation abzuarbeiten sind, werden gestartet
9. Installation der Pakete unterhalb von /mnt
10. Skripte, die nach der Installation abzuarbeiten sind, werden gestartet
11. Wechsel des Rootverzeichnisse (neue Wurzel ist /mnt)
12. Reboot (automatisch, falls in der ks.cfg "reboot" aufgeführt ist; sonst nach Bestätigung)

SuSE

Installationsserver

Der Server ist zunächst als NFS-Server einzurichten. Für die Software, die später auf den Clients zu installieren ist, benötigen Sie ein eigenes Verzeichnis. Dieses darf nicht suse heißen, da das Skript linuxrc in diesem die RPM-Pakete erwartet; SuSE selbst diese aber in einem Unterverzeichnis suse ablegt. linuxrc kann den Pfad "suse/suse" (warum auch immer) nicht auflösen. Die NFS-Freigabe dieses Stammverzeichnisses wird später in den Skripten als $I: referenziert; nachfolgend soll dieses Symbol für das von Ihnen angelegte Verzeichnis stehen. Vergessen Sie nicht, das neue Verzeichnis in die Datei "/etc/exports" aufzunehmen und dem NFS-Server ein SIGHUP zu senden.

Kopieren Sie den Inhalt der SuSE-CD's, den Sie benötigen (also zumindest die 1.CD komplett) in dieses neue Verzeichnis. Die verschiedenen CD's enthalten teils identische Dateien (Indexverzeichnisse), diese werden im Zielverzeichnis (logischer weise) nur einmal benötigt und können getrost überschrieben werden.

Zusätzliche RPM-Pakete, die nicht zum Umfang der SuSE-Distribution gehören, lassen sich unter $I:/suse/ADD_RPMS/ ablegen und werden automatisch mit installiert.

Zusätzliche Skripte lassen sich nach dem selben Schema in ein Verzeichnis $I:/suse/ADD_SCRIPTS/ integrieren. Diese können unmittelbar vor oder nach der Installation gestartet werden (dies wird in der Datei info fest gelegt).

Ein sinnvolles Skript, das unmittelbar nach der Installation ausgeführt werden sollte, betrifft die Vergabe des Rootpasswortes. Dieses könnte wie folgt ausschauen:

Eine Datei AutoSuSE.sel (der Name kann frei gewählt werden; die Endung ".sel" ist bindend) im Verzeichnis $I:/suse/setup/descr beinhaltet die Liste der zu installierenden Pakete. Am einfachsten ist es, im YaST1 unter "Konfiguration erstellen/ändern" eine solche Auswahl zu erzeugen:

Da es sich um eine ASCII-Datei handelt, steht einer manuellen Anpassung nichts im Wege (man muss nur die Paketnamen kennen).

Ein Client kann sich bez. der Softwareauswahl nur auf die Vorgaben einer solchen Datei beziehen; benötigt man mehrere Konfigurationen, ist für jede eine Paketauswahldatei zu generieren.

Auf dem Server fehlen einzig noch die Dateien mit den Partitionierungsanweisungen. Sie müssen im Verzeichnis $I:/suse/setup/descr liegen und nennen sich part_XXXXX, wobei XXXXX eine fünfstellige Zahl > 0 ist, die die Anzahl des für das System anzulegenden Speicherplatzes in Megabyte angibt.

Existieren mehrere part_XXXXX-Dateien im Verzeichnis, wählt der Client selbsttätig diejenige, deren Größe bez. der Festplattenkapazität am besten passt (die also kleiner oder gleich dieser ist).

Erläuterung: 2 GByte Plattenplatz werden wie folgt verteilt:

• Die erste Partition /boot ist 10 MByte groß; es wird ein Dateisystem ext2 (Voreinstellung) mit einer Blockgröße von 1024 Bytes (bs=...) erzeugt
• Die zweite Partition wird mit 64 MByte Kapazität angelegt und wird als Swap formatiert
• Der Rest (physische Plattenkapazit&aumlt >=2 GB - 74MB) wird das Rootdateisystem, das mit 4k-Blöcken und ReiserFS zu formatieren ist

Die Bootdiskette

Auf der ersten SuSE-CD finden Sie im Verzeichnis images/ die Datei boot.img, die auf die Diskette zu kopieren ist:

Mounten Sie anschließend die Diskette und passen die dortige Datei syslinux.cfg (es handelt sich um die Konfigurationsdatei für den syslinux-Bootloader) an:

Erläuterung: Der Name des Eintrags lautet »linux«, ebenso nennt sich der zu startende Kernel »linux«. Die »append«-Zeile definiert die Parameter, die dem Kernel beim Start als Argumente zu übergeben sind. Hier wird eine Ramdisk verwendet, Informationen dazu finden Sie im Kapitel Systemadministration unter Der Bootvorgang. Mit »timeout« wird die Verweildauer (in Millisekunden; 0 bedeutet »Warten auf eine Eingabe«) des Eingabeprompts angegeben.

Als abschließenden Schritt müssen Sie nun die Datei info bearbeiten, die Sie im Wurzelverzeichnis auf der Diskette finden. Hier findet die eigentliche Konfiguration statt, d.h. welchen Server Sie kontaktieren, welche Dateien Sie von diesem benutzen usw. Die folgende Beispieldatei wurde bewusst um ausführliche Kommentare ergänzt und kann als Ausgangspunkt für eigene Experimente dienen:

Die Erzeugung der Bootdiskette ist damit abgeschlossen.

Der Installationsvorgang beim Client

Die Schritte, die der Client ab dem Booten von der Diskette durchläuft, sind:

1. Booten des Kernels (dessen NFS-Unterstützung ist zwingend erforderlich, falls ein Installationsserver Verwendung findet)
2. Anlegen einer Ramdisk
3. Die Info-Datei wird gelesen
4. Mounten des Installationsverzeichnisses vom Server nach /var/adm/mount
5. YaST1 startet
6. Partitionieren der Festplatte
7. Skripte, die vor der Installation abzuarbeiten sind, werden gestartet
8. Installation der Pakete unterhalb von /mnt
9. Skripte, die nach der Installation abzuarbeiten sind, werden gestartet
10. Wechseln des Rootverzeichnis (/mnt wird zur neuen Wurzel) oder Start des neuen Kernels, falls der "alte" nicht der richtige ist (bspw. SMP)