Druckversion

Automatische Installation

Übersicht Weiter

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 Zurück Anfang Weiter

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.

root@sonne> dpgk -i fai_1.4.2_i386.deb
Selecting previously deselected package fai.
(Reading database ... 29597 files and directories currently installed.)
Unpacking fai (from fai_1.4.2_i386.deb) ...
...
root@sonne> dpgk -i fai-kernels_1.0_i386.deb
Selecting previously deselected package fai.
(Reading database ... 30163 files and directories currently installed.)
Unpacking fai-kernels (from fai-kernel_1.0_i386.deb) ...
...

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:

root@sonne> ls dist/
frozen   potato   stable   unstable

»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):

root@sonne> ls dist/potato
Contents-i386.gz   contrib   main   non-free

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:

root@sonne> ls dist/potato/main
binary-all   binary-i386   sources

»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:

root@sonne> ls dist/potato/main/binary-i386
Packages.gz   Release   admin    base   comm
devel         doc       editors  ...

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:

root@sonne> zless dist/potato/main/binary-i386/Packages.gz
...
Package: adduser
Version: 3.11.1
Priority: required
Section: base
Maintainer: Guy Maor <maor@debian.org>
Depends: passwd (>=961025)
Architecture: all
Filename: dists/potato/main/binary-i386/base/adduser_3.11.1.deb
Size: 17274
MD5sum: 2f78fdd289c971374bd548c3da9c02a6
Description: Add users and groups to the system.
Adduser can create new users and ...
...

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:

root@sonne> cd dist/potato/main/binary-i386/
root@sonne> for i in $(find . -name "*.deb"); do
> dpkg -I $i | sed -n '/^\ *Package.*/,$p' >> Packages
> echo "" >> Packages
> done

root@sonne> gzip Packages

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:

FAI_BASETGZ

Lage der Datei mit dem Basissystem. Dabei handelt es sich um ein Tape Archiv mit dem Namen baseVersion.tgz. Die Angabe kann sowohl ein Verzeichnis als auch eine Datei auf einem FTP- oder HTTP-Server sein. Befindet sich jedoch eine gleichnamige Datei im lokalen Verzeichnis /tmp, wird stets diese verwendet - unabhängig von der Belegung der Variablen!

FAI_SOURCE_LIST

Angabe der Lage der Debianquellen und der Zugriffsmethode. Die Syntax entspricht der der Datei sources.list:

deb <Lage des Archivs> <Distributionsname> [Komponente(n)]

Die Lage des Archivs wird mit einem Schlüsselwort eingeleitet. Die drei Wichtigsten sind:

file Die Quellen liegen lokal auf der Platte (in einem gemounteten Verzeichnis); der lokale Mountpunkt (MNTPOINT) und der Zugriffspfad zum NFS-Server (FAI_PACKAGEDIR) sind anzugeben.
http Die Quellen werden über einen Webserver bezogen
ftp Die Quellen liegen auf einem FTP-Server

Dem Schlüsselwort folgt, durch einen Doppelpunkt getrennt, der Zugriffspfad zum Archiv.

Der Distributionsname ist das schon weiter oben erwähnte Synonym für die Version, also bspw. »potato«, »woody« oder »stable«. Bei Zugriff auf mehrere Distributionen ist jede auf einer eigenen Zeile zu beschreiben.

Komponenten sind die Namen der zu verwendenden Verzeichnisse unterhalb des Distributionsverzeichnisses (bspw. »contrib«, »non-free«).

NFSROOT

Verzeichnisname, unter dem das NFS-Wurzelverzeichnis des Client eingerichtet werden soll.

KERNELPACKAGE

Name (inklusive Pfad) des Debian-Pakets, das den auf Clientseite zu bootenden Kernel enthält, das Paket wird unter NFSROOT installiert.

FAI_ROOTPW

Das verschüsselte Passwort für Root

SSH_IDENTITY

Datei mit dem öffentlichen SSH-Schlüssel (identity.pub), um einem Benutzer (um dessen Schlüssel es sich handelt,) das passwortfreie Anmelden am Client als Root (!) via ssh zu gestatten. Das Setzen ist nur sinnvoll, wenn der Bootp- bzw. Dhcp-Server dem Client das Flag "sshd" übermittelt (Siehe: »Einen Bootp-Server einrichten«).

