Jedes Linux-Universalsystem produziert große Mengen an Protokolldateien. Damit die Festplatte nicht überläuft und der Admin eine Chance zum Auswerten hat, kümmert sich ein rotierender Helfer um die Archivierung oder Entsorgung alter Protokolle.

Zugegeben nur sehr trockene Naturen schaffen es, zu Logfiles ein liebevolles Verhältnis zu entwickeln. Gleichwohl liefern die Protokolle in »/var/log« Administratoren genau die Informationen, um die Ursachen mysteriöser Fehlfunktionen zu ergründen. Fast noch wichtiger sind die unbemerkten Systemdetails, etwa ob alle Dienste korrekt laufen.

Wer neue Daemons aufsetzt oder auch nur ein kleines CGI bastelt, sieht in den Logs, was nicht funktioniert hat, und kann gezielt nachbessern. Misstrauische Zeitgenossen – und das sollten alle sein – überprüfen, ob unberechtigte Zugriffsversuche auf eigene Rechner stattfinden, die sie postwendend unterbinden.

Noch kreativere Leute benutzen die Informationen aus den Logs für Aktivitäten des Rechners. So könnte ein SMTP-Server eine IP-Adresse als berechtigt für den Versand von E-Mail ansehen, wenn im Logfile von dort ein erfolgreicher Login in eine Mailbox aufgezeichnet ist. (SMTP-after-POP und SMTP-after-IMAP, eine primitive, aber sehr verbreitete und Client-freundliche Alternative zu SMTP-Auth). Oder eine Firewall könnte eine IP-Adresse nach einem offensichtlichen Angriffsversuch automatisch per Paketfilter blockieren.

Selbst wer seine Logs nicht liest, kann dennoch über sie stolpern. Die produzierten Protokolldateien füllen die Festplatte mehr und mehr – oder zumindest die »/var«-Partition, wenn der Rechner vernünftig eingerichtet ist. Beides führt eines Tages dazu, dass der Computer seine Dienste einstellt.

Früher war eine der Aufgaben des Admin daher der verantwortungsvolle Umgang mit Logs – auswerten, archivieren, löschen. Mit dem Siegeszug von Linux auf dem Desktop ist das dem administrativ unbedarften Benutzer nicht mehr zuzumuten. Entsprechend hielten bereits vor Jahren vollautomatische Tools Einzug, die (ungelesene) Logdateien nach einer Weile wegwerfen.

Rotieren geht über Studieren

Ein Linux-System löscht eine Logdatei üblicherweise nicht einfach, sondern rotiert sie. Dazu nennt es eine Datei »XXX.log« zunächst in »XXX.log.0« (oder ähnlich) um. Das ist wichtig, weil das automatische Aufräumprogramm nicht weiß, ob und welche anderen Prozesse die Logdatei gerade geöffnet haben. Denn mit dem Öffnen einer Datei hat ein Prozess nämlich ein Filehandle auf genau diese Datei erhalten und schreibt immer in sie – egal ob ein anderer Prozess sie zwischenzeitlich umbenannt oder sogar gelöscht hat.

Nach dem Umbenennen sollte der Protokoll-Putzmann daher die Logdateien neu (leer) anlegen und sodann tunlichst alle betreffenden Prozesse informieren, dass sich die Protokolldateien geändert haben. Die schreibenden Prozesse müssen daraufhin ihre jeweiligen Logdateien schließen (die Filehandles aufgeben) und neu öffnen, woraufhin sie die aktuelle (noch leere) Version der Datei erhalten und füllen dürfen (Abbildung 1).

Daneben gibt es noch eine zweite Strategie (»copytruncate«), die sich oft als vorteilhaft erweist. Bei ihr wird das alte Logfile zunächst ebenfalls für die Archivierung kopiert, dann allerdings nicht gelöscht, sondern auf die Länge null gekürzt. Auf diese Weise ändert sich das Filehandle für den loggenden Prozess nicht, er muss nicht benachrichtigt werden und braucht auch kein neues, leeres File anzulegen.

Modulare Konfiguration

Um solche Mechanismen auf einem frei zusammenstellbaren und erweiterbaren System zu etablieren, haben findige Leute das Paket Logrotate [1] ersonnen. Es benutzt – wie viele andere zentrale Pakete – eine modulare Konfiguration. Die Kernvariablen setzt eine zentrale Konfigurationsdatei. Sie vermerkt, wie oft Logrotate Dateien rotieren soll, wie lange es die alten Protokolle aufbewahrt, ob es sie komprimieren soll (ab der zweiten Generation, denn die unmittelbar wegrotierte wird ja womöglich noch benutzt) und so weiter. Die zentrale Konfigurationsdatei heißt »/etc/logrotate.conf«.

