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...
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.
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.
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) ... ... |
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 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 |
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:
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.
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 |
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 |
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
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 |
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 |
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 |
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.
Nach Abschluss werden die Protokolldateien des Installationsvorgangs nach /var/log/fai/$HOSTNAME/install/ geschrieben und der Rechner neu gebootet.
Genau genommen sind drei Handlungen von Nöten:
Die im Verborgenen ablaufenden Vorgänge sind dann doch um Einiges komplexer:
| 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.
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:
durchzuführen sind.
Alternative Quellen für die Pakete sind lokale CDROMs, lokale Festplatten oder eine Webseite (URL).
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:
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 |
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 |
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...
Die Schritte, die der Client ab dem Booten von der Diskette durchläuft, sind:
| SuSE |
|
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:
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.
Die Schritte, die der Client ab dem Booten von der Diskette durchläuft, sind: