Systemadministratoren sind faule Leute. Überall dort, wo man Handarbeit sparen kann, wird automatisiert: Skripte führen regelmässige Aufgaben aus, Installationen werden automatisiert, Syslogs automatisch ausgewertet und Softwarepakete aktualisiert. Die Rechnerinstallation läuft, einmal angestossen, per Netzwerk-Boot automatisiert bis zur letzten ganz besonderen und nur für das lokale Subnetz geltenden Einstellung ab. Nach einiger Zeit ist das System einsatzbereit, ohne dass der Systemadministrator Hand anlegen musste. Und wenn einmal die Konfiguration des Rechners angepasst werden soll, erledigt dies der Systemadministrator auf einem einzigen Host, von dem alle anderen Rechner automatisch die Änderungen beziehen.
Von solch einem komfortablen Leben träumt jeder Systemadministrator. Dass dies schon heute problemlos realisierbar ist, wissen nur wenige. Tatsächlich lassen sich automatisierte Installationen mit Tools wie FAI (Debian), Kickstart (RedHat), JumpStart (Solaris), alice/YaST (Suse) oder lui (AIX) wunderbar erledigen. Aber auch zum nachträglichen Ändern und Konfigurieren von Rechnern gibt es ein Toolset: cfengine.
Cfengine ist eine Metaprogrammiersprache, welche von Mark Burgess, Professor für Netzwerk- und Systemadministration an der Universität Oslo, entwickelt wurde. Sicher verfügt jeder Systemadministrator über ein Arsenal von Tools, die er selbst gebastelt hat, und auch mit Bordmitteln lassen sich einige täglichen Arbeiten vereinfachen und automatisieren. Die Leistungsfähigkeit und Flexibilität der «GNU ConFiguration ENGINE» lässt sich aber nur schwer selbst nachprogrammieren, zumal selber gebaute Tools erfahrungsgemäss meist fehleranfällig und für Dritte schwer bis gar nicht zu verstehen sind. Anders ist es mit cfengine. Das Tool ist nicht nur ausführlich dokumentiert, es existieren auch etliche Tutorials und Bücher, welche in den Umgang mit dem System einführen.
Cfengine besteht aus vier einzelnen Programmen, welche die eigentliche Arbeit erledigen, und einer Handvoll weiterer Zusatzprogramme. Cfservd ist der Daemon-Prozess, der die Verbindung zwischen den Clients und dem Server beziehungsweise den Zugriff zwischen den einzelnen cfengine-Instanzen regelt. Cfrun ist der Client, mit dem man unabhängig von der Zeitsteuerung des cfexecd den cfservd auf einem Rechner anweisen kann, eine bestimmte Aktion sofort auszuführen. Die eigentliche Arbeit erledigt der cfagent während cfexecd die (zeitabhängige) Steuerung des cfagent übernimmt.
Bei einer klassischen cfengine-Installation existiert ein Master-Server, auf dem die Konfigurationen erstellt werden. Auf den Clients interpretiert der cfagent die Konfigurationseinstellungen und führt die programmierten Aktionen aus. Dabei kann cfengine sowohl als Push- als auch als Pull-Agent betrieben werden. In der Regel läuft auf jedem Host ein cfexecd, welcher steuert, wann der cfagent in Aktion tritt. Wenn der cfagent gestartet wird, holt er sich nach dem Start zuallererst vom Master Server «frische» Steuerungsdateien. Auf Server-Seite läuft der cfservd, der die Zugriffsrechte auf die Konfigurationseinstellungen von cfengine und auf eventuell zu kopierende Dateien regelt. Dann führt der cfagent lokal die Aktionen aus, welche zu diesem Zeitpunkt anstehen. Umgekehrt kann per cfrun der Agent auf den einzelnen Hosts angewiesen werden, bestimmte Aktionen sofort auszuführen und nicht zu warten, bis der cfexecd zum Leben erwacht. Durch den cfexecd kann cfengine übrigens auch als Ersatz für cron verwendet werden. Übliche Praxis ist allerdings, dass sich die beiden Dienste cron und cfengine gegenseitig überwachen und bei Bedarf neu starten.
Eine cfengine-Konfiguration besteht aus einer oder mehreren Dateien, welche den gewünschten Zustand des Rechners definieren anstatt – wie üblich – Prozeduren beschreiben, wie die Maschine in den gewünschten Zustand versetzt werden kann. Man beschreibt also, wie beispielsweise eine bestimmte Zeile in /etc/inetd.conf aussehen soll. Wie die Zeile jedoch in den gewünschten Zustand gebracht wird, wird cfengine überlassen.
Eine Konfiguration besteht in der Regel aus vier Dateien:
• cfservd.conf definiert Zugriffsrechte von cfengine-Clients auf den Server-Prozess.
• cfagent.conf beschreibt Aktionen, welche auf den Clients ausgeführt werden.
• cfrun.hosts enthält eine Liste von Hosts, die über cfrun angesprochen werden können.
• update.conf ist ein sehr einfaches cfengine-Skript zum Updaten der eigentlichen Konfigurationsdateien, welches dazu dient, dass unabhängig von eventuell fehlerhaften configs die Clients trotzdem updatefähig bleiben und so korrigierte Konfigurationsdateien erhalten können.
Die wichtigste Datei ist cfagent.conf. In dieser wird definiert, in welcher Reihenfolge die 21 möglichen Aktionen (shellcommands, editfiles, links, disable, files, tidy, copy, processes, um nur die wichtigsten zu nennen) ausgeführt werden. Ergänzt werden diese Informationen mit Klassen (z.B. «fileserver», «linux», «vertriebsnetz», «vertrieb.domain.com») und Variablen (etwa um Pfade für Shellcommands zu speichern oder Platzhalter für E-Mail-Adressen zu setzen). Anschliessend wird pro Aktion ein Abschnitt ergänzt, welcher den Soll-Zustand beschreibt. Ein Beispiel zeigt der untenstehende Kasten.
Wie man sieht, benutzt cfengine eine eigene Programmiersprache, die zwar etwas Einarbeitungszeit bedarf, dafür aber sehr mächtig ist, was die Liste an Möglichkeiten zeigt, die einem eine cfengine-Konfiguration bietet:
• Dateien von einem Server auf beliebig viele Zielrechner in beliebige Verzeichnisse kopieren,
• Symbolische Links setzen beziehungsweise überprüfen,
• Zugriffsrechte (sowohl POSIX-Rechte als auch ACLs) und Eigentümer von Dateien überprüfen und setzen,
• Textdateien durch Befehle und reguläre Ausdrücke anlegen und editieren,
• Dateien deaktivieren (entfernen),
• Dateien löschen (Core Files, temporäre Dateien, nach Datum),
• Verzeichnisse anlegen oder löschen und Rechte setzen,
• Shell-Skripte oder Programme ausführen,
• Netzkonfiguration setzen und überprüfen (IP Adresse, Nameserver, Zeitzone),
• NFS-Dateisysteme mounten und überwachen,
• Mailserver überprüfen,
• Signale an Prozesse senden (HUP, KILL, TERM...),
• Prozesse überwachen und bei Bedarf neu starten,
• Überprüfen, ob bestimmte Pakete installiert sind,
• Zeit gesteuert Aktionen ausführen (als Ersatz für cron-Einträge),
• Module ausführen, wodurch eine praktisch beliebige Erweiterbarkeit durch selbst programmierte Skripte vorhanden ist.
Damit die Konfiguration der Rechner über cfengine nur von den richtigen Servern aus gesteuert werden kann und nicht ein beliebiger (bösartiger) Host den anderen Anweisungen geben kann, verwendet cfengine eine Public-Key-Authentifizierung. Sowohl der Server als auch der Client verfügen über einen Private Key und authentifizieren sich gegenseitig mit Hilfe des zugehörigen Public Key. Dadurch wird erreicht, dass sich Server und Client gegenseitig kennen und kein fremder Host sich als der jeweilige andere Partner ausgeben kann, was Missbrauch einen Riegel vorschiebt. Weiter kann cfengine den Transfer der Dateien bei Bedarf verschlüsseln, womit der Einsatz von cfengine auch in öffentlichen Netzen kein Problem ist.
Cfengine ist auch ein ideales Tool zur Unterstützung der Systemsicherheit. So kann es beispielsweise eine Datenbank mit Prüfsummen bestimmter Dateien führen. Ändert sich eine Datei, etwa durch ein durch einen Hacker verändertes Programm, oder wurde ein ausführbares binary (Programm) von einem Hacker statt dem Original abgelegt, schlägt cfengine Alarm, indem es eine E-Mail versendet. Auch interessant ist der cfenvd. Dieser Dämon kann Anomalien im System erkennen. Nach etwa vier Wochen Laufzeit hat der cfservd so viel über das laufende System gelernt, dass er weiss, welche Last, welche Prozesse und wie viel Speicherverbrauch für den Host «normal» sind. Übersteigt ein Wert eine bestimmte Grenze (etwa ein enormes Ansteigen von Netzverbindungen), meldet cfengine dies dem Systemadministrator. Zum einen können dadurch amoklaufende Tasks und zum anderen kann ein erfolgter Einbruch oder Einbruchversuch erkannt werden. Ein nettes Abfallprodukt ist die Möglichkeit, die von cfenvd gemessenen Werte zu exportieren und so mit Tools wie gnuplot Graphen zu erstellen.
Gregor Longariva (longariva@ softbaer.de) ist Solaris-Administrator am Rechenzentrum der Universität Erlangen-Nürnberg und Spezialist für die Unix-Betriebssysteme HP/UX, Irix, Linux, OpenBSD und Solaris.
