Wie viele Administratoren braucht man, um 150 Client-PCs an einem Vormittag auszurollen? Die ehrliche Antwort für den Mittelstand: Zu viele! Wer mit USB-Stick von Rechner zu Rechner läuft, arbeitet grundlegend falsch und ineffizient. Es fehlen klare Konzepte, Monitoring, Automatisierung und Skalierung. In genau dieser Reihenfolge.

Ohne Automatisierung wird Skalierung zur Personalkosten-Explosion. Ohne Monitoring wird Automatisierung zum Brandbeschleuniger. Ohne klare Konzepte misst jedes Monitoring im sprichwörtlichen Sinne Mist.

In die gleiche Richtung weist auch das zeitlos gültige Zitat aus dem Vortrag von Kristian Köhntopp mit dem Titel “Go away, or I will replace you with a very small shell script”:¹

Wenn ein Admin auf einem Rechner “rumturnt”, um was nachzusehen, dann stimmt etwas mit dem Monitoring nicht. Wenn ein Admin auf einem Rechner “rumturnt”, um was einzustellen, dann stimmt etwas mit der Automatisierung nicht.

Dieser Beitrag thematisiert den Massenrollout von Clients mit PXE/FAI, erwartungsgemäß für Debian GNU/Linux. Die erzielten Zeit- und Skalierungseffekte sind jedoch kein isoliertes Technikthema, sondern Ausdruck von organisatorischer Reife.

Wie in allen meinen Beiträgen gilt: Your mileage may vary. Ich erhebe keinen Anspruch auf Vollständigkeit oder Allgemeingültigkeit. Wichtige technische Aspekte können nur grob angerissen werden. Neben FAI existiert mit Preseed eine weitere Deploymentmöglichkeit,² die hier nicht Thema ist. Und bevor der Einwand aus dem Windows-Lager kommt: Ja auch für Windows existieren Deployment-Werkzeuge. Doch sind diese meist Image-basiert, kaum in moderne GitOps-Prozesse integrierbar und mit zusätzlicher Infrastruktur- und Lizenzkomplexität verbunden.

Teil I: Scope und Voraussetzungen

Das technische Setup hat einige Grundannahmen und Voraussetzungen.

Eigenes Rollout-VLAN

Zunächst gehe ich von einem in VLANs segmentierten Netzwerk aus.³ Das ist keine Empfehlung, es ist Stand der Technik. Drucker, Webcams, Produktiv- und Testsysteme müssen netzwerktechnisch voneinander isoliert betrieben, Zugriffe sowie Routing an den Gateways gelenkt werden.⁴

Ein Fully Automatic Installation Server,⁵ kurz FAI genannt, gehört folglich mit seinen neuen, meist noch unbekannten Client-PCs in ein eigenes Rollout-VLAN. Das verhindert unerwünschte PXE-Boots im späteren Produktionsbetrieb und bietet zudem Raum zum ausgiebigen Testen vor einem Rollout-Termin.

Bestehende (und konfigurierbare) DHCP- und DNS-Server

Zusätzlich gehe ich von einem bereits bestehenden DHCP-Server im Rollout-VLAN aus. Das erspart einem das Setzen von Ausnahmen im DHCP-Snooping des Switch-Managements.⁶ Zu meinem Erstaunen sind nicht in allen vermeintlich professionellen Firewallsystemen DHCP-Optionen einstellbar:⁷

• DHCP Option 66 next-server
• DHCP Option 67 filename

Gleiches versteht sich auch für das DNS. Damit der spätere Aufruf von z.B. http://fai.internal von den Client-PCs aus funktioniert, muss DNS per DHCP-Option 6 und 15 propagiert werden.

64-Bit Debian und EFI-Boot only

Ein aktuelles 64-Bit-UEFI-Boot mit Debian Stable wird als Standard definiert, um die Legacy-Ausnahmen gering und die Komplexität für unser Setup niedrig zu halten. Das gilt ebenfalls für das verwendete Disk-Layout: GPT, EFI-Systempartition und eine ext4-Partition für alles.

Damit lassen sich alle PCs der vergangenen 10-15 Jahre berücksichtigen. Ausnahmen bestätigen die Regel.

Transportprotokolle und TLS

Wie später in der Bootkette dargestellt, kommen mehrere Übertragungsprotokolle zum Einsatz. Eine Kombination aus TFTP, HTTP und NFS,⁸ die sich aus der üblichen PXE-/FAI-Architektur ergibt. Die Vorteile liegen in höheren Geschwindigkeiten und geringerer Netz- und Serverlast bei vielen gleichzeitigen Verbindungen.

Auf TLS verzichte ich bei dem Rollout aus zwei bewussten Risikoabwägungen. Zum einen befinden wir uns in einem internen, von uns kontrollierten und vom Rest isolierten VLAN. Zum anderen reduziert die unverschlüsselte Bereitstellung Komplexität und Overhead. Sollte sich am Sicherheitskontext etwas ändern, können TLS und eigene Certs immer noch integriert werden.

