© Kittipong Jirasukhanont, 123RF

Heute entscheidet oft der Grad der Automation eines Setups über dessen Erfolg oder Misserfolg. FAI unterstützt den Admin dabei, Server automatisiert mit einem Betriebssystem auszustatten.

Wer nicht mit der Zeit geht, muss mit der Zeit gehen. Dieser Kalauer gilt in der IT besonders im Hinblick auf Automation. Denn wenn Firmen es schaffen, ihr gesamtes Setup so gut wie möglich zu automatisieren, ist das ein maßgeblicher Wettbewerbsvorteil.

Zugleich ist Automation die Grundlage für die Economy of Scale: Bei der geht es ja um Synergieeffekte, die überhaupt erst durch Automation entstehen. Die anfängliche Arbeit, die in die Automation einer Plattform fließt, zahlt sich dann mit jedem neuen Knoten aus, der hinzukommt und nicht stundenlanges Betätscheln durch den Admin erfordert.

Automation umfasst dabei viele Ebenen. Sie beginnt bei der Automation der Infrastruktur und umschließt etwa die automatische Konfiguration von Switches oder das Ausrollen von Diensten und deren Konfiguration, um aus einem Grundsystem einen funktionierenden Knoten zu machen, der etwa in einer Cloud virtuelle Maschinen hostet. Genauso beinhaltet Automation natürlich auch das Betriebssystem. Das händische Ausrollen einer Linux-Distribution – jeder Admin weiß das – ist heute zwar keine komplizierte Aufgabe mehr, aber nach wie vor eine langwierige. Die ist aber auch gut zu automatisieren, Kickstart von Red Hat oder das Preseeding beim Debian Installer legen davon Zeugnis ab.

FAI ist eine separate Software, die mit dem Versprechen antritt, in kürzester Zeit Betriebssysteme aufzuspielen. Dabei ist FAI auch nicht auf eine spezifische Distribution gemünzt, sondern unterstützt sowohl Debian als auch Ubuntu und Centos sowie noch weitere, weniger bekannte Varianten.

Das Rad neu erfinden?

Mancher Leser fragt sich angesichts von FAI möglicherweise, wozu das denn gut sein soll – wo es doch die schon erwähnten spezifischen Mechanismen der Distributionen gibt. Gemischte Umgebungen kommen gar nicht so oft vor – dass man etwa Ubuntu und Red Hat in derselben Umgebung vorfindet, ist eher die Ausnahme. Wer diese Frage stellt, unterliegt jedoch einem Trugschluss. Denn korrekt müsste die Frage lauten, wieso Red Hat, Debian & Co. denn unbedingt ihr eigenes Süppchen kochen mussten, obwohl FAI doch bereits existierte.

FAI ist nämlich bereits 18 Jahre alt und folglich zu einer Zeit entstanden, als die IT beim Thema Automation noch in den Kinderschuhen steckte. Dass man auch mit Werkzeugen wie Puppet, Chef oder Ansible Betriebssysteme automatisiert auf die Festplatte eines Servers bringen kann, ist eine viel jüngere Entwicklung, als viele Admins schätzen.

Puppet etwa erschien erstmals 2005, da hatte FAI bereits sechs Jahre auf dem Buckel. Und 1999, als die Arbeit an FAI begann, hantierte man bei Debian noch mit Boot-Floppies und mit einem Uralt-Installer, bei dem von Preseeding und automatischer Installation noch keine Rede war. Viel eher war froh, wer Debian 2.2 alias Potato oder 3.0 alias Woody überhaupt irgendwie auf die Festplatte brachte. Der Debian Installer, der die Boot-Floppies endlich in den Ruhestand schickte, erschien erst 2005 zusammen mit Debian GNU/Linux Sarge.

Für Thomas Lange (Abbildung 1) wäre das viel zu spät gewesen. Der arbeitete 1999 an der Universität zu Köln, die gerade einen schicken neuen Cluster bestehend aus 16 Servern angeschafft hatte. Der war nun irgendwie zu installieren – die Aufgabe fiel schließlich Thomas Lange zu. Auf die nervige Hantiererei mit Debians Boot-Floppies hatte Lange aber gar keine Lust. Und weil er zuvor lange mit Solaris gearbeitet hatte und dessen Jumpstart kannte, kam ihm die Idee, ein ähnliches Installationssystem auch Linux zu spendieren.