Zusätzlich darf jedes installierte Softwarepaket bei seiner Installation ein Schnipsel Logrotate-Konfigurationsdatei ergänzen. Freilich soll es dabei nicht in die zentrale Datei hineinschreiben – das könnte den Keim für höchst unerfreuliche Inkonsistenzen legen. Dafür verwaltet Logrotate ein Konfigurationsverzeichnis namens »/etc/logrotate.d«.

Dort hinein schreiben Pakete ihre Logrotate-Minikonfigurationsdatei mit dem Namen des jeweiligen Pakets. Darin steht auch, was zu tun ist, wenn eine Logdatei rotiert ist. Bei einem Proxyserver könnte sein Beitrag zur Konfiguration »/etc/logrotate.d/squid« heißen.

01 weekly
02 rotate 4
03 create
04 compress
05 delaycompress
06 
07 /var/log/wtmp {
08   missingok
09   monthly
10   create 0664 root utmp
11   rotate 1
12 }
13 
14 include /etc/logrotate.d

01 /var/log/apache2/*.log {
02   missingok
03   rotate 52
04   notifempty
05   create 640 root adm
06   sharedscripts
07   postrotate
08     if [ -f /var/run/apache2.pid ]; then
09       /etc/init.d/apache2 restart >/dev/null
10     fi
11   endscript
12 }

01 /var/log/ipfilter-bulk.log {
02   size 20M
03   rotate 10
04   compress
05   compresscmd bzip2
06   compressext bz2
07   postrotate
08     /etc/init.d/sysklogd reload >/dev/null
09   endscript
10 }
11 
12 /var/log/ipfilter-high.log {
13   daily
14   rotate 730
15   olddir /var/log/ipfilter-old.d
16   nocompress
17   mail ich@meine.domain.de
18   mailfirst
19 }

Ein Beispiel

Listing 1 zeigt als Beispiel eine minimalistische »/etc/logrotate.conf«. Sie legt ein paar Vorgabewerte fest: Logrotate rotiert die Protokolldateien nach dieser Konfiguration wöchentlich und bewahrt insgesamt vier Vorversionen auf. Nach jeder Rotation legt es eine neue Logdatei an und komprimiert die Version aus der vorigen Woche.

Im Listing ist eine konkrete Logdatei angegeben, die Logrotate verwalten soll, nämlich »/var/log/wtmp«. Logrotate legt diese – abweichend von den gerade festgelegten Defaults – nur einmal im Monat neu an und übereignet sie »root« und der Gruppe »utmp«. Das Schlüsselwort »rotate 1« in Zeile 11 bewirkt, dass nur eine Vorversion erhalten bleibt, also die Version aus dem vorletzten Monat zum Abschuss freigegeben ist.

Nicht »logrotate.conf« bestimmt die Behandlung der anderen Logdateien, dies tun eigene Konfigurations-Bruchstücke aus »/etc/logrotate.d«, die die Include-Direktive in Zeile 14 hereinholt. Include ignoriert alle Backupdateien von Editoren, Files von Versionskontrollsystemen, Reste der Arbeit von Paketmanagern (etwa »*.rpmsave« oder »*.dpkg-old«) sowie Dateien mit der Endung ».disabled«.

Apache bekommt eine Extrabehandlung

In »/etc/logrotate.d« befindet sich als Beispiel die Datei »apache2« (Listing 2), die besondere Optionen für die Rotation der Apache-Logs bestimmt. Dieses Listing beginnt mit der Pfadangabe der Logdateien – hier ist Apache so eingerichtet, dass er alle Protokolle im Verzeichnis »/var/log/apache2« anlegt.

Zuerst gelten für alle Dateien aus dem »/var/log/apache2«-Verzeichnis die Voreinstellungen aus Listing 1: Logrotate rotiert die Dateien wöchentlich weg, komprimiert sie nach einer weiteren Woche und legt sie nach der Rotation neu an. Für die neuen, noch leeren Logs verpasst Zeile 5 aus Listing 2 besondere Zugriffsrechte, die Otto Normaluser die Einsicht verwehren.

Abbildung 1: Wird einem Prozess die Logdatei unter den Händen wegrotiert, schreibt er trotzdem weiter in die alte Datei. Erst nachdem der Prozess die Datei geschlossen und neu geöffnet hat, benutzt er die neu angelegte Logdatei.

Eine Vorgabe des Beispiels ist, dass die Protokolle des Webservers von besonderer Bedeutung für den Betrieb und die Bezahlung des Systems sind. Deshalb soll das System sie ein ganzes Jahr lang aufbewahren, nämlich in 52 Generationen zu je einer Woche. Wenn Apache mal aus irgendeinem Grund gar nicht starten will und darum keine Protokolldatei anlegt, erfolgt auch keine Rotation – dafür zeichnet das Schlüsselwort »notifempty« verantwortlich.

Listing 2 enthält außerdem Anweisungen darüber, wie Apache über die erfolgte Rotation der Logs zu informieren ist. Die Mitteilung erfolgt nach der Rotation – deshalb das Schlüsselwort »postrotate«. (Für vor der Rotation ist das Schlüsselwort »prerotate« zuständig). Nach dem Schlüsselwort folgen einige Zeilen Shellskript, abgeschlossen durch das Schlüsselwort »endscript«. Die Zeilen 8 bis 10 besagen: Falls Apache läuft, also wenn seine PID-Datei existiert, startet ihn das zugehörige Init-Skript komplett neu.

Abbildung 2: Ein Blick in das Verzeichnis »/var/log« zeigt die einzelnen Generationen der rotierten Logdateien.

Das Schlüsselwort »sharedscript« in Zeile 6 sorgt dafür, dass Logrotate dieses Info-Skript nur einmal aufruft, auch wenn mehrere Logdateien – in der Regel mindestens ein Access- und ein Error-Log – rotieren. Es startet, sobald die Rotation aller Logdateien abgeschlossen ist.

Mit allen Raffinessen

Die Einstellungen in den Listings 1 und 2 zeigen exemplarisch, wie die Daemons der gängigen Linux-Distributionen vorkonfiguriert sind. »logrotate« kann aber noch mehr – Listing 3 konfiguriert beispielsweise einen Paketfilter. Dieses Setup geht von der Prämisse aus, dass die Protokolle des Paketfilters in »ipfilter-bulk.log« landen. Die Datei hätte bei einem typischen Server den Drang, riesig zu werden, und entzöge sich durch ihre schiere Größe der manuellen Nutzung. Ein (hier nicht abgedrucktes) Skript sucht sich daher die relevanten kritischen Informationen raus und schreibt sie nach »ipfilter-high.log«.

Entsprechend behandelt Listing 3 beide Dateien sehr unterschiedlich. »ipfilter-bulk.log« rotiert es jedes Mal, wenn die Datei eine Größe von 20 MByte überschreitet, aber normalerweise nicht häufiger als ein Mal täglich. Logrotate komprimiert das alte Log mit »bzip2«. Da dieses Log über Syslog entsteht, muss sich der Daemon anschließend über die Änderung in den Protokolldateien informieren lassen. Das erfolgt mit Hilfe der »postrotate«-Direktive über das zugehörige Init-Skript – wie oben bei Apache.

Die »ipfilter-high.log« benötigt dagegen eine andere Behandlung. Weil sie eventuell auch zeitkritische Informationen enthält, rotiert »logrotate« sie täglich und verschickt sie zudem als E-Mail an den Administrator. Sollte dieser wesenswidrig auf der faulen Haut liegen, erhält er damit eine wirksame Erinnerung, sich um die Protokolle zu kümmern. Normalerweise verschickt »logrotate« die älteste Protokolldatei, hier aber dank der Direktive »mailfirst« die eben rotierte, also aktuelle.

Kritische Daten gehen nicht nach ein paar Wochen über den Jordan, sondern bleiben dem Admin für forensische Zwecke länger erhalten, im vorliegenden Falle 730 Tage oder zwei Jahre. Damit die alten Logfiles aber nicht das Verzeichnis »/var/log« verstopfen, verschiebt sie »logrotate« ins separate Verzeichnis »/var/log/ipfilter-old.d«.

Alternativen

Logrotate ist eine pragmatische Lösung für Systeme, die den Wartungsaufwand minimieren. Es ist unter Linux und FreeBSD weit verbreitet, aber nicht die einzige Variante, Protokolldateien zu rotieren. Bei Debian etwa kümmert sich das Sys(k)log-Paket in einem eigenen, über Cron aufgerufenen Skript um die Rotation der alten Logs. (jk)