14.4 Logging

Wichtige Systeminfos

Ein weiteres interessantes Thema der Systemverwaltung ist das Logging. Vor allem bei Problemen kann man in den sogenannten Logfiles häufig die Ursache oder sogar Ansatzpunkte zu einer Lösung finden, etwa in Form einer Fehler- oder Statusmeldung eines Dienstes oder des Systems.

14.4.1 Logdateien

Am wichtigsten beim Logging sind zweifelsohne die Logdateien (Logfiles). In ihnen werden je nach Konfiguration schwere Fehler, wichtige Vorgänge oder unter Umständen auch unwichtige Informationen verzeichnet. Dabei haben viele Softwarepakete eigene Logdateien, die jedoch im Allgemeinen immer in /var/log oder diversen Unterverzeichnissen davon zu finden sind.

/var/log/messages

Die wichtigste Logdatei eines Systems ist /var/log/messages. Sie enthält so ziemlich alles, was der Kernel und die wichtigsten Systemprozesse mitzuteilen haben. So schreibt der Kernel eigene Meldungen in diese Datei, aber auch Anwendungen ohne eigene Logdateien haben die Möglichkeit, Nachrichten hineinzuschreiben. Betrachten wir im Folgenden einen Auszug aus der Datei:

Listing 14.44 Auszug aus /var/log/messages

...
Oct 12 11:44:44 localhost kernel: eth0: no IPv6      \
  routers present
...
...
Oct 12 14:59:00 localhost /USR/SBIN/CRON[2011]:      \
  CMD ( rm -f /var/spool/cron/lastrun/cron.hourly)
Okt 12 15:29:09 localhost su: FAILED SU (to root)
  jploetner on /dev/pts/4
Okt 12 15:29:16 localhost su: (to root) jploetner    \
  on /dev/pts/4
Okt 12 15:29:16 localhost su: pam_unix2: session     \
  started for user root, service su
Okt 12 15:31:42 localhost su: pam_unix2: session     \
  finished for user root, service su

Hier wird bereits der generelle Aufbau einer typischen Logdatei deutlich: Es werden das Datum und die genaue Uhrzeit vor der eigentlichen Nachricht angegeben. Im Falle von /var/log/messages folgt nach der Zeit der Name des Rechners, der die Meldung verursacht hat, dann der Name des aufrufenden Programms, gefolgt von der eigentlichen Meldung.

[zB]In unserem Fall enthält die Datei ausschließlich Meldungen eines einzigen Computers, der im Logfile als localhost [Fn. Der Name localhost bezeichnet immer den aktuellen, lokalen Rechner.] identifiziert wird. In unserem Beispiel finden wir Meldungen von cron, su und dem Kernel.

Ein fehlgeschlagenes Login

An der Ausgabe können wir zum Beispiel erkennen, dass der Benutzer jploetner einmal vergeblich versucht hat, sich per su-Kommando die root-Identität zu verschaffen, um als Systemadministrator Aufgaben zu übernehmen. Ein paar Sekunden später hat er es aber dann doch geschafft und war für ein paar Minuten in einer Session als root aktiv.

Aus den Meldungen des Kernels wurde eine beliebige herausgegriffen, in diesem Fall eine Meldung vom Bootvorgang, die beim Initialisieren der Netzwerkschnittstellen auftrat.

Eine typische Information ist bspw. der Eintrag des cron-Programms. Eine solche Logdatei bietet einen komfortablen Weg, eine Rückmeldung über die gestarteten Programme zu bekommen – in diesem Fall wurde einfach nur eine Statusdatei mit dem Kommando rm gelöscht, um die Festplatte nicht mit unnützen Daten zu verstopfen.

/var/log/wtmp – wer arbeitet(e) am System?

Die letzten Logins

Die wtmp-Datei enthält Informationen über die letzten Logins oder Login-Versuche für jeden einzelnen Nutzer. Leider ist die Datei in keinem für Menschen lesbaren (Text-)Format gespeichert, daher kann man diese Informationen nur über das lastlog-Programm anzeigen lassen:

