© Sergey Nivens, 123RF

Niemand nimmt dem Admin das Dokumentieren einer Systemlandschaft ab. Doch viele Kapitel können nützliche Programme wie Etckeeper oder Sosreport beisteuern. Dieser Artikel zeigt, wie einzelne Tools Hand in Hand arbeiten und zu einer umfassenden Dokumentation beitragen.

Dokumentieren ist eine wenig spannende, noch dazu mühsehlige Arbeit und daher nicht besonders beliebt. Tools können den Prozess aber deutlich erleichtern. Es fällt zwar am Ende kein perfekt geschriebenes Handbuch aus dem Drucker, doch auch abseits einer teuren Inventarisierungs-Suite nehmen kleine Helfer viel Schreibarbeit ab.

Ersetzen können sie den Menschen aber nicht, denn sie tragen bestenfalls zusammen, welche Komponenten und Einstellungen die Systemlandschaft verwendet, wissen aber nichts über das Warum. Automatisch zusammenstellen lassen sich demnach Infos über Netzwerke, Useraccounts, Dienste, Kernel oder Hardware.

Arbeitsweise

Den Ist-Zustand dokumentieren zahlreiche Dateien in »/etc« : NFS-Freigaben, Syslog, E-Mail-Einstellungen, Repositories für Systemupdates und vieles mehr. Diese Dateien sind also die erste Quelle für Konfigurations-Informationen. Ergänzend kann der Admin auf Reportingtools zurückgreifen, die Prozesse, Mounts, Kernelmodule, Hardware-Umgebung oder Speicherauslastung abfragen und die Resultate zusammenstellen. Kombiniert er die einzelnen Tools, ergibt sich ein detaillierter Systembericht. Die hier gezeigten Werkzeuge können einen solchen Bericht auf Wunsch auch automatisiert im Hintergrund zusammenstellen.

Manchmal existiert bereits ein ausgefeiltes Konfigurationsmanagement, das scheinbar dieselben Daten bearbeitet. Es gibt dabei aber einen wichtigen Unterschied: Diese Programme geben eine Konfiguration vor, die später der Rechner übernehmen wird – sie beschreiben also ein Soll. Die Tools, um die es in diesem Beitrag geht, erfassen und beschreiben dagegen den Ist-Zustand.

Kleine Änderungen erledigt der Admin auch gerne mal ohne Changeprozess. Das rächt sich vielleicht beim nächsten Update oder Reboot, wenn Dienste nicht mehr starten. Natürlich hat niemand etwas verändert.

Änderungen entdecken

Dieses Problem löst der Admin schnell, indem er alle Konfigurationsdateien unter Versionskontrolle stellt. Das Geheimnis der Versionierung gehört zwar den Kollegen der Software-Entwicklung, funktioniert aber auch für die Dokumentation. Danach wird datei- und zeilengenau abgerechnet: Was wurde wann und von wem (wenn der Autor korrekt eingepflegt ist) geändert?

Im Interesse einer höheren Verfügbarkeit ist es sinnvoll, das Versionsarchiv auf einer zentralen Maschine zu platzieren. Dabei sollte man jedoch auch die Sicherheit nicht vernachlässigen, da unter »/etc« auch kritische Dateien liegen, die besser nur Root bekannt sind. Korrekte Dateirechte und Verschlüsselung bei der Übermittlung sind also Pflicht!

Linux-Distributionen, die sich an den Filesystem Hierarchy Standard [1] halten, legen Konfigurationsdateien wie beschrieben unter »/etc« ab. Aber exotische oder ältere Programme nutzen auch gerne mal »/usr/local/etc« oder verstecken sich unter »/opt« . Dieser Umstand ist beim Einrichten der vorgestellten Tools zu beachten.

Etckeeper

Ein wichtiges Tool, das beim automatisierten Dokumentieren helfen kann, ist Etckeeper [2]. Es protokolliert und versioniert alle Änderungen an Konfigurationsdateien, außerdem stellt es frühere Versionen im Fehlerfall wieder her. Das Tool geht als Favorit ins Rennen, weil es gleich in mehreren Kategorien Punkte sammelt: Neben einer modernen Versionsverwaltung arbeitet es auch mit den gängigen Paketmanagern zusammen (»yum« , »apt« , »zypper« , »pacman« , »pkgng« ) und bietet Sicherheit für schützenswerte Daten. Zudem wird es weiterentwickelt.

Über Etckeeper hatte das Linux-Magazin bereits 2011 berichtet [3]. Seitdem avancierte es zum Standardwerkzeug vieler Admins und zum festen Bestandteil der großen Linux-Distributionen. Etckeeper bietet eine Vielzahl an Optionen: Sogar bei der Versionierungssoftware lässt Etckeeper dem Admin die freie Wahl. Mit Git ist er auf der sicheren Seite, viele Distributionen entscheiden sich genauso. Git ist von Hause aus ein verteiltes System und deshalb lässt sich auch auf einfache Weise das lokale »/etc« in ein entferntes Repository einchecken.