NFSROOT_PACKAGES

Liste zusätzlicher Debian-Pakete, die unter NFSROOT zu installieren sind.

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

root@sonne> cat /etc/fai.conf
# /etc/fai.conf -- Konfiguration für FAI (Fully Automatic Installation)
#


# Damit die Pakete für die richtige Architektur verwendet werden
FAI_ARCH=`dpkg --print-installation-architecture`

# Lage der Datei mit dem Basissystem auf dem Fai-Server
FAI_BASETGZ=/usr/local/src/base2_2.tgz

# Wohin soll der Client den Debian-Spiegels mounten?
MNTPOINT=/mnt

# Wo liegt der Debian-Spiegel (NFS-Server)?
FAI_PACKAGEDIR=192.168.0.1:/opt/debian/export/debian_22

# Was soll von welchem Debian-Spiegel verwendet werden?
# Im Beispiel erfolgt der Zugriff auf ein NFS-Verzeichnis

FAI_SOURCES_LIST="deb file:$MNTPOINT/debian stable main contrib non-US/main"

# Verschlüsseltes Passwort für Root; wird auf den Clients gesetzt
FAI_ROOTPW="56hNVqht51tzc"

# Lage der Datei .identity.pub des Benutzers, der sich als Root am Client anmelden darf
# SSH_IDENTITY=/home/admin/.ssh/identity.pub


# Zusätzlich soll "ssh" installiert werden
NFSROOT_PACKAGES="ssh"

# Setzen der Zeitzone auf GMT; bei "no" wird "lokale Zeitzone" verwendet
UTC=yes

# Basisverzeichnis, sollte nicht verändert werden
LIBFAI=/usr/lib/fai

# Lage des NFS-Wurzelverzeichnisses (mit mind. 100MB freien Speicherplatz!)
NFSROOT=$LIBFAI/nfsroot

# Kernelpaket, das unter NFSROOT zu installieren ist
KERNELPACKAGE=/usr/lib/fai/kernel/kernel-image-2.2.17_BOOTP1_i386.deb

# Zu installierende Kernelversion (Kernel muss im Kernelpaket enthalten sein!)
KERNELVERSION=2.2.17

# Lage der weiteren Fai-Konfigurationsdateien auf dem Server
FAI_CONFIGDIR=/usr/local/share/fai

fai-setup

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

root@sonne> /usr/sbin/fai-setup
Adding system user fai...
Stopping Name Service Cache Daemon: nscd.
Adding new user fai (100) with group nogroup.
Starting Name Service Cache Daemon: nscd.
Creating home directory /home/fai.
/home/fai/.rhosts created.
User account fai created.
Creating FAI nfsroot can take a long time and will
need more than 100MB disk space in /usr/lib/fai/nfsroot.
Unpacking /tmp/base2_2.tgz
...

Im Einzelnen vollbringt das Skript Folgendes:

  1. Erstellen des Benutzers fai
  2. Einrichten des NFS-Wurzelverzeichnisses mit
    • 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,...)
  3. 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.

root@sonne> cat /etc/bootptab
# »Makro«, das Paketgröße (ms), Verzeichnis der Bootdatei (hd), Bootdateigröße (bs) und NFS-Verzeichnis (rp) festlegt
# Zusätzlich wird dem Client sein Rechnername zugewiesen (hn)
.faiglobal:\
       :ms=1024:\
       :hd=/boot/fai:\
       :hn:\
       :bs=auto:\
       :rp=/usr/lib/fai/nfsroot:

# »Makro«, das die Wert aus dem Makro ».faiglobal« übernimmt
# Weitere Parameter betreffen den TFTP-Server (sa), Zeitserver (ts), Subnetzmaske (sm), Gateway (gw), Domainname (dn) und DNS-Server (ds)
# Erläuterung zu T.. folgt im Anschluss
.failocal:\
       :tc=.faiglobal:\
       :sa=192.168.100.1:\
       :ts=192.168.100.1:\
       :T170="FAISERVER:/usr/local/share/fai":\
       :T171="sysinfo":\
       :sm=255.255.255.0:\
       :gw=192.168.100.1:\
       :dn=galaxis.de:\
       :ds=192.168.100.1:

