Rechner verwalten mit Rex

Mit Rex verwaltet der Administrator sämtliche Rechner in einem Netzwerk von einer zentralen Stelle aus. Als einzige Voraussetzung müssen alle Computer per SSH erreichbar sein, der Rechner des Administrators benötigt zudem eine installierte Perl-Umgebung. Auf dem eigenen Rechner definiert der Administrator dann eine Aufgabe (Task), die wiederum einige ausgewählte oder sogar alle anderen Computer ausführen beziehungsweise abarbeiten.

Auf diese Weise kann man etwa Programme nachinstallieren und löschen, Wartungsaufgaben ausführen, die Konfiguration sämtlicher Stationen einheitlich ändern, Dokumente verteilen oder schlicht Informationen über den Gesundheitszustand der Systeme abfragen. Mit einem entsprechend formulierten Task genügt beispielsweise schon der Befehl »rex apache2« , um auf allen Webservern Apache2 zu installieren und sie gleich auch noch mit passenden Konfigurationsdateien auszustatten.

Rex heißt übrigens nach dem Willen der Programmautoren in Wirklichkeit "(R)?ex". Da dies aber schwer zu schreiben, lesen und auszusprechen ist, verwendet dieser Artikel im Weiteren eine andere Schreibweise.

Freie Auswahl

Kontrollieren kann Rex Computer mit den Linux-Distributionen CentOS 5 und 6, Debian 5 und 6, Fedora, Gentoo, Mageia, Open Suse, RHEL 5 und 6, Scientific Linux, sowie Ubuntu 10.04, 11.04 und 12.04. Hinzu kommen noch Solaris- (SunOS) und BSD-Systeme. Zwar sperrt sich Rex nicht gegen andere Linux-Distributionen, der Anwender muss dann aber beim Aktivieren einer Aufgabe die Daumen drücken.

Rex selbst benötigt nur der Administrator auf seinem eigenen Rechner. Das kann sogar eine Windows- oder Mac-OS-X-Maschine sein, wichtig ist lediglich eine vorhandene Perl-Umgebung. Um Rex zu installieren, holt man zunächst (unter Linux mit dem Paketmanager) die Versionsverwaltung »git« und das Werkzeug »make« hinzu. Damit zapft man Github an und lässt ein für die Installation notwendiges Makefile generieren:

git clone https://github.com/krimdomu/Rex.git
cd Rex
perl Makefile.PL

Sehr wahrscheinlich tickern jetzt durch das Terminal ein paar von Rex vermisste Perl-Module, die man nachinstalliert – unter Linux in der Regel über den Paketmanager. Die eigentliche Installation erfolgt dann mit den beiden Kommandos:

make
sudo make install

»rex -version« sollte jetzt eine Versionsnummer ausspucken. Andernfalls ist etwas bei der Installation schiefgelaufen, meist fehlen benötigte Perl-Pakete.

Für alle unterstützten Linux-Distributionen stellen die Entwickler auch Repositories mit fertigen Rex-Paketen bereit. Wie man die Repositories einbindet, hängt von der Distribution ab. Das kostet unter Umständen mehr Tipparbeit als die hier vorgestellte Installation direkt aus den Quellen. Im Gegenzug bleibt Rex immer automatisch auf dem aktuellen Stand – zumindest halbwegs, denn zum Redaktionsschluss hinkten die Inhalte der Repositories etwas der Rex-Version aus Github hinterher. Wer die Repositories nutzen möchte, findet entsprechende Installationsanleitungen unter [2].

Sobald Rex einsatzbereit ist, sollte man noch kurz prüfen, ob alle Rechner im Netz per SSH erreichbar sind. Kann sich der Administrator dabei auf jedem Rechner mit den gleichen Benutzerdaten anmelden, vereinfacht dies das Schreiben der Tasks.

Laufleistung

Für einen ersten kurzen Test kann Rex ermitteln, wie lange die Computer im Netz bereits laufen. Diese sogenannte Uptime ermittelt für die beiden Rechner »marvin« und »zaphod« ein bündiges:

