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 zur Lösung des Problems in Form einer Fehler- oder Statusmeldung eines Dienstes oder des Systems finden.
14.4.1 Die Logdateien 

Der wichtigste Aspekt beim Logging ist zweifelsohne der der Logdateien (Logfiles). In Logdateien 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 unter /var/log oder diversen Unterverzeichnissen zu finden sind.
/var/log/messages
Die wichtigste Logdatei eines Systems ist die /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 in diese Datei zu schreiben. Betrachten wir im Folgenden einen Auszug aus der Datei:
... 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
Listing 14.44 Auszug aus /var/log/messages
Hier wird bereits der generelle Aufbau einer typischen Logdatei deutlich: Es werden das Datum und die genaue Uhrzeit vor der eigentlichen Nachricht angegeben. Im Fall der /var/log/messages folgt nach der Zeit der Name des Rechners, der die Meldung verursachte, dann der Name des aufrufenden Programms, gefolgt von der eigentlichen Meldung.
In unserem Fall beinhaltet die Datei ausschließlich Meldungen eines einzigen Computers, der im Logfile als localhost [Der Name localhost bezeichnet immer den aktuellen, eigenen Rechner.] identifiziert wird. In unserem Beispiel finden wir Meldungen von den Programmen cron, su und dem Kernel. |
Ein fehlge- schlagenes 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. So eine Logdatei ist ein komfortabler 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 nicht mit unnützen Daten die Festplatte 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:
$ 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 ...
Listing 14.45 Die letzten Logins mit lastlog
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. Das kann eine lokale Konsole wie beispielsweise tty2 sein oder auch ein fremder Rechner (jupiter.wg), der eine virtuelle Konsole (pts/5) zum Einloggen nutzt.
Alle aktuell eingeloggten User
Eng im Zusammenhang mit diesem Logfile steht nun die /var/run/utmp. [Auf einigen Systemen ist die utmp auch unter /var/log gespeichert. Da diese Datei jedoch Laufzeitparameter speichert, ist sie unter /var/run besser aufgehoben.] Diese Datei speichert 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:
# 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
Listing 14.46 Alle eingeloggten User mit 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 am System eingeloggt 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.
$ 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
Listing 14.47 who und whoami
who liefert mit dem Parameter -q zudem die Anzahl der derzeit eingeloggten Benutzer:
$ who -q swendzel swendzel swendzel swendzel # Benutzer=4
Listing 14.48 Anzahl derzeit angemeldeter Benutzer anzeigen
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.
$ 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)
Listing 14.49 who-Eastereggs
/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 Der 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 durch den 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 einen Integerwert sowie den einzutragenden Text entgegen, der ähnlich wie bei printf() formatiert werden kann. Wie das Ganze nun aussehen kann, zeigt dieser Beispielcode:
#include <syslog.h>
int main()
{
syslog( LOG_USER | LOG_INFO, "Nachricht\n" );
return 0;
}
Listing 14.50 Ein syslog()-Testcode
Hier wird der Text »Nachricht« an den syslogd übergeben, damit er diesen in die Logfiles schreibt. Dabei spezifiziert das erste Integer-Argument von syslog() offensichtlich 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. Die Konstante 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 später noch vorgestellten Diensten cron und at genutzt. Diese Dienste erledigen automatisiert und selbstständig verschiedene Aufgaben im System, wodurch die eine eigene Facility rechtfertigende Bedeutung dieser Dienste gegeben ist.
- 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
- LOG_FTP
FTP-Serverdienste können diese Facility nutzen, um ihre Lognachrichten zu speichern.
Logging des Kernels
- LOG_KERN 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. [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.] Dieser Dienst wurde aus Konsistenzgründen eingeführt und macht 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 dabei eine Alternative zum traditionellen Syslog. Der Dienst kann auf fast allen Distributionen nachinstalliert werden. Die Vorteile des Dienstes sind seine höhere Flexibilität und die bessere I/O-Performance bei vielen Log-Einträgen. Die erhöhte Flexibilität führt aber zu einer komplexeren Konfigurationsdatei. Daher wollen wir mit der Konfiguration der /etc/syslog.conf die Konfiguration des traditionellen Syslogs erläutern. Mit diesem Basiswissen und der Manpage zum Syslog-ng können Sie diesen dann einfach an die 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. Die ganze Datei 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 Regel nun zu erklären, werden wir im Folgenden einzelne, typische Beispiele erläutern.
Eine Regel ist dabei wie folgt aufgebaut: Sie steht in einer Zeile, die einen Selektor enthält und eine Aktion definiert. Dabei können über einen Backslash (\) 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. Möglich ist jedoch auch, die gewählten Nachrichten mit @ auf einen fremden Rechner, eine lokale Konsole oder direkt auf die Shell eines angemeldeten Users zu schicken. Außerdem kann man die Selektoren noch über Symbole wie =, !=, ! oder auch * recht flexibel handhaben.
*.=crit;kern.none /var/log/critical.log
Listing 14.51 Was kommt in die Datei /var/log/critical.log?
Diese Regel würde alle Nachrichten des Loglevels LOG_CRIT, ausgenommen aller 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.
kern.* /var/log/kern.log kern.crit@gateway kern.crit/dev/console kern.info;kern.!err /var/log/kern-info.log
Listing 14.52 Nachrichten des Kernels
Kernel-Logging
Diese Anweisungen sind schon etwas komplizierter. Die erste Regel gibt an, dass alle Nachrichten der LOG_KERN-Facility in der /var/log/kern.log gesichert werden sollen.
Die zweite Zeile und damit die zweite Regel leitet zusätzlich alle mindestens kritischen Nachrichten dieser Facility zum Rechner gateway. Es ist sinnvoll, zumindest diese 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 mit kern.!err schließen wir alle Meldungen aus, die als LOG_ERR oder wichtiger klassifiziert wurden, sodass die genannten übrig bleiben.
mail.=info /dev/tty12
Listing 14.53 Auf die 12. Konsole!
Dieser Ausdruck leitet alle Nachrichten der Facility LOG_MAIL im Level LOG_INFO auf das Device /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 Sonderbehandlung 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.
mail.*;mail.!=info /var/log/mail.log
Listing 14.54 Das restliche Mail-Logging
Möchte man alle anderen Nachrichten der LOG_MAIL-Facility in der /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).
*.=info;*.=notice;*.=warn;
auth,authpriv.none;
cron,daemon.none;
mail,news.none-/var/log/messages
Listing 14.55 Die /var/log/messages
/var/log/messages
In dieser Regel wird definiert, was alles in die /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 Facilities konnten durch Kommas getrennt werden, und es stand ein Minus vor der Datei. Dieses Minus 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.
*.=emerg *
Listing 14.56 Alle Notfälle an alle User schicken
Diese Regel schickt nun alle LOG_EMERG-Meldungen auf die Konsolen aller aktuell eingeloggten Benutzer. Dieses Feature wird vom wall-Programm angeboten, dessen Features wie immer auf der entsprechenden Manpage gefunden werden können.
*.alertroot,jploetner
Listing 14.57 Den Administrator benachrichtigen
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.
*.* @gateway
Listing 14.58 Remote-Logging komplett
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:
# Options for start/restart the daemons
# For remote UDP logging use SYSLOGD="-r"
SYSLOGD=""
Listing 14.59 Den syslogd netzwerkfähig machen
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 die Logdatei gepackt beziehungsweise gelöscht, und eine neue, leere Logdatei wird erstellt.
Dabei ist logrotate jedoch kein Dämonprozess – und das 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.
$ls /var/log/messages* /var/log/messages /var/log/messages-20050510.gz /var/log/messages-20050629.gz
Listing 14.60 logrotate bei der Arbeit
Die Konfiguration
Sie konfigurieren logrotate über die Datei /etc/logrotate.conf. Eine Beispieldatei sieht folgendermaßen aus:
# 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 }
Listing 14.61 Eine einfache logrotate.conf
Die Datei ist also wie folgt aufgebaut: Am Anfang der Datei stehen »globale« Optionen, die – falls keine speziellen, überdeckenden Regelungen getroffen wurden – für alle Logdateien gelten. In unserem Beispiel wäre mit diesen Optionen geregelt, dass die Logfiles wöchentlichrotiert (also als Backup gespeichert) werden, dass vier dieser Backups komprimiert vorgehalten werden und dass nach dem Rotieren die Logfiles 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.
# 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
Listing 14.62 Eine minimale logcheck.conf
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.
# these files will be checked by logcheck # This has been tuned towards a default syslog install /var/log/syslog /var/log/auth.log
Listing 14.63 logcheck
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.