Administrationsgallier

Während sich alle über das geradezu hefenkuchenartige Wachstum der Netzwerkwelt freuen und Strategen wie Intel, Microsoft und Cisco eine Allianz nach der anderen schließen, erprobt es sich im täglichen Kampf gegen das Chaos in unseren Netzen: ein kleines Grüppchen unerschrockener, gegen übliche Verkaufsargumente weitgehend immuner Systemverwalter.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 4 Min.
Von
  • Torsten Beyer
  • Kersten Auel

Die einzigen Verbündeten der tapferen Administrationskämpen sind kleine Hilfsprogramme und viel Selbstgestricktes. Da wäre zunächst mein erklärtes Lieblingsüberwachungsprogramm watcher, ein einfaches, gleichwohl pfiffiges System, das die Überwachung praktisch aller Aspekte eines Unix-Systems erlaubt. Eine Konfigurationsdatei enthält die Kommandos, die watcher innerhalb festgelegter Zeiträume ausführen soll (à la cron) sowie die gewünschten Reaktionen auf bestimmte Ergebnisse. Damit kann man ganz bequem eine Unmenge von Automatismen zur Systemüberwachung konfigurieren. Nach guter alter Unix-Manier läuft das Ganze primär mit regulären Ausdrücken, vielen Kommandos und anderen Unix-Segnungen. Abgestufte Reaktionen machen es auch möglich, Eskalationsstrategien mit watcher zu realisieren. So kann das System zunächst versuchen, einen Fehler ohne menschliches Zutun in den Griff zu bekommen und erst bei Erfolglosigkeit den Systemadministrator über das sich anbahnende Drama zu informieren. Zu bekommen ist das watcher-Paket zum Beispiel beim Eunet (ftp.germany.eu.net/pub/sysadmin/watcher).

"Immer mehr Computer" heißt im allgemeinen "immer mehr Benutzer", und das ist gleichbedeutend mit exponentiellem Wachstum von Anwendungen. Am geplagten Systemadministrator bleibt es hängen, Licht ins Dickicht der sich schlingpflanzenartig ausbreitenden Pfadnamen, Environment-Variablen, rc-Dateien und dergleichen mehr zu bringen. Jede Anwendung hat ja bekanntlich ihre eigene Vorstellung davon, wie ein gescheites Unix-System zu administrieren sei. Modules lindert hier Schmerzen.

Simpel gesagt handelt es sich bei Modules um ein System, mit dem man anwendungsspezifische Konfigurationen der oben genannten Art standardisieren kann. Alle Einstellung für eine Anwendung (beispielsweise X11) werden in einem sogenannten Modules-File abgelegt. Anwender, die das jeweilge System nutzen (sollen), tragen nur module add in ihre privaten .{c,s,k}shrc-Dateien ein. Auf diese Weise belastet man die Anwender nicht mit vielen (für die meisten wohl eher unverständlichen) Shell-Spezifika. Darüber hinaus kann der Administrator eine neue Version einspielen, alle Umgebungseinstellungen zentral in einer Datei ändern, und es funktioniert überall. Eine der Bezugsquellen findet sich in Finnland.

Bisweilen soll es ja vorkommen, daß Netzprobleme gar nicht auf einen einzigen Computer beschränkt sind, sondern aus der Dynamik mehrerer miteinander kommunizierender Rechner entstehen. Da hilft dann nur der Blick ins Netz. Dabei stellt man meist fest, daß eigentlich Informationen von vor fünf Minuten wichtig wären. Ein ganz schmuckes Set von Werkzeugen für derartige Aufgaben ist netlog, das es über tcplogger und udplogger ermöglicht, alle Verbindungen auf einem gegebenen Subnetz aufzuzeichenen.

Wenn in bezug auf die Systemadministration wirklich der GAU ausbricht, steht in den meisten Fällen das Thema Sicherheit ganz oben auf der Liste der Problemkandidaten. Unix-Rechner, die schon ewig laufen und durch -zig Hände gegangen sind, haben meist eine Unzahl von Sicherheitsschwachstellen, die sich mit der Zeit eingeschlichen haben und in Vergessenheit geraten sind. Über die Sicherheitslücken fabrikneuer Systeme will ich mich gar nicht erst ereifern. Eine Vielzahl von Werkzeugen können dem Systemadministrator helfen, die üblichen Schwachstellen zu finden. Einer der feineren Kandidaten dieser Gilde ist tiger, das einen recht vollständigen Satz von Prüfroutinen für die gängigen Unixe bietet.

Abschließend ein Werkzeug, das kleinen Gruppen von Administratoren hilft, sich untereinander zu koordinieren: trouble (ftp.germany.eu.net/pub/sysadmin/trouble) funktioniert ein bißchen wie news (bloß besser :-) und bietet im wesentlichen eine kleine Datenbank, in der Fehlermeldungen inklusive Kommentaren verwaltet werden können. Durch den aus den News bekannten Threading-Mechanismus entstehen zusammengehörige 'Diskussionen' zu einem Fehler. trouble ist kein ausgefuchstes Troubleticket-System, reicht aber für sehr kleine Installationen und wenig komplexe Umgebungen voll aus. (ka)