Listing 14.45 Die letzten Logins mit lastlog

$ lastlog
Username  Port   From         Latest
root      tty2               Don Sep 18 16:35:01 2005
bin                           **Never logged in**
...
jploetner :0     console     Son Okt 16 11:46:30 2005
swendzel  pts/5  jupiter.wg  Son Okt 16 20:05:22 2005
...

Beim einfachen Aufruf von lastlog werden also alle Benutzer mit den entsprechenden Daten ausgegeben. Zu diesen Daten gehört einerseits der Zeitpunkt, andererseits aber auch der Ort, von dem aus sich der entsprechende Benutzer eingeloggt hat. Diese kann eine lokale Konsole wie beispielsweise tty2 oder auch ein fremder Rechner (jupiter.wg) sein, der eine virtuelle Konsole (pts/5) zum Einloggen nutzt.

Alle aktuell eingeloggten User

Eng im Zusammenhang mit diesem Logfile steht nun die Datei /var/run/utmp. [Fn. Auf einigen Systemen ist die utmp auch unter /var/log gespeichert. Da diese Datei jedoch Laufzeitparameter speichert, ist sie unter /var/run besser aufgehoben.] Sie enthält nämlich Informationen über die momentan eingeloggten Benutzer. Da auch diese Datei in einem unlesbaren Format geschrieben ist, kann man zum Beispiel das Programm w nutzen, um die entsprechenden Informationen auszulesen:

Listing 14.46 Alle eingeloggten User mit w

# w
13:40:18 up 1:12, 2 users, load average: 0.34,0.4,0.51
USER     TTY   FROM       LOGIN@ IDLE  JCPU  PCPU WHAT
jploetne :0    –          12:29  ?xdm?  5:24 0.00s -:0
root     pts/3 jupiter.wg 13:40  0.00s 0.00s 0.00s w

Hier sind also gerade zwei Benutzer – root und jploetner – eingeloggt. Dabei ist jploetner lokal auf der grafischen Oberfläche (:0, siehe Kapitel 24, »X11-Programme«) eingeloggt, während root von einem anderen Rechner aus eine virtuelle Konsole benutzt.

who und whoami

Es gibt mit who und whoami noch zwei weitere Programme, mit denen Sie herausfinden können, wer sich derzeit beim System angemeldet hat bzw. als wer Sie selbst gerade am System eingeloggt sind und an welchem Terminal Sie arbeiten. Im Wesentlichen sind die ausgegebenen Informationen dieselben wie beim zuvor besprochenen Programm w.

Listing 14.47 who und whoami

$ who
swendzel tty7         2010-08-28 10:16 (:0)
swendzel pts/0        2010-08-28 17:11 (:0.0)
swendzel pts/1        2010-08-28 17:41 (:0.0)
$ whoami
swendzel
$ echo $USER
swendzel

who liefert mit dem Parameter -q zudem die Anzahl der derzeit eingeloggten Benutzer:

Listing 14.48 Anzahl derzeit angemeldeter Benutzer anzeigen

$ who -q
swendzel swendzel swendzel swendzel
# Benutzer=4

Auch ein paar Eastereggs sind mit dem Programm möglich, wie das folgende Listing zeigt. Sobald Sie mindestens zwei textuelle Parameter angeben, nimmt who nämlich an, Sie hätten den Parameter -m angegeben, der bewirkt, das nur Ihr Login erscheint.

Listing 14.49 who-Eastereggs

$ who am i
swendzel pts/1        2010-08-28 17:41 (:0.0)
$ who wrote this book?
swendzel pts/1        2010-08-28 17:41 (:0.0)

14.4.2 /var/log/Xorg.log

Ein typisches Beispiel für eine anwendungsspezifische Logdatei ist /var/log/Xorg.log. Bei dieser Datei handelt es sich um eine Logdatei der grafischen Oberfläche X11. Sie enthält zahlreiche Informationen zum Start des sogenannten X-Servers. Vor allem bei unerklärlichen Abstürzen findet man hier häufig einen Anhaltspunkt zur Lösung des Problems.