# Beschreibungen für jeden einzelnen Client
# Weitere Parameter sind Typ des Netzwerks (ht), die Hardwareadresse (ha), Name der Bootdatei (bf) und die IP des Client (ip)
faiclient01:\
   ht=ether:ha=0050569a0001:bf=faiclient01:ip=192.168.100.101:\
   tc=.failocal:T171="sysinfo":T172="sshd verbose":

faiclient02:\
   ht=ether:ha=00e07d79ac3b:bf=faiclient02:ip=192.168.100.102:\
   tc=.failocal:T171="install":T172="sshd":

faiclient03:\
   ht=ether:ha=00E07D79CBE9:bf=faiclient03:ip=192.168.100.103:\
   tc=.failocal:T171="showclasses":T172="sshd":

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:

T170

Verzeichnis, das die FAI-Konfiguration enthält

T171

Die so genannte FAI-Aktion, welche im Hauptinstallationsskript des Clients (rcS_fai) ausgewertet wird

T172

Liste von Flags für Fai; möglich sind:

debug Debugmodus; ggf. notwendige Konfiguration von installierten Paketen muss interaktiv vorgenommen werden
reboot Rechner wird nach Abschluss der Installation neu gestartet
sshd Der Secure Shell Daemon wird gestartet, um entferntes Anmelden zu ermöglichen
verbose Aktiviert eine erweiterte Ausgabe während des Installationsvorgangs

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:

root@sonne> /usr/sbin/make-fai-bootfloppy

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:

root@sonne> cp -pR /usr/share/doc/fai/templates /usr/local/share/fai

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

class

Skripte und Dateien zur Definition von Klassen (siehe im Anschluss an diese Tabelle)

disk_config

Beschreibung der Partitionierung der Festplatten auf den Clients mit Dateinamen gleich Klassennamen

fai_config

Dateien mit Variablendefinition (Dateinamen gleich Klassennamen + global.conf) zur Überschreibung der Varaiblen aus /etc/rcS_fai.conf

files

Dateien für cfengine

package_config

Software-Paket-Konfigurationen mit Dateinamen gleich Klassennamen

scripts

cfengine-Skripts mit Dateinamen gleich Klassennamen

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:

root@sonne> cat /usr/local/share/fai/class/S01alias.sh
#! /bin/sh

case $HOSTNAME in
   erde)
      echo ERDE
      ;;
   disk??)
      echo DATALESS
      ;;
esac

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:

root@sonne> cat /usr/local/share/fai/class/ATA33.var
# enable ultra ATA/33 modus for hard disk hda
# create etc/rcS.d/S61hdparm

# if defined, this line is executed and written to /etc/init.d/S61hdparm

hdparm='hdparm -c1 -d1 -m16 -X66 /dev/hda'

# tune harddisk during installation
[ "$hdparm" ] && eval $hdparm

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:

root@sonne> cat /usr/local/share/fai/disk_config/4GB
# disk configuration for one disk with up to 4GB disk space

# <type> <mountpoint> <size in mb> [mount options]  [;extra options]


disk_config hda

primary  /             50          rw,errors=remount-ro ;-c
logical  swap          200         rw
logical  /var          200         rw
logical  /tmp          100-250                          ;-m 0
logical  /usr          700          rw
logical  /scratch      0-          rw,nosuid            ;-m 0 -i 50000

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:

root@sonne> cat /usr/local/share/fai/package_config/NFSSERVER
PACKAGES install
nfs-server

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 Zurück Anfang Weiter

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:

# Installation von CDROM oder Festplatte
root@sonne> dd if=boot.img of=/dev/fd0

# Installation von einem NFS-Server oder URL
root@sonne> dd if=bootnet.img of=/dev/fd0

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;

root@sonne> mount /dev/fd0 /mnt/floppy
root@sonne> cat /mnt/floppy/syslinux.cfg
default linux
label linux
  kernel vmlinuz
  append initrd=initrd.img devfs=nomount lang=de ks=floppy