Leider beachtet Etckeeper ausschließlich Dateien in »/etc« und ignoriert alle anderen Konfigurationsfiles. An dieser Stelle kann sich der Anwender aber mit Softlinks behelfen, die andere Verzeichnisse und Dateien unter »/etc« einblenden, damit sie nun unter das Augenmerk des Tools fallen. Mit »yum« oder »apt-get« ist Etckeeper dann schnell installiert (Listing 1).

01 yum install etckeeper
02 etckeeper init
03 etckeeper commit "erster checkin"
04
05 # nach vielen Änderungen...
06 etckeeper commit "geplante Wartung"

Ein Webserver kann nun das Repository unter »/etc/.git« anzeigen (Vorsicht bei kritischen Verzeichnissen und freizügigen Webservern) oder auf andere Maschinen klonen. Letzteres bietet sich an, wenn ein bestehendes System mit einer Entwicklungs- oder Staging-Umgebung synchronisiert werden soll.

In bester Linux-Manier ist »etckeeper« ein reines Kommandozeilentool. Für die Bedienung ist das zwar optimal, aber die Auswertung gelingt über eine Webseite leichter. Glücklicherweise gibt es eine Vielzahl von Webinterfaces für Git-Repositories. Als besonders vorteilhaft haben sich »gitalist« [4] und »cgit« [5] erwiesen. Beide geben tiefe Einblicke in die gesammelten Daten eines Repository (Abbildung 1).

Abbildung 1: Mit »gitalist« durch die Systemänderungen stöbern.

Für Etckeeper existiert eine ganze Reihe nützlicher Erweiterungen. So fragt etwa »gitcal« [6] Etckeeper nach den letzten Änderungen und formatiert die Antwort im I-Cal-Format:

gitcal /etc/.git > changes.ics
echo "" | mutt -s "$HOSTNAME: etckeeper" -a changes.ics -- it.kalender@example.com

Damit lassen sich Google Calendar oder Outlook mit Leben füllen (Abbildung 2). Als Eye-Candy zeigt die Heatmap in Abbildung 3 die Häufigkeit von Änderungen farblich an. Github bietet dieses Feature seit 2013 für alle öffentlichen Repositories an. Der hier gezeigte Screenshot basiert allerdings auf der Javascript-Bibliothek Cal-heatmap [7].

Abbildung 2: Änderungen am System werden an Google Calendar berichtet.

Abbildung 3: Die Farbwerte der Heatmap demonstrieren die Häufigkeit von Systemänderungen.

Changetrack

Zu den Senioren unter den Tools, die Konfigurationsänderungen loggen, gehört Changetrack [8]. Ein kleiner Nachteil ist, dass es auf die steinalte Versionsverwaltung RCS aufsetzt und sonst eher einen minimalistischen Ansatz verfolgt. Vorteilhaft ist dagegen der niedrige I/O-Fingerprint, da Changetrack weniger Festplattenzugriffe für die Arbeit benötigt als seine Kollegen. Damit eignet sich Changetrack gut für eingebettete Systeme mit Flashspeichern, die nicht viel Platz bieten und nur eine begrenzte Anzahl Schreiboperationen erlauben.

Changetrack liegt zumindest bei Debian als Paket vor, aber auch die Installation mittels Tarball sowie die Nutzung sind trivial (Listing 2). Eine optisch wenig ansprechende Weboberfläche »changeweb.cgi« liefert Changetrack zwar mit, der Admin muss sie aber noch händisch ins »cgi-bin« -Verzeichnis des Webservers bewegen.

01 apt-get install changetrack
02 echo '@ /etc -name "*.conf"' >> /etc/changetrack.conf
03 changetrack -r -m "erster commit"
04
05 # nach einem langen Wartungstag...
06 changetrack -r -m "geplante Updates"

Blueprint

Einen Schritt weiter geht Blueprint [9] und versioniert zusätzlich zu »/etc« auch das restliche Dateisystem (mit Ausnahme von Pseudodateien im »/proc« oder im »/sys« ). Außerdem erzeugt es eine Liste der installierten Pakete. Durch diese Snapshots erreicht Blueprint sein eigentliches Ziel und macht das Reverse Engineering von Linux-Servern möglich.

Zudem kann Blueprint sein Wissen über das Linux-System als Puppet-Modul oder Chef-Kochbuch exportieren. Durch die vielen Informationen sind die Snapshots von Blueprint natürlich riesig und ein Diff lässt dann gerne auf sich warten. Blueprint verwendet ebenso wie Etckeeper als Backend Git, daher lassen sich die oben schon beschriebenen Webinterfaces verwenden.

Die Installation von Blueprint erwartet Python 2.6 (oder höher). Der Installateur klont ein Git-Repository und hantiert dann mit der üblichen Kombination aus »make« und »make install« . Anschließend wertet Listing 3 mit Blueprint ein beispielhaftes Update aus.

01 blueprint create ANFANG
02 # ein paar Updates später...
03 blueprint create ENDE
04 blueprint diff ANFANG ENDE  DIFF
05
06 # was hat sich verändert?
07 blueprint show-files DIFF
08
09 # bitte als Puppet-Modul
10 blueprint show --puppet DIFF