Das Postinstall-Skript

Was passiert nach einem vollautomatischen Rollout eines Systems? Vereinfacht gesagt beginnt ein Client seinen Lebenszyklus im Rollout-Segment und wechselt nach erfolgreichem Abschluss in ein Produktionssegment.

Das Postinstall-Skript ist elementar für die weitere Anpassung von Paketen, der Konfiguration des Remotezugriffs mit SSH-Public-Keys⁹ und zur Vorbereitung der Übernahme durch Automatisierungstools wie Ansible.

Die ganze Magie wird deutlich, sobald über REST-APIs Registrierungen in Monitoring-, Asset- und Ticket-Managementsystemen erfolgen.

Teil II: Der FAI-Server

Betrachten wir nun den zentralen Baustein unseres Setups, den FAI-Server. Typischerweise wird dieser als VM innerhalb einer Proxmox-Virtualisierung eingerichtet. Die Hardware-Anforderungen sind erfreulich minimal:

• 2-4 vCPUs
• 2-4 GB RAM
• 30 GB Storage für typische Debian-Rollouts
• LAN-Interface im Rollout-VLAN

Basis bildet ein Debian Stable. Die zusätzlich benötigten Pakete befinden sich im Standard-Repository:

• Apache¹⁰ (+ optional PHP)
• TFTP-Server¹¹
• iPXE¹²
• FAI-Server¹³

# apt install -y fai-server fai-setup-storage apache2 php-fpm tftpd-hpa ipxe

Im Anschluss wird fai-install zur Vorbereitung des Servers ausgeführt. Prinzipiell kann der FAI-Server komplett offline betrieben werden, sollte vor einem Rollout selbstverständlich auf einem aktuellen Stand sein.

Screenshot Proxmox-Testumgebung bestehend aus einem FAI-Server und einem virtuellen Client

FAI-Konfiguration und Klassenkonzept

Mit der Installation der benötigten Pakete ist ein FAI-Server noch nicht produktiv einsetzbar. Entscheidend ist die weitere verzeichnisbasierte Konfiguration.

Im Zentrum steht das Verzeichnis /srv/fai/config. Hier wird in den verschiedenen Unterverzeichnissen und Klassen der gewünschte Zielzustand beschrieben.

• class/ - Definition von unterschiedlichen (Deployment)-Klassen
• disk_config/ - Partitionierung und Dateisysteme
• package_config/ - zu installierende Client-Pakete
• files/ - Dateien, die direkt ins Zielsystem mitkopiert werden
• scripts/ - Installations- und Postinstall-Skripte

Ein paar erklärende Worte zum FAI-Klassenkonzept. Eine Klasse wird einem Client während des Bootvorgangs zugewiesen. Ein Client kann dabei mehrere Klassen gleichzeitig besitzen. Die resultierende Konfiguration ergibt sich aus der Kombination der zugewiesenen Klassen. Zum Beispiel definiert die Klasse DEFAULT nur ein minimales Grundsystem, welches auf alle Clients unabhängig vom Einsatzzweck zutrifft. Erst mit Mitgliedschaft in der WORKSTATION-Klasse wird ein Client zu einem Arbeitsplatz mit grafischer Oberfläche und den benötigten Anwendungen. Eine andere Klasse wie beispielsweise TERMINAL richtet nur eine minimale grafische Umgebung mit Autologin und Webbrowser im Kiosk-Modus ein.¹⁴

Ein Beispiel Datei für die Klasse DEFAULT in /config/package_config/DEFAULT:

PACKAGES install
ca-certificates
locales
sudo
openssh-server
curl
mc

Das Ergebnis ist ein deterministisch reproduzierbares System, dessen Zustand sich vollständig aus den definierten Klassen ableiten lässt.

Teil III: Vollautomatisierter Rollout

Jetzt wird es operativ. Bei Rollouts von neuen Clients darf ich “Weihnachten” spielen und viele Kisten in hinreichend großen Räumlichkeiten öffnen und die neuen Rechner dort aufstellen. Bei Bestandsystemen ist es einfacher: Hier reicht es, einmal durch das Unternehmen zu gehen und zu hoffen, dass Switch-Management und Netzwerkdokumentation stimmen.

BIOS/UEFI‑Setup vorbereiten

Idealerweise sind Rechner standardisiert, sprich sie kommen vom gleichen Hersteller und Serie und sind bereits werksseitig auf PXE voreingestellt. Das ist leider nicht immer der Fall und so heißt es, einmal “ins BIOS” gehen:

• PXE aktivieren¹⁵
• UEFI aktivieren bzw. Legacy-Boot deaktivieren¹⁶
• ggf. Secure Boot deaktivieren (meine Empfehlung)¹⁷
• ggf. Boot-Reihenfolge anpassen (zuerst immer PXE, dann SSD)