14.4.2 syslogd

Zentrale Anlaufstelle

Als Nächstes wollen wir uns ansehen, wie die Nachrichten in die Logfiles kommen. Bei einer anwendungsspezifischen Datei wie der Xorg.log ist der Fall klar: Die Anwendung öffnet die Datei und schreibt die Nachrichten einfach hinein. Im schlimmsten Fall muss die Anwendung beim Logging mehrere Instanzen verkraften können, falls mehrere User dieses Programm gleichzeitig nutzen.

Für eine zentrale Logdatei wie die /var/log/messages ist eine solche Vorgehensweise jedoch nicht praktikabel. Schließlich könnte es sowohl zu Synchronisations- als auch zu Sicherheitsproblemen kommen. Vermischte oder von »bösen« Programmen gelöschte Meldungen wären möglich. Um solche Schwierigkeiten auszuschließen, braucht man eine zentrale Instanz zur Verwaltung der Logdateien. Unter Linux ist eine solche Instanz im syslogd realisiert.

Zugriff auf den syslogd

Um nun eine Nachricht in die System-Logfiles zu schreiben, muss ein Programmierer eine entsprechende Bibliotheksfunktion nutzen. Diese Funktion heißt syslog() und nimmt als Argumente eine Ganzzahl sowie den einzutragenden Text entgegen, der ähnlich wie bei printf() formatiert werden kann. Wie das Ganze nun aussehen kann, zeigt dieser Beispielcode:

Listing 14.50 Ein syslog()-Testcode

#include <syslog.h>