Die zweite Schublade des Doku-Werkzeugkastens ist gefüllt mit Reportingtools. Diese Werkzeuge kennen die vielfältigen Verstecke von Diagnose- und System-Informationen in einem Linux-System und sammeln dort alle möglichen Fakten und präsentieren sie als Webseite oder in Textform.

Cfg2html

Der Name ist Programm: »cfg2html« [10] holt Werte aus dem letzten Winkel des Systems und erstellt daraus eine lange und druckbare HTML-Datei. Die Menge der Informationen ist über so genannte Kollektionen steuerbar. Cfg2html unterstützt neben Linux auch die Unix-Derivate HPUX, AIX, Sun OS und BSD. Aber lediglich für RPM-basierte Distributionen steht ein fertiges Paket bereit. Einziges Manko: Der HTML-Report ist optisch kein Leckerbissen. Für das Beispiel in Abbildung 4 wurde mit CSS äußerlich etwas nachgeholfen. Der Report wird mit dem Kommando

cfg2html -o /var/www/html/

erstellt und ist nach ungefähr 15 Sekunden fertig.

Sosreport

Sosreport [11] ist der Allrounder, der über Plugins auch Datenbanken, Mailerdaemons, IPsec, VMware oder KVM anzapft. Dadurch, dass der Admin aus über 100 Plugins wählen kann, lässt sich das Ergebnis exakt auf die eigene Umgebung anpassen.

Abbildung 4: Detaillierter geht’s kaum: Cfg2html bei der Arbeit.

Grundsätzlich will Sosreport aber gar keinen besonders schicken Bericht erstellen, sondern Systeminformationen zusammentragen, die einen Techniker bei der Fehlersuche unterstützen. Sosreport ist das Standardtool für Berichte über Fehler bei Red Hat Enterprise Linux schon seit 2007. Die Version 3 unterstützt jetzt freundlicherweise auch Debian und bindet außerdem bereits die ersten Clouddienste mit ein.

Dummerweise verteilt Sosreport die von ihm gesammelten Informationen auf eine Unmenge kleiner Dateien, sodass das Endergebnis gerne mal aus über 1000 Schnipselchen besteht. Der Aufruf von »sosreport« startet den Reportingprozess mit den jeweils voreingestellten Plugins. Das Resultat liegt zum Schluss schließlich unter:

/tmp/sosreport-$HOSTNAME-$DATUM.tar.xz

Erst das Kommando

sosreport --batch --build --tmp-dir=/var/www/html/

legt die einzelnen Dateien nebst Übersicht im Document-Root-Verzeichnis des Apache ab. Auch hier ist Vorsicht wegen sicherheitskritischer Dateien geboten.

Hardinfo

Deutlich Hardware-lastiger füllt Hardinfo [12] den Report. Neben CPU-Features, I/O-Ports und Speicheradressen wertet das Tool auch ein paar Benchmarks der CPU und FPU aus. Über vier Module lässt sich die Menge der Daten leider nur wenig beeinflussen.

Hardinfo punktet besonders in der Kategorie Einfachheit. Installation und Start gehen leicht von der Hand, der erste Bericht ist bereits nach wenigen Minuten fertig:

yum install hardinfo
hardinfo --generate-report --report-format=html > report.html

Aus den Ausgaben der hier vorgestellten Tools lässt sich mit ein paar weiteren Werkzeugen automatisch – sprich Cron-gesteuert – ein schicker Report erzeugen. Als Formate eignen sich HTML, Latex oder Ascii-Doc [13]. Aus naheliegenden Gründen sollte man die IT-Dokumentation auf einem von der Stromversorgung unabhängigen Medium speichern – also auf Papier oder per USB-Stick.

Fazit

Zu bedenken bleibt allerdings, dass die Konfigurationssammler nichts über Sinn und Zweck der Installation in Erfahrung bringen können. Auch Notfallpläne, Wartungsintervalle, HA-Konzepte, Verantwortlichkeiten, Ansprechpartner und Eskalationswege werden so nicht erfasst. Überhaupt kommen Abläufe und Prozesse zu kurz. Die Tools dokumentieren keine Schnittstellen, keine SLAs, keine Backupkonzepte und auch keine Risikobewertungen.

Außerdem sind applikationsspezifische Einstellungen in der Regel zu speziell für solche Tools: Die Konfiguration von MySQL, Apache, PHP oder gar von Applikationen, die auf diesen Infrastruktur-Komponenten aufbauen, muss der Anwender also oft anders dokumentieren. Nur er kann diese Dinge beisteuern, nur er kann schließlich auch alles gliedern und sortieren.

Trotzdem legen die hier vorgestellten Tools den Grundstein für eine gute Dokumentation. Besonders empfehlenswert sind »etckeeper« für das Aufzeichnen von Konfigurationsänderungen und Cfg2html für eine Hard- und Software-Übersicht. Beide sparen viel Zeit für das Suchen und Abtippen wichtiger Systeminformationen.