© Jean-Pol Grandmont, CC BY-SA 3.0

Die Plattform mit dem anmutigen Namen Open Venus tritt an, um dem Administrator das Leben zu vereinfachen. Die Wiedergängerin der proprietären SC Venus setzt Kommandos auf Gruppen von Servern ab und verteilt Dateien oder Softwarepakete von zentraler Stelle aus.

Das Tagesgeschäft eines Administrators besteht aus vielen und teils langweiligen Aufgaben: Er spielt Patches ein, absolviert das Setup neuer Server oder nimmt gar auf allen Rechnern einer Firma Änderung vor. Virtualisierung und Cloud Computing machen seine Situation nicht besser, da das Einrichten eines neuen virtuellen Servers auf Basis eines Masterimage schnell erledigt und somit die Neigung, dies oft zu tun, entsprechend angestiegen ist. Die laufenden Images zu pflegen und zu administrieren erfordert aber den gleichen Aufwand wie bei einem dedizierten Gerät.

Um arbeitsfähig zu bleiben, versuchen Admins mit selbst geschriebenen Toolsets oder fertigen Verwaltungslösungen ihre Rechnerpools effizienter zu verwalten. SC Venus [1] von Science+Computing ist eine solche kommerzielle Verwaltungssoftware, das Linux-Magazin hatte sie vor einiger Zeit getestet [2].

Auch der Münchner Open-Source-Entwickler Albert Flügel war recht angetan von SC Venus, als er als ausgeliehener Systemadministrator in einer großen Umgebung arbeitete. Der Auftraggeber verwaltete mit SC Venus eine vierstellige Anzahl Hosts. Als dort die Lizenz des Frameworks auslief, stand das Administratorenteam vor dem Problem, die zum Teil recht alten Betriebssystemstände weiterhin verwalten zu müssen.

Auf eine frischere Lösung wie Puppet umzuschwenken funktionierte wegen der dazu benötigten neuen Software nicht. Dies und in SC Venus vermisste Features brachten Flügel dazu, eine schon vor längerer Zeit begonnene Implementierung wieder aufzugreifen und weiterzuentwickeln: Open Venus [3]. Die Software ist SC Venus nachempfunden, ja nachimplementiert. Da Albert Flügels Administratorenteam bereits viel Arbeit in die SC-Venus-Skripte investiert hatte, war es sein Ziel, die Kompatibilität mit SC Venus auf API-Ebene sicherzustellen.

Was kann das System

Administratoren, die sich einen Open-Venus-Server hinstellen (siehe Kasten “Installation”), verfügen über eine Plattform, mit der sie ihre Systeme einfacher zentral verwalten. Die Software steuert nicht nur Linux-Rechner (Red Hat, Fedora, Centos, Suse), sondern auch welche mit Solaris oder HP-UX, selbst Windows-Systeme lassen sich einbinden, wenn die Cygwin-Umgebung dort installiert ist.

Open Venus führt Kommandos auf vielen Rechnern gleichzeitig aus. Der Admin fasst zu diesem Zweck Geräte in Gruppen zusammen, wobei ein Rechner mehreren Gruppen angehören darf. Außerdem verteilt das Framework einzelne Dateien oder ganze Softwarepakete auf die administrierten Systeme.

Technisch besteht Open Venus aus einem Masterserver, an den zu administrierende Clients angebunden sind (Abbildung 1). Auf dem Server installiert der Admin zwei Pakete: Basis und Server; auf den Clients nur das Basispaket. In großen Setups kann man auch mehr als einen Server betreiben. Das Authentifizieren zwischen Client und Server erfolgt über SSL-Zertifikate, die der Master im Zuge jeder Clientinstallation ausstellt. Klappt die Verbindung, darf der Server seine Clients fernsteuern und Dateien oder Softwarepakete dorthin übertragen.

Abbildung 1: Struktur eines typischen Open-Venus-Setups.

Viele Chefs

Open Venus ist für mehrere Administratoren ausgelegt, von denen jeder auf dem Master einen eigenen Account besitzt und eigene Zuständigkeiten übertragen bekommt. Um Aktionen anzustoßen, loggen sich die Administratoren dann auf dem Master ein. Pro Kommando ist konfigurierbar, welcher Administrator (oder welche Gruppe) auf welchem Host (oder welcher Gruppe) dieses Kommando ausführen darf. Sogar Spezialrechte sind konstruierbar, etwa: Admin Hans bekommt Zutritt zu allen Hosts der Gruppe »Buchhaltung« , außer zum Host »Banking« . Die Listen der Administratoren- und Hostgruppen hält der Master entweder lokal vor oder in einem Verzeichnisdienst wie NIS oder LDAP, was zu empfehlen ist.

Auf Kommando

Beim Ausführen von Kommandos kennt Open Venus zwei Spielarten: Einfache Kommandos setzt der Admin mit dem Kommando »ovprdo« ab, wenn er auf den Clients als Superuser agieren will, und »ovrdo« für das Ausführen als normaler Benutzer. Die Ausgaben der Kommandos erscheinen auf der Konsole, auf der sie gestartet wurden, und landen im Log; auch den Exitcode jedes Kommando-Laufs wertet Open Venus aus.

Ist ein Host der Liste nicht erreichbar, vermerkt Open Venus dies als Fehler, schiebt die Aufgabe aber nicht in eine Queue. Ein Kommando für nicht erreichbare Hosts zu puffern gelingt mit der Option »+N« ; die unprivilegierte Variante eignet sich nicht fürs Batchen. Abbildung 2 zeigt den Lauf eines Kommandos.

