Konfigurationsmanagement fängt bei jedem einzelnen Client an. Dort sind lokale Eigenheiten zu beachten, Bedingungen zu formulieren und dynamisch anzupassen. Der Altmeister der Zunft bringt eine Sprache mit, die intuitiv ist - das Linux-Magazin untersucht, ob sie heutigen Ansprüchen genügt.

Als Write-only-Software gelten Admin-Skripte, die Perl oder »sed« ausführen. Zu dieser Erkenntnis kam bereits 1993 die Universität Oslo [1] und entwickelte daraufhin Cfengine, den Ahnvater aller freien Konfigurationswerkzeuge [2]. Noch heute arbeitet eine aktive Entwicklergemeinde daran, das Tool weiterzuentwickeln. Cfengine setzt Richtlinien automatisch um, die sich auf Funktionsgruppen, zum Beispiel Mail- oder Webserver, Hardware oder auf das Betriebssystem beziehen. Neben den gängigen Linux- und Unix-Varianten unterstützt Cfengine nämlich auch Windows.

Das Tool unterscheidet sich von anderen Lösungen für das Konfigurationsmanagement durch seinen pragmatischen Ansatz. Die Syntax der Konfigurationssprache gilt als gut lesbar (andere Tools benutzen XML), die Konzepte als verständlich. Das Werkzeug richtet Systeme nicht nur initial ein, sondern kümmert sich bei Abweichungen auch darum, den Status quo wieder herzustellen. Wartungsarbeiten startet es über einen Scheduler, der Cron ähnelt, aber Rücksicht auf den aktuellen Zustand des Systems nimmt, beispielsweise hohe Last oder niedriges Mailaufkommen.

Installation und Setup

Aktuell ist die Version 2.2.7, in vielen Paket-Repositories der Distributionen findet sich noch die Release 2.2.3, mit der sich ebenfalls arbeiten lässt. Unter Debian und Derivaten erledigt das übliche

aptitude install cfengine2 cfengine2-doc

die Installation samt ausführlicher Dokumentation und einigen Konfigurationsbeispielen, die sich als Grundlage für eigene Anpassungen eignen. Cfengine operiert nach dem Client-Server-Prinzip, wobei ein Admin den Client auch autark betreiben kann. Bei größeren Installationen bietet es sich zwangsläufig an, die Master-Konfiguration auf einem Server vorzuhalten und dann auf die verwalteten Clients zu verteilen. Dazu erzeugt die Installtionsroutine ein RSA-Schlüsselpaar, das die Kommunikation absichert. Hat eine verwundbare Version von OpenSSL die Schlüssel erzeugt [3], sorgt

rm /var/lib/cfengine2/ppkeys/localhost*
/usr/sbin/cfkey

wieder für Sicherheit. Cfengine setzt sich aus den vier Programmen »cfagent«, »cfexecd«, »cfservd« und »cfenvd« sowie einigen Hilfswerkzeugen zusammen, die gemeinsam die Infrastruktur der Gruppenrichtlinien bilden (siehe Tabelle 1). Die eigentliche Arbeit übernimmt der »cfagent«, der die stets lokal vorgehaltene Policy interpretiert, überprüft und gegebenenfalls nötige Änderungen vornimmt. Wer nicht gleich die vollständige Infrastruktur aufsetzen möchte, kann auch einzelne Cfengine-Skripte schreiben und mit »cfagent« lokal ausführen.

Die Master-Konfiguration »/etc/cfengine/cfagent.conf« ist in Blöcke unterteilt, die jeweils eine Aufgabe - Action im Sprachgebrauch von Cfengine - übernimmt. Jede Aufgabe enthält Bedingungen, die das Werkzeug zu erfüllen versucht. Sind einige von ihnen nicht erfüllt, entwickelt es Aktivitäten, um den Zustand herbeizuführen. So passt es etwa eine Datei mit falschen Leserechten an.

Jedes Cfengine-Skript enthält einen »control«-Block, der in die modular aufgeteilten Blöcke verzweigt und damit die Ausführung steuert (siehe Listing 1). Zeile 1 leitet den »control«-Block ein, der allgemeine Konfigurationseinstellungen, etwa den DNS-Namen der Domain festlegt, aber auch eigene Variablen zu definieren erlaubt. Das Schlüsselwort »actionsequence« in Zeile 5 legt fest, welche Aufgaben der Agent in welcher Reihenfolge bearbeitet. Der durch die Anweisung konfigurierte Block »files« beginnt ab Zeile 7. Er überprüft, ob die angegebenen Dateien mit den angegeben Rechten auf dem System vorliegen, und korrigiert diese bei Abweichungen durch die Zuweisung »action=fixall«. Die Action »shellcommands« in Zeile 11 führt dort verzeichnete Shellbefehle bei jedem Durchlauf aus.

01 control:
02   domain      = ( linux-magazin.com )
03   access      = ( root )
04   tier        = ( Fisch )
05   actionsequence = ( files shellcommands )
06 
07 files:
08   /etc/passwd mode=644 owner=root group=root action=fixall
09   /etc/shadow mode=600 owner=root group=root action=fixall
10 
11 shellcommands:
12   suse|64_bit::
13     echo "Mach's gut und danke für den $(tier)"
14   Friday.Day13::
15     echo "Vorsicht! Heute ist Freitag, der 13."

Einfach Klasse

Sollen durch »shellcommands« definierte Befehle von Bedingungen abhängen, etwa dem Betriebssystem, der Plattform oder schlicht dem Wochentag, verwendet der Admin so genannte Klassen. Sie lassen sich an der Doppelpunkt-Notation erkennen. Eine Klassendefinition ist innerhalb eines Abschnitts so lange gültig, bis eine weitere Definition erfolgt. Fehlt die Angabe einer Klasse, tritt automatisch die für alle Systeme gültige Klasse »any::« in Kraft.

Führt Cfengine das Skript unter Suse oder einem 64-Bit-System aus (Zeile 12), gibt es sich literarisch. An einem Freitag dem 13. gibt das Tool die nötige Warnung aus (Zeilen 14 und 15). Einige Klassen bringt Cfengine bereits mit und nennt sie Hardcoded Classes. Der Admin kann Klassen auch zur Laufzeit definieren oder zuvor anhand bestimmter Voraussetzungen, etwa dem Verwendungszweck des Servers, festlegen. Welche Bedingungen greifen und welche Kommandos ausgeführt würden, verrät der Aufruf von:

cfagent --verbose --dry-run

Diese Trockenübung verändert nichts am System. Entspricht das der Erwartung, erfolgt durch Streichen des letzten Parameters der Sprung ins angewärmte Wasser.

Konfigurationsmanagement fängt bei jedem einzelnen Client an. Dort sind lokale Eigenheiten zu beachten, Bedingungen zu formulieren und dynamisch anzupassen. Der Altmeister der Zunft bringt eine Sprache mit, die intuitiv ist - das Linux-Magazin untersucht, ob sie heutigen Ansprüchen genügt.