Im Test: Zentrales PC-Deployment mit Fog

An Software zum Erzeugen und Wiedereinspielen einer ganzen Festplatte oder einzelner Partitionen herrscht eigentlich kein Mangel: von Norton Ghost [1] über True Image [2] bis zu Clonzilla [3], Partimage [4] und einige mehr. Auch die freie Linux-Software Fog [5] zieht Abbilder über das Netz und verteilt sie an andere Systeme. Es handelt sich also um kein klassisches Backup-, sondern um ein Deployment-Tool. Denn das System besitzt einige praktische Funktionen wie das automatische Anlegen von Benutzern oder das Anmelden eines Host im Active Directory nach Neuinstallation. Es ist eher mit Snap Deploy [6] aus der Windows-Schiene zu vergleichen.

Administratoren, die Verantwortung für viele Clients tragen, versuchen so viel wie möglich zu automatisieren. Windows selbst bietet eine unbeaufsichtigte Installation, ähnlich zu Kickstart [7] bei Red-Hat-Systemen. Neben der Grundinstallation gehören zu einem System gewöhnlich weitere Software und Treiber. Es bietet sich an, für Gruppen gleichartiger Hosts einen Abzug eines fertig installierten Systems anzulegen und ihn auf die anderen PCs zu verteilen – genau dies tut Fog. Grundlage des folgenden Artikels ist die Version 0.32, also eine neuere als die 0.27, die noch mit der DELUG-DVD im Linux-Magazin 11/2011 unter die Linux-Menschheit kam.

Die Architektur

Die Basis des Systems bildet ein DHCP-Server, der auf PXE-Bootrequests von Clients reagiert und ihnen entweder ein Bootmenü oder gleich einen Netzboot anbietet. Der Fog-Server stellt die Startdaten per TFTP und NFS bereit. Eine LAMP-Kombination und einige selbst geschriebene Tools verwalten das ganze Ensemble. Normalerweise liegen die PC-Images auf den Festplatten des Servers. Reicht der Platz bei vielen Clients nicht aus oder erweist sich der Datendurchsatz als ungenügend, kann Fog auch die Dienste von Storage Nodes in Anspruch nehmen. Die bieten nicht nur den Platz für viele Images, sondern stehen möglicherweise auch netztopologisch näher an den Clients als der Fog-Server.

Die verwalteten PCs sollten das Netzwerk als erste Bootquelle haben, damit Fog sie fernsteuern kann. Ein Fog-Client zeigt nach dem Start das per Syslinux erzeugte Menü in Abbildung 1 an. Der erste Eintrag initiiert das Booten von der lokalen Festplatte, er startet auch nach einem Timeout. Über die anderen Einträge registriert der Bediener den PC in der Fog-Datenbank, startet Memtest, fertigt ein Plattenimage an oder lässt sich Informationen über den Host anzeigen.

Abbildung 1: Der Bootscreen eines Fog-Clients nach dem Start übers Netz.

Bei allen Menüpunkten außer dem ersten bootet ein Linux-Kernel, der über Bootparameter erfährt, was der Benutzer ausgewählt hat. Das regulär startende Betriebssystem darf eine Linux-Distribution sein, Fog ist Client-seitig aber auf Windows XP, Vista und 7 optimiert.

Um einen PC zu einer Fog-Aktion zu veranlassen, ohne dass ein Bediener vor dem Gerät sitzt, läuft auf Windows-Clients ein Service, der in Intervallen beim Server nachfragt, ob eine Aufgabe ansteht. Ist dies der Fall und kein Benutzer eingeloggt, startet der Service den Rechner neu. Der sich anschließende Netzwerkboot nimmt die vorgesehene Konfiguration vor und erledigt übertragene Aufgaben wie das Anfertigen eines Abbilds.

Walten im Nebel

Fog stattet den Arbeitsplatz des Administrators mit einer optisch sehr ansprechenden Weboberfläche aus, die die Arbeitsschritte gut gegliedert präsentiert (Abbildung 2). Im Zentrum der Verwaltungsaufgaben stehen die Hosts: Ihre Daten gelangen entweder durch das Registrieren im PC-Bootmenü, manuell per Web-GUI oder durch das Hochladen einer CSV-Datei in die Datenbank (Abbildung 3). Als logische Abstraktionsebene kann Fog Hosts in Gruppen ordnen. Jede Aktion, die der Server auf einem Host anzustoßen vermag, darf der Admin auch auf eine Gruppe anwenden.

Abbildung 2: Fogs Weboberfläche für den Administrator – nach dem Einloggen sieht dieser zuerst das Dashboard mit Nutzungsstatistiken.

Abbildung 3: Hier dreht sich alles um einen in Fog registrierten Host. Über das Menü links kann der Admin den betreffenden PC administrieren.

Im nächste Schritt widmet sich der Admin den Abbildern. Er legt eines an, indem er einen Namen, den Dateinamen (auch wenn die Datei noch nicht existiert), einen Typ und die so genannte Speichergruppe angibt. Der Typ darf das Image einer NTFS-Partition sein, das sich auch verkleinern lässt, um Speicherplatz zu sparen, oder ein Image mit mehreren Partitionen oder das einer ganzen Festplatte. Bei den letzten beiden Methoden ist Resizing nicht möglich. Ein Test ergab, dass bei geklonten Linux-Systemen die Partitionsgrößen ebenfalls fix bleiben, auch wenn im Zielsystem eine größere Festplatte ihren Dienst verrichtet.

Der nächste Menüpunkt verwaltet die eben erwähnten Speichergruppen. Eine Speichergruppe bekommt die Speicherknoten zugeordnet – so vorhanden. Der Admin gibt für jeden Speicherknoten dessen IP-Adresse, Usernamen und Passwort zur Absicherung der Kommunikation an sowie den Pfad, in dem die Images liegen, und die maximale Anzahl an Clients, die dieser Node bedienen kann.