# Advanced Kickstart: Dynamische Installationen auf Experten-Niveau

TL;DR / Management Summary Während ein statisches Kickstart-File (siehe Artikel 062) für homogene VM-Flotten reicht, benötigt man für heterogene Hardware (verschiedene Disk-Anzahlen, unterschiedliche NIC-Namen) dynamische Kickstarts. In diesem Modul nutzen wir die %pre Sektion, um Hardware-Checks durchzuführen, Konfigurations-Schnipsel in /tmp/ zu schreiben und diese via %include in den Installationsprozess einzubinden.

# 1. Einführung & Konzepte

Logik vor der Installation.

Der Anaconda-Installer führt das %pre Skript aus, noch bevor er das Dateisystem anfasst. Dies ist der Moment, um Entscheidungen zu treffen.

# Der Dynamische Fluss (Mermaid)

graph TD
    A[Start Anaconda] --> B[Execute %pre Script]
B --> C{Check Hardware}
C -->|NVMe found| D[Write 'ignoredisk' to /tmp/disk.cfg]
C -->|HDD found| E[Write 'ignoredisk' to /tmp/disk.cfg]
B --> F[Finish %pre]
F --> G[Read %include /tmp/disk.cfg]
G --> H[Partitioning with selected Disk]

# 2. Die Macht von %include

Konfigurationen modular aufbauen.

Anstatt alles in ein File zu pressen, laden wir Teile nach Bedarf nach.

# Beispiel: Dynamische Partitionierung

# In der Command Section (oben)
%include /tmp/part-include

%pre
# Suche nach der kleinsten Disk für das OS
DEV=$(lsblk -nd -o NAME,SIZE | sort -k2 -n | head -n1 | awk '{print $1}')

cat <<EOF > /tmp/part-include
ignoredisk --only-use=$DEV
clearpart --all --initlabel --drives=$DEV
autopart --type=lvm
EOF
%end

# 3. Kernel-Parameter und iPXE Integration

Flexible Übergabe von Daten.

Sie können dem Installer über den Boot-Prompt Parameter mitgeben, die Sie im Kickstart-Skript auslesen.

# Parameter übergeben (iPXE)

kernel http://mirror/vmlinuz inst.ks=http://cfg/ks.cfg my_role=database my_env=prod

# Parameter im Skript auslesen

%pre
ROLE=$(cat /proc/cmdline | tr ' ' '\n' | grep '^my_role=' | cut -d= -f2)
echo "Role detected: $ROLE" > /dev/console

if [ "$ROLE" == "database" ]; then
    echo "installing mysql-server" > /tmp/extra-packages
fi
%end

%packages
%include /tmp/extra-packages
%end

# 4. Day-2 Operations: Post-Install Hardening

Das System fertigstellen.

Nutzen Sie die %post Sektion, um den Server sofort in Ihr Management-System aufzunehmen.

%post --log=/root/ks-post.log
# 1. SSH-Keys vom Deployment-Server laden
mkdir -p /root/.ssh
curl -s http://10.0.0.1/pub_keys >> /root/.ssh/authorized_keys

# 2. Ansible-Agent / Salt-Minion installieren
dnf install -y ansible-core
%end

# 5. Troubleshooting & “War Stories”

Debugging im Pre-Install.

# Story 1: “Der unsichtbare Output”

Symptom: Das %pre Skript schlägt fehl, aber man sieht keine Fehlermeldung. Ursache: Standardmäßig werden Fehlermeldungen in %pre nicht auf die Konsole ausgegeben. Lösung: Leiten Sie den Output explizit um: exec < /dev/console > /dev/console 2>&1.

# Story 2: “NIC Naming Chaos”

Symptom: Auf manchen Servern heißt die Karte eth0, auf anderen eno1 oder enp3s0. Das statische network Kommando im Kickstart schlägt fehl. Ursache: Predictable Network Interface Names. Lösung: Nutzen Sie --device=link (nimmt das erste Interface mit Link) oder identifizieren Sie die Karte im %pre via MAC-Adresse.

# 6. Fazit & Empfehlung

• Modularität: Bauen Sie eine Basis-Kickstart-Datei und inkludieren Sie Rollen-spezifische Teile via %include.
• Logging: Nutzen Sie immer --log= in Skript-Sektionen. Ohne Log ist die Fehlersuche nach einem gescheiterten Deployment unmöglich.
• Wahl: Nutzen Sie dynamische Kickstarts nur, wenn Sie eine hohe Varianz in der Hardware haben. Für Cloud-VMs sind feste ISOs/Images effizienter.

# Anhang: Cheatsheet