prompt 0
timeout 10

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 Zurück Anfang

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:

user@sonne> cat suse/ADD_RPMS/post_install.sh
#!/bin/sh

# Damit niemand die Ausgaben sieht, leiten wir sie in den Mülleimer
exec > /dev/null 2>&1

ORIG=/mnt/etc/shadow
TEMP=/mnt/etc/shadow.tmp
LOG=/mnt/var/adm/inst-log/post.sh.log

echo "Postinstall Script!"
# Das verschlüsselte Passwort lautet: "DAbzbyj39/Lq"; wir setzen es in der Passwortdatei:
sed 's/root::/root:DAbzbyj39\/Lq\.:/' $ORIG > $TEMP

cat $TEMP > $ORIG
rm $TEMP

# Die Logdatei sollte nur Root lesen dürfen:
chmod 600 $LOG

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:

user@sonne> cat AutoSuSE.sel
# SuSE-Linux Configuration YaST Version 1.03 -- (c) 1994-2000 SuSE GmbH
# generated on Sat Jul 29 20:41:09 GMT 2000


Description.english: AutoSuSE
Description.french: AutoSuSE
Description.german: AutoSuSE
...

Info.english:
Ofni.english:
...

Kind: baseconf

Visible: true

Toinstall:
aaa_base
aaa_dir
aaa_skel
ash
base
bash
bc
...
# Endekennung nicht vergessen (reine SuSE-Syntax)
Llatsinot:

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).

user@sonne> cat suse/setup/descr/part_02000
# Partitionstabelle
# Schlüsselwörter :
# size=nnnn             # Größe in MB, 0 entspricht dem Rest
# fsys=reiser          # Reiserfs
# id=xx                 # Id der Partition
# bs=nnnn               # Blockgröße

/boot   size=10 bs=1024
swap    size=64
/       size=0 bs=4096 fsys=reiser

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:

root@sonne> dd if=boot.img of=/dev/fd0

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:

root@sonne> mount /dev/fd0/floppy
root@sonne> cat /floppy/syslinux.cfg
label linux
  kernel linux
  append initrd=initrd rw ramdisk_size=65536 linuxrc=auto

timeout 1

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:

user@sonne> cat info
# Konfiguration der Installation (Sprache, Bildschirm, Tastatur)
#
Language:               german          # oder: english
Display:                color          
# oder: mono
Keytable:               de-lat1-nd      # oder: us, fr-latin1, it

# Angabe des Bootmodus (hier übers Netz)
#
Bootmode:               Net             # oder: CD

# Konfiguration des Netzwerkes (Laden eines Moduls, um die Netzwerkkarte anzusprechen)
#
insmod pcnet32                          # Laden von Modulen
Netdevice:              eth0            # Netzwerkinterface
IP:                     172.16.91.100   # IP-Adresse
Netmask:                255.255.255.0   # Netmaske
# Konfiguration der Netzinstallation (Installationsserver, Name des Installationsverzeichnisses...)
#
Gateway:                172.16.91.1     # IP-Adresse des Gateway
Nameserver:             172.16.91.1     # IP-Adresse des Nameservers
Server:                 194.180.239.232 # IP-Adresse des NFS-Server
Serverdir:              /export/SuSE_70 # exportiertes NFS-Verzeichnis

# Angabe des CD-ROM's für Installation
#
CDROM_DEVICE            /dev/hdc

# Schlüsselwörter fur Installation
#

# Soll Installation automatisch geschehen?
# FAST_INSTALL          0               # Nein
# FAST_INSTALL          1               # Ja, aber nur mit Bestätigung
FAST_INSTALL            2               # Ja ohne Bestätigung

# Was soll bei Problemen geschehen?
NEVER_STOP              0               # Benutzerabfrage
# NEVER_STOP            1               # Defaultwert und weiter

# Soll automatisch partitioniert werden?
# AUTO_FDISK            0               # Nein
# AUTO_FDISK            1               # Ja, aber nur mit Bestätigung
AUTO_FDISK              2               # Ja ohne Bestätigung