Abbildung 1: Thomas Lange ist das Mastermind hinter FAI und zeichnete 1999 für den Entwicklungsbeginn verantwortlich.

Der Rest ist Geschichte: Der FAI, der Fully Automated Installer, erfreut sich seither einer großen Fangemeinde und Lange wurde über den Umweg FAI sogar offizieller Debian-Entwickler – bis heute pflegt er die Pakete in Debian, die für FAI benötigt werden.

Wie FAI funktioniert

Der Artikel stellt FAI ganz praktisch vor und erklärt, wie das Programm funktioniert und an welchen Stellschrauben der Admin bei Bedarf dreht. Um Verständnis für das große Ganze zu schaffen, geht dem aber der Blick aus der Vogelperspektive voraus: Welchen Konzepten folgt FAI und wie erledigt es seine Arbeit grundsätzlich? Dass es nicht trivial ist, Hosts automatisiert mit einem Betriebssystem zu versorgen, haben auch die Debian-Entwickler und die Red-Hat-Leute gemerkt, die dort an den heute gebräuchlichen Installern arbeiten.

Umso interessanter, dass FAI eine ähnliche Funktionalität bereits vor 20 Jahren und mit den Werkzeugen bot, die damals eben zur Verfügung standen. Wobei ehrlicherweise auch festzustellen ist, dass sich die genutzten Protokolle seither gar nicht so radikal verändert haben – viele gehen ohnehin auf die Anfangszeit des Internets zurück.

Alte Bekannte: DHCP, PXE, TFTP

Startet ein Server kalt oder nach einem Neustart, gibt es mehrere Optionen, wie er an ein lauffähiges Betriebssystem kommt. Die erste und übliche Option ist das Starten von einem lokalen Speichermedium – meist handelt es sich um die so genannte Systemfestplatte. Die enthält das reguläre Betriebssystem. Hat der Server mit dieser Platte erst einmal begonnen, geschieht der Rest des Bootvorgangs automatisch.

Kommt er aber frisch aus dem Karton, hat er in der Regel noch kein Betriebssystem. Der Admin kann nun mit einem temporären lokalen Bootmedium – etwa einem USB-Stick – dieses händisch installieren. Aber das ist ja gerade das, was er sich nicht wünscht. Oder er setzt auf einen anderen Weg, um das System zu installieren: das Booten via Netzwerk. Ein Start von Netzwerkmedien ist keine neue Erfindung. Es spielen drei Protokolle zusammen, die zu den Urgesteinen des Internets gehören: DHCP versorgt einen Server mit einer IP-Adresse, damit er TCP/IP und UDP sprechen kann.

Per TFTP lädt das System sich anschließend einen Bootloader herunter und bootet ihn. Ab jetzt ist theoretisch alles möglich, was beim Booten von einem lokalen Medium auch machbar wäre. Es ist zum Beispiel kein Problem, das eigene Root-Dateisystem auf einem Server im Netz liegen zu haben und das System ohne lokales Bootmedium zu betreiben – im so genannten Diskless-Mode.

Das Gespann aus DHCP und TFTP heißt, wenn es – wie im Artikel beschrieben – zum Einsatz kommt, übrigens “Preboot Execution Environment”, abgekürzt PXE. Will ein System per PXE starten, muss mindestens eine verbaute Netzwerkkarte PXE unterstützen. Im Serverumfeld ist das aber kein Problem mehr, hier finden sich Server ohne PXE-fähige Netzwerkkarten so gut wie gar nicht mehr.

Auch bei Endanwender-Systemen fehlt PXE meist nur, wenn man zu den allergünstigsten Komponenten greift. Mittlerweile ist sogar flächendeckender Support für UEFI per PXE gegeben, sodass entsprechende Systeme sich auch auf UEFI-Basis nach Maßgabe des Bios-Nachfolgers booten lassen.

FAI: Netz ist Standard

Die Fähigkeit, vom Netzwerk zu starten, macht sich auch FAI zunutze. Der Bootvorgang per PXE ist hier fester Programmbestandteil, auch wenn er sich mittlerweile umgehen lässt – dazu später mehr. Um FAI zu nutzen, obliegt es dem Admin deshalb zunächst, einen Host zum FAI-Master zu ernennen und auf diesem einen DHCP-Server und einen TFTP-Server zu betreiben.