int main()
{
  /* Der erste Parameter von syslog() enthält einen
   * durch logische ODER-Verknpüfungen zusammengefügten
   * Bitwert. Im folgenden Absatz beschreiben wir die
   * Werte, die diese Bitmaske annehmen kann.
   */
  syslog( LOG_USER | LOG_INFO, "Nachricht\n" );

  return 0;

Hier wird der Text »Nachricht« an den syslogd übergeben, damit er diesen in die Logfiles schreibt. Dabei spezifiziert das erste Integer-Argument von syslog() die Priorität – den Loglevel – sowie die Herkunft der Nachricht und wird aus der ODER-Verknüpfung der Konstanten LOG_INFO und LOG_USER gebildet. Diese letzte Konstante – die Facility – zeigt im Beispiel an, dass die Nachricht von einem normalen Benutzerprogramm kommt. Sie kann jedoch unter anderem auch die folgenden Werte annehmen:

• LOG_AUTHPRIV
  Diese Facility wird bei sicherheitsrelevanten Authentifizierungsnachrichten benutzt. Ein Beispiel dafür wäre das su-Programm, über das sich Benutzer eine andere Identität verschaffen können, für die sie das Passwort kennen müssen.
• LOG_CRON
  Diese Facility wird von den weiter oben vorgestellten Diensten cron und at genutzt (Abschnitt cron-abschnitt bzw. at-Abschnitt).
• LOG_DAEMON
  LOG_DAEMON ist für alle Dienste gedacht, die keine eigene Facility besitzen. Es lässt sich jedoch sehr oft konfigurieren, welche Facility und welchen Loglevel ein bestimmter Dienst haben soll. Für eine bessere Differenzierung beim späteren Filtern nach dieser Facility können in einem solchen Fall auch die folgenden Facilities genutzt werden:
• LOG_LOCAL0 bis
• LOG_LOCAL7

Diese sind zwar vom Namen her weniger aussagekräftig, bieten aber lokal doch eine gewisse Flexibilität. Vorsicht bei der Bedeutungstreue ist nur dann geboten, wenn im Netzwerk geloggt wird.

• LOG_FTP
  FTP-Serverdienste können diese Facility nutzen, um ihre Lognachrichten zu speichern.
• LOG_KERN
  Logging des Kernels Diese Facility wird für Kernel-Nachrichten genutzt; ein normales Benutzerprogramm hat mit dieser Facility nichts zu tun. In den Linux-Implementierungen des syslog-Dienstes bedient ein eigener Prozess die Requests des Kernels: der klogd. [Fn. Daher bezeichnet man das entsprechende Paket auch als sysklogd, um diese Trennung zu betonen und von der traditionellen Implementierung aus der BSD-Welt zu unterscheiden, bei der es diese Trennung so noch nicht gab.] Er wurde aus Konsistenzgründen eingeführt und tut nichts anderes, als die Nachrichten des Kernels an den Syslog weiterzuleiten. Dieser verarbeitet diese Nachrichten dann ganz normal.
• LOG_LPR
  Druckerdienste wie der lpd oder cupsd setzen über diese Facility ihre Nachrichten ab.
• LOG_MAIL
  Entsprechend nutzen Maildienste wie exim, sendmail und postfix diese Log- Facility, um Meldungen in den Systemlogfiles zu speichern.
• LOG_NEWS
  Newsserver wie der cdpnntpd nutzen die LOG_NEWS-Facility.
• LOG_SYSLOG
  Diese Facility hingegen wird nur vom syslogd selbst genutzt und ist nicht für die Nutzung in normalen Benutzerprogrammen oder Systemdiensten bestimmt.
• LOG_USER (default)
  Wird keine Facility weiter angegeben, so ist LOG_USER die Vorgabe des Systems. Diese Facility wird auch für jedes nicht weiter spezifizierte Programm aus dem Userland genutzt.

Über die Facility kann ein Programm also dem syslogd mitteilen, woher eine Nachricht kommt. Inwieweit der Logging-Dienst diese Information zur Verarbeitung der Nachricht heranzieht, werden wir bei der Konfiguration des Dienstes noch näher erläutern. Im Folgenden soll jedoch erst einmal eine Übersicht über die unterschiedlichen Loglevel beziehungsweise Prioritäten einer Nachricht gegeben werden:

• LOG_EMERG
  Nachrichten dieser Priorität zeigen ein unbenutzbares System an.
• LOG_ALERT
  Bei dieser Gefahrenstufe muss sofort gehandelt werden.
• LOG_CRIT
  Nachrichten dieser Priorität bezeichnen einen kritischen Zustand.
• LOG_ERR
  Mit diesem Wert kann man einfache Fehlernachrichten belegen.
• LOG_WARNING
  Entsprechend bezeichnet LOG_WARNING einfache Warnungen, die also weniger kritisch sind.
• LOG_NOTICE
  Diese Nachricht bezeichnet eine normale, aber immer noch wichtige Nachricht.
• LOG_INFO
  Diese Stufe bezeichnet eine einfache Information ohne besondere Wichtigkeit, die auch ignoriert werden kann.
• LOG_DEBUG
  Debug-Nachrichten sind die am wenigsten relevanten Nachrichten und werden vor allem zum Debugging, also zum Überprüfen frisch geschriebener Software auf eventuelle Fehler genutzt.

Inwieweit diese Informationen nun relevant für die Verarbeitung der Nachrichten vom syslogd sind, wird spätestens bei der Konfiguration des Dienstes klar, die wir im Folgenden darstellen. Dazu müssen wir aber noch zwischen zwei Implementierungen differenzieren: dem Syslog und dem Syslog-ng.

syslog-ng

Der Syslog-ng-Dienst ist eine Alternative zum traditionellen Syslog und kann auf fast allen Distributionen nachinstalliert werden. Seine Vorteile sind höhere Flexibilität und die bessere I/O-Performance bei vielen Log-Einträgen. Diese erhöhte Flexibilität führt aber auch zu einer komplexeren Konfigurationsdatei. Daher wollen wir hier die Konfiguration des traditionellen Syslogs erläutern. Mit diesem Basiswissen und der Manpage zum Syslog-ng können Sie diesen dann ebenfalls an Ihre eigenen Bedürfnisse anpassen.

Die Datei /etc/syslog.conf

Den Syslog konfigurieren

Im Folgenden wollen wir also die Konfiguration des traditionellen, ursprünglich aus der BSD-Welt kommenden Syslogs über die Datei /etc/syslog.conf behandeln. Diese ist dabei als eine Ansammlung von unterschiedlichen Regeln zu verstehen, die bestimmen, wie mit Nachrichten aus bestimmten Facilities und Logleveln verfahren werden soll. Um diese Regeln nun zu erklären, werden wir im Folgenden einzelne, typische Beispiele erläutern.

Eine Regel ist eine Zeile, die einen Selektor enthält und eine Aktion definiert. Dabei können über einen Backslash (\gpBackslash) auch mehrere Zeilen zu einer Regel zusammengefasst werden.

Ein Selektor besteht aus mehreren Paaren der Form facility.log-level und spezifiziert damit die Herkunft einer Nachricht. Eine Aktion ist dann typischerweise die Datei, in die die Nachricht geschrieben wird. Es ist jedoch auch möglich, die gewählten Nachrichten mit @ auf einen fremden Rechner, eine lokale Konsole oder direkt an die Shell eines angemeldeten Users zu schicken. Außerdem kann man die Selektoren noch über Symbole wie =, !=, ! oder auch recht flexibel handhaben.

Listing 14.51 Was kommt in die Datei /var/log/critical.log?

*.=crit;kern.none            /var/log/critical.log

Diese Regel würde alle Nachrichten des Loglevels LOG_CRIT, ausgenommen alle Kernel-Messages, in der Datei /var/log/critical.log speichern. Dazu wurde im Selektor zuerst für die Facility eine Wildcard (}) eingesetzt, der Loglevel mittels = jedoch auf crit festgelegt. Die Wildcard von eben wird jedoch im nächsten Schritt durch kern.none wieder eingeschränkt, da dadurch eben Nachrichten der LOG_KERN-Facility ausgeschlossen werden.