Abbildung 2: Hier steuert Open Venus auf dem Client »venusclient« die Ausführung eines Kommandos.

Die zweite Variante für komplexere Operationen sind Methoden. Für sie hält Open Venus ein eigenes API bereit. Methoden sind in Perl oder Bash implementierte Skripte. Der Admin checkt sie in ein Repository ein und kann sie mit dem Kommando »ovrapply« auf den Clients ablaufen laufen. »ovrapply« batcht in der Standardeinstellung, was sich mit »-N« auch deaktivieren lässt.

Auf den Clients fragt der Dienst »ovpoll« beim Server an, ob Aufgaben anstehen. Alternativ stößt »ovqpush« auf dem Server einen Queue-Run an. Für die Queues selbst gibt es Kommandos, um die ausstehenden Jobs aufzulisten und Jobs zu löschen. Der Server probiert nicht per se, einen fehlgeschlagenen Job abermals zu starten, dies kann aber ein Push- oder Pull-Cronjob nachholen.

Software verteilen

Neben dem Ausführen von Jobs samt eigenem API ist die Verteilung von Software die zweite Hauptfunktion von Open Venus. Dabei unterstützt die Software derzeit Solaris-Packages, Linux-Pakete im RPM-Format sowie Tar-Archive. Bevor der Admin die Software verteilt, checkt er sie auf dem Open-Venus-Server ein. Danach listet das System Pakete auf Wunsch auf, installiert oder löscht sie.

Ein steter Quell von Arbeit ist das Pflegen von Konfigurationsdateien. Wer einen Dienst auf einem Server ändert, muss dies oft genug ein paar Hundert Clients im Netz mitteilen. Open Venus verwaltet ein Repository für solche Konfigurationsdateien, wobei sich auch hier Hosts zu Gruppen mit gleichen Konfigurationsdateien zusammenfassen lassen, zum Beispiel Solaris-spezifische Dateien und Linux-spezifische.

Zum Bearbeiten der Konfigurationsdateien checkt der Admin die Datei aus, ändert sie und checkt sie wieder ein. Der Umstand, dass das Repository eine Versionskontrolle enthält, macht Konfigurations-Rollbacks möglich. Die Versionskontrolle greift auch für Methoden.

Das Kommando »ovpdistfile« verteilt dann die Datei auf eine Clientgruppe. Dabei batcht Open Venus die Aufträge, falls einzelne Clients in der Gruppenliste nicht erreichbar ist. Und: Mehrere Pakete und Methoden lassen sich zu einem Metapaket zusammenfassen, damit Open Venus konsistente Bündel verteilt.

Das API bietet auch eine eigene Funktion, die Dateien bei Ablauf der Methode auf dem Client herunterlädt. Dies ist vor allem dann sinnvoll, wenn ein Dienst nicht nur eine, sondern mehrere Konfigurationsdateien besitzt, die sich immer zusammenhängend ändern. Alle Aktionen protokolliert Open Venus, sodass die Admins nachvollziehen können, wer was wann gemacht hat.

Das API für Methoden

Methoden greifen per API auf das Framework zu. Standard für Open Venus sind Bash-Skripte, gestattet sind aber auch andere Sprachen, die mit dem »#!« -Mechanismus funktionieren – genauer gesagt akzeptiert Open Venus Skripte im Format »#! Interpreter: Programm« . Das funktioniert sogar auf Windows-Systemen, die »#!« nativ nicht verstehen.

Skripten, die unter dem Framework ablaufen, steht eine Reihe von Umgebungsvariablen zur Verfügung, die eher Open-Venus-intern sind. Zudem kann der Admin über eine Konfigurationsanweisung eigene Umgebungsvariablen mitgeben. Die API-Beschreibung nennt eine Reihe von Utility-Funktionen, beispielsweise solche, um Pakete zu installieren oder um auf Open-Venus-Informationen zuzugreifen. Apropos Beschreibung: Die Dokumentation von Open Venus ist zwar als Referenz akzeptabel, macht aber den Einstieg nicht unbedingt einfach.

Fazit

Wenn das Netzwerk groß und die verwendeten Betriebssysteme vielfältig sind, schlägt die Stunde des Verwaltungssystems SC Venus oder seines schlanken Freie-Software-Abkömmlings Open Venus. Ein Vorteil von Open Venus ist auch die Unterstützung recht alter Betriebssysteme, etwa Suns OS 4.

Der zentrale Master setzt Kommandos und Skripte ab und verteilt Software und Konfigurationsdateien. Dabei kann der Admin die Clients gruppieren, Open Venus erkennt Architektur und Betriebssystem zudem automatisch. Da ein Großteil der Funktionen auf Skripten beruht, sind sie einfach zu verstehen und darauf ausgelegt, dass der Administrator sie selbst erweitert. Zudem kommt Open Venus mit recht minimalen Abhängigkeiten aus. Einer Ruby-Installation wie bei Puppet bedarf es nicht.

Andere Frameworks punkten mit mehr Funktionen und einer großen Community, die fertige Rezepte für Standardaufgaben bereithält. Die Funktionsweise der One-Developer-Show Open Venus dagegen durchschaut der Admin noch selbst. Den größten Vorteil aus Open Venus können freilich frühere SC-Venus-Benutzer ziehen, die noch an eigene Gegebenheiten angepasste Skripte besitzen und nun weiterbenutzen. (jk)