Herrscher aller ReuĂźen

Muss der Administrator auf mehreren Rechnern dieselben Befehle ausfĂĽhren, kann er notfalls auf for -Schleifen oder selbst gebastelte Skripte zurĂĽckgreifen. Bequemer geht es jedoch mit einem geeigneten Werkzeug wie der Distributed Shell dsh.

vorlesen Druckansicht
Lesezeit: 4 Min.
Von
  • Dr. Udo Seidel

Verwaltet der Administrator Hunderte von Rechnern, ist die Aufgabe ohne Hilfsmittel nicht mehr zu bewältigen. Spezielle Managementsoftware hilft, belastet jedoch das Budget. Außerdem erfordern die gängigen Lösungen Installationen auf jedem einzelnen Rechner. Beides kann man mit der Distributed Shell dsh, auch bekannt als „Dancer’s Shell“, umgehen (siehe Kasten „Onlinequellen“).

Mehr Infos

Wer das Programm selbst kompilieren möchte, muss nacheinander die Pakete libdshconfig und dsh herunterladen und auf dem Administrationsrechner installieren. Manche Linux-Distributionen, darunter Debian, liefern kompilierte Pakete mit.

Als Transportmittel kann dsh die Secure Shell ssh oder die Remote Shell rsh verwenden – aus Sicherheitsgründen empfiehlt sich Erstere. Auf der Kommandozeile kann der Nutzer sie mit –r ssh auswählen. Tippfaule tragen die Zeile remoteshell=ssh in die dsh-Konfigurationsdatei ein, die normalerweise auf den Namen /etc/dsh/dsh.conf hört. Nutzer können individuelle Einstellungen in ~/.dsh/dsh.conf vornehmen.

Zusätzlich benötigt dsh ein „Inventar“: eine Liste aller zu administrierenden Rechner. Zwar kann man sie mit –m rechner,rechner,… auf der Kommandozeile übergeben. Üblicherweise legt man sie jedoch in /etc/dsh/machines.list ab. Die Syntax user@rechner und die Verwendung von IP-Adressen statt Rechnernamen sind ebenfalls zulässig.

Ruft man dsh –a “uname –r“ auf, klappert dsh alle Rechner nacheinander ab, loggt sich ein und führt den Befehl aus. Die Fragen nach dem jeweiligen Passwort kann man zum Beispiel durch Eintragen des Admin-Rechners in .rhosts unterbinden. Bei ssh sollte der Administrator lieber ein sichereres Verfahren auf Schlüsselbasis verwenden.

Klappt das Einloggen ohne Passwort-Abfrage, kann man mit der Option –c die Rechner parallel arbeiten lassen. Um die Last auf dem Admin-Rechner in Grenzen zu halten, sollte man jedoch mit –F <maximum> die Zahl der gleichzeitig laufenden Prozesse begrenzen. Mit waitshell=0 und forklimit=<maximum> lassen sich beide Angaben in der Konfigurationsdatei verewigen.

Soll nur ein Teil der Rechner eine Aufgabe durchführen, kann der Nutzer Gruppen definieren. Dazu muss er lediglich die Namen der Mitglieder in /etc/dsh/group/<gruppenname> oder ~/.dsh/group/<gruppenname> eintragen. Anschließend kann er etwa mit dsh –g linux-pcs “<kommando>“ ein Kommando nur auf den vorhandenen Linux-Rechnern ausführen lassen.

Bei paralleler Ausführung mit –c erscheinen die Ausgaben der einzelnen Rechner bunt durcheinandergewürfelt auf dem Schirm. Benötigt der Nutzer etwas mehr Übersicht, kann er dsh mit der Option –M oder showmachinenames=1 in der Konfigurationsdatei anweisen, jeder Ausgabe den Namen des Rechners voranzustellen, von dem sie stammt. Stören die Zusätze – etwa beim maschinellen Nachbearbeiten – kann man sie mit –H ausschalten.

In größeren Netzen dauern das Verbreiten des Kommandos und das Einsammeln der Ergebnisse entsprechend länger. Daher erlaubt es dsh, die Arbeit zu delegieren. Allerdings muss dazu das Programm auf allen Rechnern installiert sein, weil der Nutzer die Relay-Stationen nicht frei wählen kann. Lediglich die Zahl der Helfer kann er mit –N <nummer> einstellen.

Es gibt eine Reihe von Skripten mit vergleichbarer Funktion. SSH-Kenner finden beim Multihost SSH Wrapper mussh viele bekannte Optionen wieder. Wer Perl bevorzugt, wird bei clusterssh, der Global Shell gsh oder mass.pl fündig, Python-Fans bei Tentakel. Alle arbeiten ähnlich wie dsh mit einem Inventar und ssh oder rsh.

Außerdem lohnt es sich, einen Blick auf die Werkzeugsammlung von clusterit zu werfen. Sie enthält ebenfalls eine dsh, deren Aufrufsyntax jedoch von der beschriebenen abweicht. Außerdem gehören zum Paket das Programm barrier, mit dem sich die Prozesse auf den einzelnen Rechnern synchronisieren lassen. jsh und jsd unterstützen ein einfaches Job-Scheduling.

Dr. Udo Seidel
leitet eine Unix/Linux-Sysadmin-Gruppe bei der Amadeus Data Processing GmbH in Erding. (mr)