Wer schon einen oder beide Dienste in seinem Netzwerk hat, kann diese recyceln – es ist aber darauf zu achten, dass sich die FAI-Konfiguration und möglicherweise bestehende Infrastruktur nicht auf die Füße treten.

Aus Gründen der Einfachheit geht dieser Artikel im Folgenden davon aus, dass FAI auf einem einzelnen Server zum Einsatz kommt, auf dem es für PXE samt DHCP und TFTP selbst verantwortlich ist. Das Grundsystem besteht aus Debian GNU/Linux, das Paket »fai-quickstart« aus dem FAI-Verzeichnis ist installiert. Wo der Admin besondere Vorkehrungen treffen muss, falls FAI sich nicht exklusiv um den DHCP-Server kümmert, weist der Artikel darauf gesondert hin.

Wichtig: Im Idealfall definiert der Admin zumindest ein Deployment-Netz ohne VLAN-Tag, in dem alle betroffenen Netzwerkports automatisch Mitglied sind. Denn das Booten von VLAN-getaggten Interfaces unterstützen die meisten Netzwerkkarten eben nicht. Selbst Intels Chips benötigen hierfür eine spezielle Firmware, die der Hersteller nur auf Anfrage überhaupt herausrückt.

Das ist aber kein Problem: Nach der Installation des Betriebssystems muss dieses ja ohnehin noch konfiguriert werden, eventuelle VLAN-Tags lassen sich bei der Gelegenheit einrichten. Das System installiert sein Betriebssystem also in einem ungetaggten Netz und hat schon beim ersten Boot ins finale Betriebssystem die passende Konfiguration der Netzwerkschnittstellen zur Hand.

Die FAI-Konfiguration

PXE sieht DHCP und TFTP für große Aufgaben vor. Der Fokus liegt hier einzig und allein darauf, dem System einen Bootloader zu vermitteln, alle anderen benötigten Dateien muss dieser sich im Anschluss aus einer anderen Quelle ziehen. Hat der Admin das im Hinterkopf, erschließt sich das grundlegende Design hinter FAI sehr schnell.

Denn auf dem FAI-Master müssen mehr Dienste als nur DHCP und TFTP aktiv sein. Ebenso braucht er in der Standardkonfiguration einen NFS-Server. Der stellt verschiedene von FAI benötigte Konfigurationsdateien bereit, etwa die Konfiguration der FAI-Klassen, auf die der Artikel später noch im Detail eingeht.

NFS ist bei Admins möglicherweise nicht das beliebteste Protokoll und heute würden sie möglicherweise auf andere Protokolle setzen – weil der größte Teil der Arbeit der Clients in lesendem Zugriff besteht, ist das am Ende aber ohnehin kaum noch relevant. Denn der lesende parallele Zugriff auf NFS ist deutlich weniger problematisch als der schreibende Zugriff. Und das schon aus einem ganz einfachen Grund – das Thema Locking fällt dabei komplett weg.

Ist der NFS-Master dann installiert und ausgerollt, kommt ihm eine wichtige Aufgabe zu: Er hostet die FAI-Konfigurationsdateien, also jene Dateien, aus denen FAI seine Arbeitsanweisungen bezieht. Hier liegen zum Beispiel auch die Basefiles, die FAI benötigt, um ein Betriebssystem zu installieren.

Schritt für Schritt: Was passiert wann?

Um sich die FAI-Funktionen zu vergegenwärtigen, ist es sinnvoll, sich die einzelnen Arbeitsschritte vor Augen zu führen. Sobald ein Server per PXE in eine Netzwerk-Bootumgebung startet, bekommt er vom DHCP-Server zunächst eine IP-Adresse und dann per »next«-Eintrag auch noch die Information, auf welchem Server er per TFTP nach Dateien suchen kann.

Dabei ist wichtig, dass je nach genutzter Bootloader-Art – Bios oder UEFI – der Client nach bestimmten Dateien auf dem TFTP-Server sucht, die MAC-spezifisch sind. Im Namen der Datei ist also die MAC-Adresse der Netzwerkkarte, die die Anfrage stellt, enthalten. Der PXE-Standard sieht das ausdrücklich vor.

