Wer Konfigurationen zentral verwalten will, muss die Einstellungen dennoch zu den Clients transportieren. Bcfg2 geht aber noch einen Schritt weiter und abstrahiert das Was vom Wie. Dabei mahnt die Software den Admin sogar selbstständig daran, was er noch nicht erledigt hat.

© pmphoto, fotolia .com

Da die Mathematik- und Informatikabteilung des Argonne National Laboratory [1] unzufrieden mit der manuellen Konfiguration ihrer vielen Systeme war, entwickelte sie als internes Forschungsprojekt Bcfg2 [2] und veröffentlichte es später unter der BSD-Lizenz. Die akademische Herkunft des Projekts ist erkennbar: Es nutzt moderne Techniken wie XML zur Beschreibung und RPC zur Kommunikation mit seinen Clients. Kenner erweitern es leicht, es erfordert aber eine gehörige Einarbeitungszeit, da es einen sehr weitsichtigen, aber auch abstrakten Weg wählt. Darin unterschiedet sich das Werkzeug von den eher pragmatisch orientierten Tools Cfengine oder Puppet (siehe Artikel in diesem Heft).

Bcfg2 unterstützt viele Plattformen, darunter Open Suse, Fedora, Gentoo und Debian sowie viele abgeleitete Derivate und Businessversionen. Zusätzlich kommt es auch mit FreeBSD, AIX, Solaris und Mac OS X klar, da die Entwickler zusätzlich zu den fertigen Paketen für Client (oft »bcfg2«) und Server (oft »bcfg2-server« genannt) auch distributionsunabhängige Encap-Packages anbieten [3]. Alternativ hilft ein Blick auf den Open Suse Build Service [4] weiter, der Pakete für einige weitere Plattformen anbietet.

Architektur

Die Verwaltung von Spezifikationen erledigt Bcfg2 mittels eines Servers, der mit einem relativ kleinen Gegenstück auf dem Client kommuniziert. Sowohl Server als auch Client spielt der Administrator initial mit dem Paketmanager seiner Wahl ein. Der Client besteht nur aus wenigen Zeilen Python-Code. Ihn trägt der Administrator entweder in die Crontab ein, damit sich der Client regelmäßig beim Server meldet und Aktualisierungen abholt. Oder er lässt Bcfg2 als Hintergrundprozess starten. In diesem Fall darf der Server den Agenten auch aktiv kontaktieren.

Der Admin konfiguriert alle Einstellungen seiner gemanagten Systeme ausschließlich am Bcfg2-Server. Er hält für jeden Client Beschreibungen vor, die er aus einer zentralen Spezifikation erzeugt. Dieser Prozess hat mehrere Abstraktionsschichten und erfordert für den Einsteiger eine gewisse Einarbeitung.

Objekthierarchie

So kennt Bcfg2 auf der obersten Ebene Profile, die Klassen gleichartiger Rechner beschreiben, etwa ein Desktopsystem oder einen Webserver. Jeder verwaltete Rechner hat genau ein Profil. Innerhalb dessen sind Gruppen definiert, die bestimmte logische Systembereiche umfassen, etwa Office-Software oder Netzeinstellungen. Sie erlauben es, die Konfigurationsspezifikation übersichtlich zu gestalten und Code-Duplikation zu vermeiden. Diese Gruppen lassen sich rekursiv schachteln. Jede Gruppe enthält ihrerseits eine beliebige Anzahl von Bundles. Ihr Geltungsbereich orientiert sich zumeist an einem Softwareprodukt, etwa Postfix, Open Office oder dem Nameswitch-Mechanismus. Die Profile, Gruppen und Bundes legt die Datei »metadata/groups.xml« fest (siehe Listing 1).

01 <Groups>
02   <Group name='desktop' profile='true'>
03     <Bundle name='motd' />
04     <Bundle name='networking' />
05     <Group name='office-workstation' />
06     <Group name='debian-stable' />
07   </Group>
08 
09   <Group name='webserver' profile='true'>
10     <Group name='apache' />
11     <Bundle name='networking' />
12     <!-- ... --!>
13   </Group>
14 
15   <Group name='office-workstation'>
16     <Group name='gnome-desktop' />
17     <!-- ... --!>
18   </Group>
19 
20   <Group name='debian-stable'
21          toolset='debian' />
22 </Groups>

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Wer Konfigurationen zentral verwalten will, muss die Einstellungen dennoch zu den Clients transportieren. Bcfg2 geht aber noch einen Schritt weiter und abstrahiert das Was vom Wie. Dabei mahnt die Software den Admin sogar selbstständig daran, was er noch nicht erledigt hat.