Der einzige manuelle Schritt im gesamten Prozess kann nach entsprechender Einweisung auch von Hilfskräften oder Anwendern selbst vorbereitet werden.

Die Bootkette

Startet ein Client im PXE-Modus, erhält er per DHCP alle notwendigen Informationen zum Netzwerk. Insbesondere den Boot-Server und das zu ladende Netzwerk-Boot-Programm (NBP). Das können zum Beispiel ipxe.efi (UEFI) oder undionly.kpxe (Legacy-BIOS) sein. Je nach Systemarchitektur, Firmware und verwendeter Hardware unterscheiden sich die Details. Das Grundprinzip bleibt jedoch gleich.

Vereinfacht dargestellt läuft die Bootkette wie folgt ab:

1. PXE wird von der Firmware (BIOS/UEFI) initialisiert
2. Über DHCP werden die Boot-Informationen vermittelt
3. Das iPXE Netzwerk-Boot-Programm (NBP) wird via TFTP geladen
4. iPXE startet sein Boot-Skript und lädt Kernel und initrd via HTTP nach
5. Das Root-Filesystem der Installationsumgebung wird via NFS gestellt

Ab hier beginnt die eigentliche Installation des Betriebssystems. Das Ergebnis ist ein einheitlich und reproduzierbar installierter Rechner, der bereit ist, in das produktive Segment verschoben zu werden.

Screenshot eines PXE-bootenden Client-PCs in der Testumgebung

Teil IV: Optimierungen

Ein Rollout von hunderten oder gar tausenden Clients benötigt verständlicherweise mehr Optimierung.

Webserver

Der Webserver wird bei vielen parallelen Downloads zum Engpass, sofern dieser mit den Defaults betrieben wird. Hier helfen Worker- und KeepAlive-Einstellungen erfahrungsgemäß am meisten. In fortgeschrittenen Szenarien kommen Loadbalancing-Proxies hinzu, welche die Last auf mehrere Webserver verteilen.¹⁸

MAC-Adressen sammeln

Für Firewall-Einstellungen werden die meist bei Erstboot noch unbekannten MAC-Adressen der Client-PCs benötigt.¹⁹ Hier hilft ein simples PHP-Skript auf dem FAI-Server, das während des Bootvorgangs die MAC-Adresse durch Aufruf von http://fai.internal/fai/start.php?mac=XXXXXXXX erhält und in eine Textdatei wegschreibt. Wichtig ist, dass der Aufruf nicht als Chain erfolgt.

Rechner inventarisieren und benennen

Hier stehen drei Möglichkeiten zur Auswahl, der Anwendungsfall entscheidet:

1. Gleiches Prinzip wie bei dem Sammeln von MAC-Adressen. Ein PHP-Skript wird aufgerufen und liefert als Ergebnis den Rechnernamen mit einem laufenden Index z.B. PC-005.
   Serverseitig öffnet dabei jeder Aufruf des Skripts zunächst eine Textdatei, liest die dort hinterlegte Zahl der bisherigen Aufrufe ein, inkrementiert diesen Index um 1 und schreibt diese neue Zahl anschließend wieder zurück. Selbstverständlich mit entsprechenden File-Locks bei massenweisen Zugriffen.²⁰

2. Im Postinstall-Skript kann aus Bash via curl mit REST-APIs von Asset- und Managementsystemen wie GLPI,²¹ iTop²² oder Snipe-IT²³ kommuniziert und aus diesen Systemen vergebene Rechnernamen mit hostnamectl gesetzt werden.

3. Wo Ansible-Playbooks bereits zum Einsatz kommen, bietet es sich an, dieses auch zu nutzen. FAI bringt ein System in einen definierten Ausgangszustand. Ansible übernimmt jede weitere Anpassung.²⁴

Versionierung

Selbstverständlich lassen sich FAI-Konfiguration und Skripte in ein Git-Repository überführen und als GitOps-Prozess weiter anpassen und fortentwickeln.²⁵

Ein per PXE gebootetes Minimal System in der Testumgebung

Fazit

Das eigentliche Problem bei Massenrollouts liegt selten in der Technik. Es ist der bestehende Reifegrad der Organisation. Was bringt einem ein vollautomatisches Deployment binnen weniger Minuten, wenn im Nachgang alle Rechner händisch in eine Inventarisierung übertragen werden müssen?

Hier schließt sich der Kreis zu den eingangs genannten Notwendigkeiten klarer Konzepte, Monitoring, Automatisierung und Skalierung. In genau dieser Reihenfolge.

Mit einem vollautomatischen PXE/FAI-Rollout wird die Frage nach “150 Client-PCs an einem Vormittag” nicht zur Heldengeschichte, sondern zu einem planbaren, skalierbaren und vor allem deterministischen Prozess.

Die gute Nachricht: Für diese Reife bedarf es keiner großer Budgets. Und Admin-Heldengeschichten sind eher Heuristik für Unternehmen mit einem geringen Reifegrad.

In diesem Sinne,
Tomas Jakobs