Zentrale Konfigurationsverwaltung mit Cfengine

Eine Systemeinstellung ist auf allen Clients neu zu konfigurieren. Meier kann das selber erledigen und er kann auch Schulze helfen, der ihm gegenüber am Schreibtisch sitzt. Bei Müller geht der Admin vorbei. Das gleiche Szenario in einer großen Behörde: Hier gibt es 127 Müllers und würde der Admin jeden persönlich besuchen, wäre er wochenlang auf Achse. In einer solchen Umgebung oder in der Serverfarm eines Rechenzentrums oder beim Grid Computing gibt es kaum eine Alternative zu automatisierter Systemadministration.

Die großen Distributoren von Suse bis Red Hat bieten für solche Arbeiten Unterstützung an und statten ihre kommerziellen Business-Versionen mit den entsprechenden Werkzeugen aus. Auch andere namhafte Hersteller von Unix-Hard- und Software, beispielsweise Sun, haben spezielle Offerten für die Konfigurationsverwaltung in Linux-Umgebungen mit vielen Clients parat [1].

Doch diese Angebote sind nicht in jedem Fall optimal: Einerseits sprengen sie zuweilen den Kostenrahmen, andererseits ist die Systemwelt nicht immer hinreichend homogen und in einem dritten Szenario fehlt vielleicht ein essenzielles Feature. Spätestens dann kommt Cfengine [2] ins Spiel - leistungsstark, kostenlos, plattformübergreifend und erweiterbar ist das Open-Source-Tool eine gute Alternative.

Das Ziel, nicht der Weg

Cfengine (Configuration Engine) wird seit zehn Jahren an der Universität Oslo entwickelt und steht unter der GPL. Es existieren Unix-Versionen und solche für Windows und Mac OS X. Sie beherrschen alle wichtigen Aufgaben der Systemadministration und können zum Beispiel genauso Dateien editieren und im Netzwerk verteilen wie Prozesse starten und überwachen, Dateisysteme mounten oder Verzeichnisse aufräumen und vieles mehr. Viele gängige Distributionen (etwa Suse, Debian oder Fedora) liefern bereits fertige Pakete, entsprechend einfach ist bei ihnen die Installation.

Was bei der Beschäftigung mit Cfengine sicherlich zuerst auffällt, ist ein Denkansatz, der das Tool grundlegend von seinen Verwandten unterscheidet: Vorgegeben wird das Ziel, nicht der Weg. Der Admin übermittelt dem Rechner also kein Skript mit detaillierten Handlungsanweisungen, sondern die Beschreibung eines Soll-Zustands. Über das Wie braucht er sich zunächst keine Gedanken zu machen.

Als Nebeneffekt dieser Herangehensweise lassen sich Cfengine-Skripte bis auf Ausnahmen schadlos mehrfach ausführen (sie sind idempotent). Erreichen sie beim ersten Lauf das Ziel, verändert ein weiterer Start nichts mehr. Um Clients vor einer zu hohen Last durch zu oft ausgeführte Anweisungen zu schützen, lassen sich für jede Aktion Mindestzeitabstände angegeben, die zwischen zwei Ausführungen einzuhalten sind.

Arbeitsteilung

Cfengine besteht aus mehreren Komponenten. Die wichtigsten sind zum einen »cfagent«, der Interpreter, der von Cfengine genutzten Beschreibungssprache, zum anderen »cfservd«, ein Daemon, der Dateien netzwerkweit verteilt. Das Kopieren von Files erfordert allerdings grundsätzlich eine Authentifizierung und erfolgt auf Wunsch verschlüsselt. In diesem Fall verwendet Cfengine die Bibliothek OpenSSL - sie stellt Funktionen für RSA-Schlüssel und den verwendeten Blowfish-Algorithmus zur Verfügung.

Abbildung 1: Der Pull-Modus benötigt nur drei Komponenten. Cfexecd lässt sich bei Bedarf durch den Systemdienst Cron ersetzen.

Cfengine unterstützt zwei Operationsmodi: Im Pull-Modus startet auf dem Client periodisch »cfagent«. Er bezieht vom »cfservd«-Daemon auf dem Management-Server die benötigten Anweisungen und führt sie dann lokal aus. Im Push-Modus dagegen kontaktiert das Programm »cfrun« auf dem Management-Server nacheinander eine Liste von Hosts und löst dann auf jedem von ihnen die Abarbeitung der anstehenden Aktionen aus.