Chormeister für Rechner-Parks

Am Regionalen Rechenzentrum der Universität Erlangen-Nürnberg (RRZE) laufen auf den zentralen Rechnern praktisch ausschliesslich Unix-Systeme. Neben einigen wenigen HP/UX- und Irix-Installationen findet man im Gros der Server Solaris und Linux. Aus ökonomischen Gründen wurde die Entscheidung getroffen, die Dienste mit vielen kleinen Maschinen anstatt einigen wenigen grossen Servern anzubieten. Von administrativer Seite her gesehen stellt diese Architektur eine grosse Herausforderung dar. Denn jedes einzelne der vielen kleinen Systeme muss mit Patches versorgt, gewartet, gepflegt, überwacht und ab und zu umkonfiguriert werden.

Limitierter Eigenbau

Bislang wurde das Open-Source-Werkzeug rdist verwendet. Die Aufgabe von rdist ist es, auf verschiedenen Rechnern identische Kopien von Dateien vorzuhalten. Im Gegensatz zu rsync benutzt es eine Steuerungsdatei, die – in Abhängigkeit von getätigten Kopieraktionen – auch Befehle ausführen kann. So ist es mit rdist möglich, eine Crontab auf alle Rechner zu verteilen, um anschliessend mit Hilfe eines oder mehrerer Befehle eine eventuell vorhandene lokale Crontab mit der globalen zu verschmelzen und diese dann zu aktivieren.
Obwohl dieses System jahrelang funktioniert hat, waren doch einige Tücken und Grenzen zu überwinden. So bringt beispielsweise Solaris selbst nur wenig Software mit, und auch die Open-Source-Zugaben von Sun Microsystems sind nicht sehr umfassend und meistens etwas betagt. Doch auch unter Linux ist nicht immer alles mit den vorhandenen Paketen zu erledigen. Deshalb wurden Paketsammlungen im grossen Stil mit Hilfe von NFS auf die einzelnen Rechner nach /local exportiert, wo Benutzer und Dienste ihre Binaries finden konnten. Das Problem dabei war allerdings, dass es mit der Zeit praktisch unmöglich war, Abhängigkeiten von verschiedenen Versionen der Pakete zu pflegen. Auch war es sehr schwer, Altlasten zu entsorgen, da niemand genau wusste, ob wirklich alle Abhängigkeiten der Pakete gelöst und somit obsolet waren. Aus diesem Grund wurde die Entscheidung getroffen, ein neues Konzept einzuführen.

Einfaches Konzept mit grosser Wirkung

Das neue Konzept sollte dank eines überarbeiteten Paketkonzepts und des Einsatzes von cfengine die Arbeit der Administratoren vereinfachen.
Für Solaris sollte als Paketbasis die Sammlung von Blastwave dienen. Bei Linux (am RRZE wird Suse Linux verwendet) soll den distributionseigenen Paketen der Vorzug gegeben werden. Alles, was trotzdem selbst kompiliert werden muss – etwa weil es nicht vorhanden ist oder weil spezielle Versionen benötigt werden –, muss in Pakete verpackt und unter dem Pfad /opt/FAU installiert werden. Dank der Nutzung des betriebssystemeigenen Paketmechanismus (rpm für Suse Linux und pkg bei Solaris) können Abhängigkeiten aufgelöst und Pakete bei Bedarf sauber deinstalliert werden. Als Update-Mechanismus wird für Linux apt-get verwendet und für Solaris eine ähnlich funktionierende Software von Blastwave, welche sich pkg-get nennt.

Wartung des Administrators

Eines der ersten Pakete, das jeweils auf den Rechnern installiert wird, ist cfengine. Das Post-Install-Skript von cfengine nimmt den Erstkontakt zum Server auf, startet die benötigten Dienste und löst das erste Update aus. Die angepasste automatisierte Jumpstart-Installation für Solaris erledigt die ganze Prozedur automatisch, während auf den Linux-Systemen cfengine im Moment noch von Hand aktiviert wird; dies, da die Integration von cfengine am RRZE für Linux noch nicht so weit fortgeschritten ist.
Wichtig bei der Anwendung von Werkzeugen, die so tief ins System eingreifen, wie es cfengine macht, ist eine vernünftige Versionsverwaltung für die Konfigurationsscripts. Falls das Ergebnis nicht den Erwartungen entspricht oder Fehler gemacht wurden, kann so eine ältere Version wiederhergestellt oder nachvollzogen werden, wann eine Änderung gemacht und von wem sie veranlasst wurde. Auch kann man cfengine mit einem kleinen Script, das die nötigen Daten aus der Versionskontrolle exportiert, sich selber aktualisieren lassen.