Doch ganz korrekt ist die vorangegangene Darstellung nicht. Denn die MAC-Adresse der anfragenden Netzwerkkarte spielt in FAI noch eine zweite und viel wichtigere Rolle: Sie entscheidet letztlich darüber, ob ein Server auf seine DHCP-Frage überhaupt eine Antwort bekommt. Der Admin kann ja auch ein Interesse daran haben, einen Server in eine PXE-Umgebung zu schicken, ohne ihm per FAI gleich ein neues Betriebssystem überzubügeln. Daher kümmert sich FAI ab Werk nur um jene Server, die der Admin ausdrücklich per CLI in die Datenbank des DHCP-Servers übernommen hat.

Dem Standard-DHCP-Server in FAI fehlt also die Catch-all-Regel, die sich in DHCP-Konfigurationen ansonsten üblicherweise findet. Der Befehl

dhcp-edit demohost 01:02:03:AB:CD:EF

demonstriert beispielhaft, wie sich ein Host für die Nutzung im FAI-DHCP aktivieren lässt.

Ist die DHCP-Konfiguration gesichert, folgt ein weiterer wichtiger Schritt: Der Admin hinterlegt auf dem TFTP-Server einen MAC-spezifischen Bootloader, damit der Client diesen beim Request findet und nicht ins Leere greift. Der Befehl dafür ist nicht kompliziert:

fai-chboot -IFv -u nfs://faiserver/srv/fai/config demohost

Er setzt aber voraus, dass er auf demselben Host aufgerufen wird, auf dem auch die DHCP-Konfiguration lagert, denn über diese holt sich »fai-chboot« die MAC-Adresse von »demohost«.

Boot in ein Mini-System

Sobald die passende PXE-Konfiguration hinterlegt ist, bekommt der Client beim Netzwerkboot einen Bootloader untergeschoben – das allseits bekannte Pxelinux. Das wiederum lädt dann einen ganz klassischen Linux-Kernel samt Ramdisk. Es handelt sich um ein auf Debian GNU/Linux basierendes System, das eigentlich nur eine Aufgabe hat: Die Installation eines lokalen Linux zu ermöglichen – falls der Admin beim Bootvorgang nicht doch noch den »rescue«-Parameter angibt. Denn dann bootet FAI in dasselbe Mini-Linux, es startet aber nicht automatisch die Routine zur Installation eines Systems (Abbildung 2).

Abbildung 2: FAI startet in ein Pxelinux, das in der Standardkonfiguration im Anschluss an einen Time-out automatisch in den Installer startet.

Den Configuration Space verstehen

Läuft die oben beschriebene Installationsroutine erstmal, ist es aus der Sicht des Admin sehr wichtig, die Struktur des Configuration Space auf dem zuvor geschaffenen NFS-Server zu verstehen. Hier finden sich diverse Ordner wie »classes«, »disk_config«, »basefiles«, »scripts« und viele weitere. All jene Verzeichnisse haben im Rahmen der FAI-Abläufe eine spezielle Rolle. Zu den wichtigsten gehört der »classes«-Ordner, denn auf Grundlage der Klassen weist FAI Servern Kategorien zu und versorgt sie mit einem vorher definierten Software-Mix.

Zur Erinnerung: In jenem Augenblick, in dem ein Server in den Bootloader von Pxelinux bootet, hat FAI über ihn noch keine andere Information als die MAC-Adresse, über die er den DHCP-Request abgeschickt hat. Das allein ist meist aber zu wenig, um FAI eine Entscheidung darüber zu erlauben, welches Betriebssystem der künftige Host haben soll, welche von der Standardinstallation abweichenden Pakete zu installieren sind und ob – und falls ja welche – Skripte nach der Installation laufen sollen.

FAI behilft sich, indem es Server in Klassen einteilt und für die einzelnen Klassen die Parameter wie Betriebssystem oder Paketauswahl definiert. Die Entscheidung darüber, zu welcher Klasse ein Server gehört, fällt auf Basis mehrerer Parameter. Ein Parameter kann etwa der Hostname sein – das ist aber nicht sehr flexibel. Ab Werk gehören Server ohnehin mehreren Standardklassen an, etwa »DEFAULT« und »LAST«. Wirklich flexibel ist die Klassenzuweisung dort, wo sie über den Aufruf von Skripten passiert.

