Unbeaufsichtigte RHEL-Installation mit einer Kickstart-Datei aufbauen

Ziel

Eine Kickstart-Datei schreiben, die RHEL (oder einen Rebuild) ohne interaktive Eingaben installiert, Syntaxfehler erkennen, bevor irgendetwas gebootet wird, und verhindern, dass über die Datei selbst Zugangsdaten preisgegeben werden.

Voraussetzungen

Eine Möglichkeit, die Datei dem Installer bereitzustellen (HTTP(S) oder eingebettet im Installationsmedium), und eine Boot-Methode, die ein Kernel-Argument übergeben kann (PXE, das Boot-Menü eines ISO-Images oder ein Argument von virt-install).

Schritte

1. Die Datei aus einzeiligen Befehlen (lang, keyboard, timezone, network, Partitionierung, rootpw) und einem %packages-Abschnitt aufbauen, der Gruppen und Paketnamen auflistet und mit %end abgeschlossen wird. Wo Logik nötig ist, Skriptabschnitte ergänzen: %pre läuft vor der Installation (zum Beispiel, um aus den erkannten Datenträgern ein Partitionslayout zu berechnen), %post läuft nach der Basisinstallation im Root-Verzeichnis des neuen Systems und dient der Konfiguration.
2. Die Datei vor jeder Verwendung validieren, ohne etwas zu booten:

ksvalidator /path/to/ks.cfg

ksvalidator meldet unbekannte oder veraltete Befehle, kann aber nicht prüfen, ob ein referenziertes Repository oder Paket tatsächlich existiert. 3. Die Datei bereitstellen und beim Booten übergeben. inst.ks= ist die eigene Boot-Option von Anaconda, um auf eine Kickstart-Quelle zu verweisen:

inst.ks=http://server/ks.cfg

Diese Option wird bei PXE/grub an die Kernel-Kommandozeile angehängt oder als zusätzliches Boot-Argument an virt-install übergeben. 4. Geheimnisse aus der Datei heraushalten. Eine Kickstart-Datei, die für PXE über unverschlüsseltes HTTP ausgeliefert wird, ist typischerweise nicht authentifiziert, und Kopien verbleiben auf dem fertigen Host (/root/anaconda-ks.cfg und bei aktuellen Releases zusätzlich die unveränderte /root/original-ks.cfg). Deshalb nie ein gültiges Root-Passwort, einen Activation Key oder ein Join-Token direkt in rootpw oder in eine %post-Zeile schreiben. Stattdessen rootpw --lock verwenden (Zugriff nur per SSH-Schlüssel) und jedes echte Geheimnis in %post aus einer Quelle zur Laufzeit abrufen, statt es einzubetten. 5. Die gesamte Datei in einer Wegwerf-VM testen, bevor sie auf echte Hardware angewendet wird.

Erwartetes Ergebnis

Der Installer läuft ohne Eingabeaufforderungen vom Anfang bis zum Ende durch; ksvalidator beendet sich mit Exit-Code 0; weder /root/anaconda-ks.cfg noch /root/original-ks.cfg auf dem fertigen Host enthält gültige Zugangsdaten.

Grenzen und Prüfbasis

ksvalidator prüft die Kickstart-Syntax, nicht die Korrektheit des %post-Skripts und auch nicht die Paketverfügbarkeit auf dem Zielsystem. Ein Probelauf in einer VM ist der einzige echte Test. Kickstart-Befehle werden zwischen Releases gelegentlich als veraltet markiert; eine für ein älteres Release geschriebene Datei daher erneut mit ksvalidator prüfen, bevor sie auf einem neueren Release wiederverwendet wird.