Listing 14.52 Nachrichten des Kernels

kern.*                       /var/log/kern.log
kern.crit                    @gateway
kern.crit                    /dev/console
kern.info;kern.!err          /var/log/kern-info.log

Kernel-Logging

Diese Regeln sind schon etwas komplizierter. Die erste davon gibt an, dass alle Nachrichten der LOG_KERN-Facility in der /var/log/kern.log gesichert werden sollen.

Die zweite Regel leitet zusätzlich alle mindestens kritischen Nachrichten dieser Facility zum Rechner gateway. Es ist sinnvoll, zumindest solche kritischen Nachrichten noch extern zu speichern, da im Falle eines Festplattencrashs oder eines entsprechenden Treiberproblems die Meldungen nicht verloren gehen und noch nachvollzogen werden können.

Sollte allerdings der Netzwerk-Stack des Kernels ebenfalls ein Problem haben, so wird auch eine Weiterleitung nichts bringen. Daher sollen alle diese Nachrichten ebenfalls auf der Konsole des aktuell eingeloggten Users ausgegeben werden, die durch das Device /dev/console repräsentiert wird.

Schließlich sollen alle Nachrichten der Facilities LOG_INFO, LOG_NOTICE und LOG_WARNING in der /var/log/kern-info.log gespeichert werden. Mit kern.info wählt man alle Nachrichten aus, die mindestens den Loglevel LOG_INFO beitzen, und kern.!err schließt alle Meldungen aus, die als LOG_ERR oder wichtiger klassifiziert wurden, so dass die genannten übrig bleiben.

Listing 14.53 Auf die 12. Konsole!

mail.=info                   /dev/tty12

Dieser Ausdruck leitet alle Nachrichten der Facility LOG_MAIL im Level LOG_INFO an das Gerät /dev/tty12, die zwölfte Konsole, weiter. So können Nachrichten durch Drücken von Strg + Alt + F12 auf eben dieser Konsole gelesen werden. Durch Drücken von Strg + Alt + F7 oder Alt + F7 kommt man anschließend wieder auf die grafische Oberfläche oder durch Drücken einer anderen F-Taste eben wieder auf die entsprechende Textkonsole.