Das geht so: Während des Installationsvorgangs lassen sich über Hooks zu bestimmten Zeitpunkten externe Shellskripte aufrufen. Die legt der Admin im NFS-Verzeichnis im Ordner »scripts« ab, und zwar so, dass sie aufrufbar sind. Ihre Ausgabe interpretiert der FAI-Installer dann als Klassen, zu denen die jeweiligen Hosts gehören. Findet sich im »classes«-Ordner eine passende Klassendefinition, wendet der FAI-Installer die darin festgelegten Parameter auf das jeweilige System an.

Was theoretisch ziemlich kompliziert klingt, ist in der Praxis aber simpel, wie ein einfaches Beispiel verdeutlicht. Angenommen FAI käme auf Workstations und Servern eines Unternehmens zum Einsatz. Im konkreten Fall startet FAI auf einem Desktop-System – der FAI-Installer weiß das aber noch nicht, eben weil er bisher nur die MAC des Systems kennt.

Im ersten Schritt des Prozesses ruft der FAI-Installer deshalb ein Skript auf, das die Hardware des Hosts einliest und inventarisiert. Dabei stell sich heraus, dass im jeweiligem System eine fette Grafikkarte mit 3-D-Chipsatz verbaut ist. Die findet sich naturgemäß in Servern eher selten, sodass es sich wohl um einen Desktop handelt.

Das Skript zur Inventarisierung gibt deshalb »KDEHOST« aus, und FAI weiß, dass das System zur Klasse »KDEHOST« gehört. In der Definition jener »KDEHOST«-Klasse ist zu lesen, dass neben der Basis-Installation auch das komplette KDE 5 nebst den für die Nvidia-Grafikkarte benötigten proprietären Treibern zu installieren ist. Auf Servern mit weniger starker Grafikkarte könnte der Host automatisch in der Klasse »XFCE« landen, die auch zu einem grafischen Desktop führt, aber zu einem weniger Ressourcen-intensiven GUI als KDE.

Ähnliche Stunts sind selbst in Kombination mit neuester Technik denkbar: Merkt FAI etwa, dass ein System Dutzende große Festplatten hat, könnte es als Klassendefinition »CEPH« ausgeben. In der dazugehörenden CEPH-Klasse wäre dann vermutlich hinterlegt, dass die für Ceph benötigten Pakete automatisch den Weg auf das System finden und grundsätzlich konfiguriert werden.

Klar ist: Das Klassensystem in FAI ist mächtig und trägt einen großen Teil dazu bei, dass die Lösung so flexibel und dynamisch ist. Es sorgt zum Beispiel auch dafür, dass ein Host eine passende Festplattenkonfiguration bekommt: Über Dateien, deren Syntax der von »/etc/fstab« sehr ähnelt, definiert der Admin das Layout, das die Platten im Zielsystem haben sollen (Abbildung 3).

Abbildung 3: Die Festplattenkonfiguration eines Systems definiert sich über die Klasse, zu der es gehört.

Noch mehr Skripte

Zwischen Klassen und Skripten entsteht übrigens eine äußerst hilfreiche Wechselwirkung. Denn steht auf Basis der Ausgabe der Klassen-Skripte erstmal fest, dass ein Host zu einer bestimmten Klasse gehört, lassen sich für sie weitere Skripte definieren, die zu bestimmten Vorgängen während des Setups aufzurufen sind. Für Admins bedeutet das nicht weniger als die Option, in das Setup und seine zentralen Prozesse zu quasi jedem Zeitpunkt nach Belieben einzugreifen.

Die FAI-Dokumentation [1] listet die möglichen Hooks sowie die Zeitpunkte auf, zu denen diese jeweils greifen. Und falls der Admin bei der Lektüre jener Dokumentation über den Begriff “Plan” stolpert: Darunter versteht FAI gewissermaßen die Gesamtheit aller vorgenommenen Einstellungen, die so im Installationsplan landen.

Basefiles für verschiedene Distributionen

Eine der eher schrägen Eigenheiten von FAI besteht in der Verwendung der so genannten Basefiles für die Installation verschiedener Distributionen. Der Artikel hat schon erwähnt, dass FAI eben nicht nur für Debian und Ubuntu zur Verfügung steht, sondern dass sich auch Centos und potenziell jedes andere Betriebssystem damit installieren lassen soll – solange es auf Linux basiert.