rex -e "say run 'uptime'" -H "marvin zaphod"-u hans -p 123456

Hinter »-e« steht in Anführungszeichen das auszuführende Kommando. »run 'uptime'« weist »rex« an, auf den entfernten Rechnern das Programm »uptime« zu starten. Das vorangestellte »say« sorgt dafür, dass die Ausgaben von »uptime« im Terminal des Administrators landen. Der Parameter »-H« listet in Anführungszeichen alle betroffenen Rechner auf. Anstelle der Rechnernamen darf man selbstverständlich auch wie in Abbildung 1 die IP-Adressen verwenden. Der für die Anmeldung an den beiden Computern benötigte Nutzername steht schließlich hinter »-u« , das Passwort hinter »-p« .

Abbildung 1: Beim ersten Rechner schlägt das Login fehl, was unter anderem die kryptische Fehlermeldung am Ende zur Folge hat. Der zweite Rechner gibt hingegen brav seine Uptime preis.

Damit man sich bei komplexeren Aufgaben nicht die Finger wund tippt, kann man alle notwendigen Informationen auch in einer Textdatei ablegen, dem sogenannten Rexfile. Für die Abfrage der Uptime befüllt man sie mit dem Inhalt aus Listing 1.

Am Anfang steht hinter »user« und »password« in Anführungszeichen der Benutzername und das Passwort, mit dem sich der Administrator auf allen Maschinen per SSH einloggt. Danach folgt die Definition einer Aufgabe. Was sie bewirkt, verrät die kurze menschenlesbare Beschreibung hinter »desc« in Anführungszeichen. »task« gibt der Aufgabe einen eindeutigen Namen – in Listing 1 heißt sie schlicht »uptime« . Was Rex beim Aufruf der Aufgabe machen soll, steht zwischen den geschweiften Klammern. In Listing 1 startet (»run« ) auf den externen Rechnern das Programm »uptime« , wobei dessen Ausgaben im Terminal des Administrators landen (»say« ). Das Ende einer jeden Zeile beziehungsweise Anweisung ziert schließlich noch ein Semikolon.

Die so definierte Aufgabe führt der Administrator mit folgendem Befehl aus:

rex -H "marvin zaphod" -f uptime.rex uptime

Hinter »-H« stehen wieder die Rechner, die eine Aufgabe mit dem Namen »uptime« abarbeiten sollen. Die Definition dieser Aufgabe erwartet »rex« in einer Datei namens »uptime.rex« . Wer »uptime.rex« in »Rexfile« umbenennt, kann sich den Parameter »-f« sparen. Apropos sparen: Ohne den Parameter »-H« würde »rex« die Aktion lokal, also auf dem Rechner des Administrators ausführen. Auf diese Weise kann der Administrator Rex auch zur Automatisierung von lokalen Aufgaben missbrauchen und von ihm beispielsweise ein Programm übersetzen oder eine Dokumentation zusammenstellen lassen. Alle Parameter für »rex« müssen übrigens immer zwingend vor dem Task-Namen stehen (im obigen Beispiel also vor »uptime« ). Andernfalls ignoriert »rex« sie.

Sicherheitsbewussten Administratoren dürften bei einem Blick auf Listing 1 sicherlich die Haare zu Berge stehen. Im Rexfile stehen tatsächlich der Benutzername und das Passwort im Klartext. Lässt man sie weg, muss man sie »rex« wieder mit den Parametern »-u« und »-p« übergeben. In der zum Redaktionsschluss erhältlichen Version wertete »rex« die beiden Parameter jedoch nicht immer zuverlässig aus. Als dritte Alternative kann man sich auch mit SSH-Schlüsseln authentifizieren. Dazu dienen die Zeilen:

user "hans";
private_key "/pfad/zum/private.key";
public_key "/pfad/zum/public.key";

am Anfang des Rexfiles mit den passenden Pfaden. Sofern die Schlüssel in den Standardverzeichnissen liegen (unter »$HOME/.ssh« ), reicht bereits die Angabe des »user« .