Aus dem Nähkästchen geplaudert: Logrotate

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 }