Ein Grund für die gesonderte Behandlung dieses einen Facility/Loglevel-Paares könnte der Umstand sein, dass zum Beispiel der TCP-Wrapper tcpd standardmäßig diese Einstellungen benutzt und man ihn von der »normalen« Behandlung des Mail-Loggings ausnehmen möchte.

Listing 14.54 Das restliche Mail-Logging

mail.*;mail.!=info           /var/log/mail.log

Möchte man alle anderen Nachrichten der LOG_MAIL-Facility in /var/log/mail.log sammeln, so genügt die folgende Regel. In ihr wird eigentlich nach Facility geloggt (mail.) und nur genau der Loglevel LOG_INFO ausgeschlossen (mail.!=info).

Listing 14.55 /var/log/messages

*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

/var/log/messages

In dieser Regel wird definiert, was alles in /var/log/messages geschrieben wird. Dies wären unter anderem alle Nachrichten der Loglevel LOG_INFO, LOG_NOTICE und LOG_WARNING. Nicht mit von der Partie sind Nachrichten der Facilities LOG_AUTH, LOG_AUTHPRIV oder auch LOG_CRON.

An diesem Beispiel waren vor allem zwei Dinge neu: Mehrere Facility-Bezeichnungen konnten durch Kommas getrennt werden, und es stand ein Minuszeichen vor dem Dateinamen. Dieses Zeichen verhindert das sofortige Schreiben neuer Nachrichten auf die Platte und ermöglicht durch die so mögliche Pufferung eine bessere Performance bei vielen Log-Einträgen.

Listing 14.56 Alle Notfälle an alle User schicken

*.=emerg                     }

Diese Regel schickt nun alle LOG_EMERG-Meldungen auf die Konsolen aller aktuell eingeloggten Benutzer. Dieses Feature wird ansonsten vom Programm wall angeboten, dessen Features wie immer auf der entsprechenden Manpage gefunden werden können.

Listing 14.57 Den Administrator benachrichtigen

*.alert                      root,jploetner

Remote-Logging

Hier geben wir an, dass alle Nachrichten vom Level LOG_ALERT oder wichtiger direkt auf die Konsolen der User

root und jploetner geleitet werden, so diese denn eingeloggt sind.

Listing 14.58 Remote-Logging komplett

*.                          @gateway

Besonders bei einem mittleren bis größeren Rechenzentrum oder einem Rechner-Cluster ist es oft sinnvoll, das gesamte Logging auf einem einzigen Rechner vorzunehmen. Mit einer solchen Regel würde man offensichtlich alles – der Selektor »*.« trifft keine Einschränkungen – auf den Rechner gateway weiterleiten.

Damit der syslogd auf dem entsprechenden Rechner auch Nachrichten aus dem Netzwerk annimmt, muss er mit der Option -r gestartet werden. Um dies zu automatisieren, muss diese Option im Startup-Skript des Dienstes eingetragen werden. Unter Debian wäre dies die /etc/init.d/sysklogd, in der man folgende Zeilen findet:

Listing 14.59 Den syslogd netzwerkfähig machen

# Options for start/restart the daemons
#   For remote UDP logging use SYSLOGD="-r"
SYSLOGD=""

Verführt man nun wie in dem Kommentar beschrieben, können alle Rechner im Netzwerk auf diesem System loggen. Wie Sie allerdings Ihr Netzwerk korrekt konfigurieren, ist wieder ein anderes Thema ... und wird in den nächsten Kapiteln besprochen.

14.4.3 logrotate

Logfiles aufräumen

Logdateien werden mit der Zeit immer größer, und übergroße Logdateien können potenziell ein System außer Gefecht setzen, indem sie irgendwann die ganze Festplatte füllen. Für dieses Problem gibt es das Programm logrotate. Wird eine Logdatei zu groß oder ist ein bestimmter Zeitabschnitt vorüber, so wird sie gepackt beziehungsweise gelöscht, und eine neue, leere Datei erstellt.

Dabei ist logrotate jedoch kein Dämonprozess – und dies hat auch seine Gründe. Es ist nicht notwendig, dass das Programm die gesamte Zeit im Hintergrund läuft und Speicher sowie Rechenzeit frisst. Stattdessen läuft logrotate als Cronjob, wird also vom cron-Dämon in einem regelmäßigen Intervall gestartet.