# Frage nach Verwendung der SWAP-Partition
# NO_ASK_SWAP           0               # Ja
NO_ASK_SWAP             1               # Nein

# Angabe der Sel-Datei für Paketauswahl
AUTO_INSTALL            $I:/suse/setup/descr/AutoSuSE.sel

# Interaktion, wenn ungelöste Pakeabhängigkeiten auftreten?
CHECK_DEPENDENCY        0               # Nein
# CHECK_DEPENDENCY      1               # Ja

# Interaktion nach Beendigung der Paketinstallation?
INSTALL_WAIT            0               # Nein
# INSTALL_WAIT          1               # Ja
# Angabe des zu installierenden Kernels
AUTO_KERNEL             k_deflt.rpm     # Standardkernel
# AUTO_KERNEL           k_laptop.rpm    # Kernel mit APM Unterstützung
# AUTO_KERNEL           k_ide.rpm       # Kernel für spezielle IDE Chipsätze
# AUTO_KERNEL           k_smp.rpm       # Kernel mit SMP Unterstützung
# AUTO_KERNEL           k_i386.rpm      # Kernel für i386
# AUTO_KERNEL           MeinKernel      # eigener Kernel unter suse/images/MeinKernel.ikr

# Soll LILO automatisch konfiguriert weren?
# AUTO_LILO             0               # Nein
# AUTO_LILO             1               # Ja mit Bestätigung
AUTO_LILO               2               # Ja ohne Bestätigung

# Sollen Netzparametern automatisch übernommen werden?
# Frage: Loopback/Netzwerk bis Sendmail-Abfrage
# AUTO_NET              0               # Nein
AUTO_NET                1               # Ja

# Soll der Nameserver (von bootp, DHCP ..) übernommen werden?
# AUTO_NAMESERVER 0               # Nein
AUTO_NAMESERVER 1               # Ja

# Soll der Rechnernamen (durch bootp, DHCP ..) übernommen werden?
# AUTO_NAME             0               # Nein
AUTO_NAME               1               # Ja, Name entsprechend IP-Adresse

# Sollen die Parameter des Netzwerkservice abgefragt werden?
# AUTO_SERVICES         0               # Ja
AUTO_SERVICES           1               # Nein

# Frage nach Installation ob System gebootet werden soll.
# END_MESSAGE           0               # Nein
END_MESSAGE             1               # Ja

# Setzen der notwendigen rc.config-Parameter.
RC_CONFIG_0             TIMEZONE       MET
RC_CONFIG_0             SENDMAIL_TYPE   no

# Tastendruck für Skripte (Konsole 9)
# nicht notwendig
END_STARTUP             0
# END_STARTUP           1

RC_CONFIG_0             START_GPM       no
RC_CONFIG_0             MODEM
RC_CONFIG_0             MOUSE          /dev/psaux

# RC_CONFIG_0          START_LOOPBACK yes
# RC_CONFIG_0           FQHOSTNAME      pc20.saxedu.de
# RC_CONFIG_0           SEARCHLIST      saxedu.de
# RC_CONFIG_0           NAMESERVER      192.168.42.100
# RC_CONFIG_0           SMTP            no

# Setzen von rc.config-Parameter zur Konfiguration des Systems.
### some system setup #
### RC_CONFIG_0         GMT -u
### RC_CONFIG_0         START_INEtd no
### RC_CONFIG_0         START_SSHD yes
### RC_CONFIG_0         START_GPM yes
### RC_CONFIG_0         START_ROUTED no
### RC_CONFIG_0         START_NAMED no
### RC_CONFIG_0         ROOT_LOGIN_REMOTE no
### RC_CONFIG_0         MODEM
### RC_CONFIG_0         FH_ADVANCED_CONFIG yes
###
### RC_CONFIG_0         DISPLAYMANAGER    kdm
### RC_CONFIG_0         CONSOLE_SHUtdOWN   halt
### RC_CONFIG_0         KDM_SHUtdOWN       all

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)
Korrekturen, Hinweise?
Startseite Nächste Seite Nächstes Kapitel Vorherige Seite Kapitelanfang