Eben weil das so ist, verbietet es sich allerdings von selbst, auf die von den Distributionen angebotenen Installationsmechanismen zu setzen. In Debian wäre das zwar per »debconf« und »cdebconf« noch möglich, doch andere Distributionen haben schlicht kein separates Werkzeug, das sich um das System und dessen Basis-Installation kümmern könnte.

Die FAI-Entwickler beschreiten deshalb einen besonderen Weg: Sie liefern zusammen mit FAI Basefiles für diverse Distributionen aus. Die enthalten ein möglichst reduziertes Basis-System, das der FAI-Installer dann einfach auf die Platte kopiert.

Praktisch aus Admin-Sicht ist dabei auch, dass die FAI-Entwickler sich regelmäßig um die Wartung dieser Basefiles kümmern. Allerdings geht dafür viel Zeit drauf – wer sich also berufen fühlt, den Entwicklern bei dieser Mammutaufgabe unter die Arme zu greifen, stößt sicher nicht auf taube Ohren (Abbildung 4).

Abbildung 4: Basefiles für Distributionen pflegen die Leute von FAI selbst.

Ganz verheimlichen kann FAI seine Vorlieben übrigens doch nicht, denn zumindest ein streng Debian-spezifisches Feature hat seinen Weg in FAI gefunden. Das Preseeding von »debconf« bietet die Möglichkeit, über das Debconf-System – Debians systemweites Framework zur Festlegung von Konfigurationsparametern bei Paketen – viele Einstellungen automatisiert vorzunehmen. Der Admin hinterlegt dazu für eine Klasse einfach eine Debconf-Konfiguration. Installiert FAI danach Pakete auf dem jeweiligen System, erben sie automatisch alle Debconf-Einträge.

Logs sichern

Ein zentraler Faktor bei der Installation von Systemen ist die Sicherung der Logdateien, die im Rahmen dieses Vorgangs entstehen. Die gute Nachricht ist, dass den FAI-Entwicklern das durchaus klar ist. Ganz am Ende eines von FAI initiierten Installationsvorgangs kopiert FAI nämlich die zehn zentralen Logdateien des Mini-Debiansystems auf den FAI-Server, sodass sie dort für den Admin später zur Ansicht bereitliegen.

Dieselbe Funktion existiert auch, wenn der Admin FAI nutzt, um seine Systeme zentralisiert zu aktualisieren: In den Logs findet sich dann die durch diesen Arbeitsschritt produzierte Ausgabe. Die Power von FAI bei zentralisierten Updates sollte der Admin dabei nicht unterschätzen, mehrere Tests haben in der Vergangenheit gezeigt, dass das Grund-Update per FAI mit seinen Basefiles vergleichbar gut funktioniert wie ein Update über die Paketmanager.

Übrigens: In Umgebungen, in denen PXE fehlt, muss der Admin nicht zwangsläufig auf FAI verzichten. Denn »fai-mirror« erlaubt es, eine ISO-Datei auf Basis eines lokalen Setups zu erstellen, die sich danach auf eine CD-ROM oder einen USB-Stick bannen lässt und dann in den Servern als lokales Bootmedium fungiert. So umgeht der Admin den gesamten Zirkus rund um DHCP & Co., wenn auch um den Preis, dass er die Konfiguration auf dem NFS-Server nicht mal eben schnell anpassen kann.

Fazit

Obwohl FAI bereits einige Lenze auf dem Buckel hat, zeigt sich das Tool auf der Höhe der Zeit. Wer schnell und unkompliziert viele Server ausrollen möchte, findet in FAI dafür einen verlässlichen Partner. Wollte man zunächst eine funktionierende Preseeding-Konfiguration für Debian und dann ein laufendes Kickstart-Environment für Centos bauen, wäre das deutlich aufwändiger als der vergleichbare Aufwand in FAI.

Der größte Unterschied zwischen den Systemen wären wohl noch die Namen der Pakete, die auf den Listen mit Zusatzpaketen zu finden wären (Abbildung 5). Deshalb gilt: FAI ist vielleicht ein Oldie, aber definitiv auch ein Goldie.

Abbildung 5: Die Paketauswahl ist noch das Individuellste bei den einzelnen Distributionen – der Rest ist großflächig recycelbar.