Lange Zeit wurden am RRZE die Konfigurationen von cfengine per RCS verwaltet. Mittlerweile steht der Umzug auf ein verteiltes System wie CVS oder Subversion an, da damit auch externen Administratoren, zum Beispiel von einem der angeschlossenen Institute, ermöglicht werden kann, ihre Rechner via cfengine zu verwalten. Da Subversion binäre Dateien besser verwalten kann als CVS und bei der Installation am RRZE durchaus auch Binaries verteilt werden, fiel die Wahl auf Subversion.
Die Anforderung, dass auch externe Administratoren auf das System zugreifen können, erforderte einige weitere Anpassungen. So muss dafür gesorgt werden, dass ein Administrator nur mit diesem Teilbaum arbeitet, für den er zuständig ist, und diesen selbständig warten kann, ohne auf das Gesamtsystem Einfluss nehmen zu können. Vor allem im Linux-Bereich ist dies auch für die angeschlossenen Institute interessant, da so eine zentrale Administration durch das RRZE möglich ist und die einzelnen Administratoren vor Ort auch ohne grundlegende Kenntnisse der cfengine zurechtkommen. Hier wird ein hoher Grad an Automatisierung angestrebt, um den Kollegen die Arbeit zu vereinfachen. Zu diesem Zweck wurden die Konfigurationen und zu verteilenden Dateien
aufgeteilt.

Automatische Qualitätsprüfung

Wichtig bei so einer Automatisierung ist aber, dass die einzelnen Teile – besonders die cfengine-Konfigurationen selbst – valide bleiben. Zwar können inhaltliche (nichtsyntaktische) Fehler (etwa eine «nur» falsch kopierte Datei oder ein falsch geänderter Eintrag in einer Konfigurationszeile für einen Klienten) durch einen Überprüfungsmechanismus nicht gefunden werden. Unbedingt geprüft werden muss aber die Syntax der cfengine-Skripte selbst, damit nicht das gesamte System zusammenbricht. Diese Aufgabe lässt sich an den Pre-check-in-Mechanismus von Subversion delegieren. Findet dieser einen Fehler, kann der fehlerhafte Teil nicht eingecheckt werden.
Um die Lesbarkeit der cfengine Konfigurationen zu erhalten, wurde ein Styleguide festgelegt, der eingehalten werden soll. Dabei kann allerdings nur an die Disziplin der Administratoren appelliert werden. Überprüft wird das nicht. Diskussionen gab es auch, inwieweit cfengine die auf den Rechnern installierten Pakete automatisch über pkg-get bzw. apt-get aktualisieren soll. Bis jetzt haben sich auf Solaris-Seite keine Probleme ergeben. Allerdings musste dafür ein Mechanismus gefunden werden, die speziell angepassten FAU-Pakete mit den Blastwave-Paketen zu mergen. Dazu wurde ein eigener FTP-Baum erstellt, welcher beide Bäume vereint. Auch Linux hatte keine Probleme mit dem automatischen Update.

Wenig Probleme

Der Umstieg auf eine Rechnerverwaltung mit cfengine hat durch intensive Planung und sanfter Migration verhältnismässig wenig Probleme bereitet. So wurde cfengine lange Zeit nur im Leerlauf betrieben. Die Prozesse liefen zwar auf den Clients, haben sich aber nur auf Trockenübungen beschränkt. Erst nachdem das Vertrauen in das System gewachsen war, wurden die Konfigurationen nach und nach gefüllt.
Etwas problematischer war die Einführung in Bereiche, die durch Firewalls geschützt werden. Einige Systeme maskieren die IP-Adresse der dahinter liegenden Hosts durch die eigene. Der cfengine-Daemon autorisiert die Clients aber anhand der IP Adresse und des cfengine-Host-Keys. Dieses Problem konnte nur dadurch gelöst werden, dass alle Hosts hinter diesen Firewalls dieselben cfengine-keys erhalten haben. Diese Lösung ist zwar alles andere als hübsch – eine bessere Lösung konnte aber bis jetzt nicht gefunden werden.

Der Autor

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.