Viele Distributionen haben logrotate schon als Cronjob sinnvoll vorkonfiguriert, und wenn Sie in Ihrem Logverzeichnis /var/log ein paar durchnummerierte und gepackte Dateien finden, ist logrotate schon am Werk.

Listing 14.60 logrotate bei der Arbeit

$ls /var/log/messages*
/var/log/messages
/var/log/messages-20050510.gz
/var/log/messages-20050629.gz

Die Konfiguration

Sie konfigurieren logrotate über die Datei /etc/logrotate.conf. Eine Beispieldatei sieht folgendermaßen aus:

Listing 14.61 Eine einfache logrotate.conf

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# we want our log files compressed
compress

# packages drop log rotation information into this  directory
include /etc/logrotate.d

/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

Die Datei ist also wie folgt aufgebaut: Am Anfang der Datei stehen »globale« Optionen, die – falls keine speziellen, übergreifenden Regelungen getroffen wurden – für alle Logdateien gelten. In unserem Beispiel wäre mit diesen Optionen geregelt, dass die Dateien wöchentlich rotiert (also als Backup gespeichert), dass vier dieser Backups komprimiert vorgehalten und dass nach dem Rotieren die Logdateien selbst wieder leer initialisiert werden.

Außerdem werden bei diesem der Debian-Standardinstallation entnommenen Beispiel alle im Verzeichnis /etc/logrotate.d befindlichen Dateien eingebunden. So können Softwarepakete die Rotation ihrer Logfiles selbst bestimmen, indem sie einfach eine entsprechende Datei in dem Verzeichnis ablegen.

Die Logfiles an sich werden in den von geschweiften Klammern eingefassten Blöcken ähnlich dem hier aufgeführten /var/log/wtmp-Beispiel noch einmal genau spezifiziert. Erst jetzt weiß logrotate, welche Dateien genau überwacht werden sollen und ob eventuell globale Optionen wie im Beispiel teilweise geändert wurden.

14.4.4 logcheck

Gerade bei mehreren Servern oder großen Datenvolumen ist es umständlich, die Logdateien regelmäßig nach auffälligen Meldungen zu durchforsten. So kommt es oft zu der paradoxen Situation, dass Sicherheitsvorfälle zwar protokolliert, aber schlicht nicht beachtet werden.

Logfiles überprüfen

Abhilfe können Sie zum Beispiel durch den Einsatz von logcheck schaffen, einem Tool, das bei den meisten Distributionen erst noch nachinstalliert werden muss. Über die sehr einfache Konfigurationsdatei /etc/ logcheck/logcheck.conf teilen Sie dem Programm mit, welche der drei Alarmstufen paranoid, server und workstation Sie benutzen möchten und an welchen Mail-Account die Reports geschickt werden sollen.

Listing 14.62 Eine minimale logcheck.conf

# Controls the level of filtering:
# Can be Set to "workstation", "server" or "paranoid"
# for different levels of filtering. Defaults to
# paranoid if not set.
REPORTLEVEL="server"

# Controls the address mail goes to:
SENDMAILTO="admin@ihrefirma.de"

# Should the hostname of the generated mails be
# fully qualified?
FQDN=1

Standardmäßig werden nur die Dateien /var/log/syslog und /var/log/auth.log überprüft, Sie können aber über die Datei logcheck.logfiles, die sich wie die logcheck.conf meist im Verzeichnis /etc/logcheck befindet, weitere Logfiles hinzufügen.

Listing 14.63 logcheck

# these files will be checked by logcheck
# This has been tuned towards a default syslog install
/var/log/syslog
/var/log/auth.log

Intern arbeitet logcheck mit einer Datenbank von Filterausdrücken, die sich für die einzelnen Reportlevel in ihrer Ausführlichkeit unterscheiden. Diese Filter anzupassen ist im Allgemeinen jedoch unnötig, daher werden wir an dieser Stelle nicht weiter darauf eingehen.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.