Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
5 Der Kernel
6 Die Grundlagen aus Anwendersicht
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP
20 DNS-Server
21 Secure Shell
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in die Sicherheit
33 Netzwerksicherheit überwachen
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Die Buch-DVDs
F Glossar
G Literatur
Stichwort

Download:
- ZIP, ca. 15,7 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Linux von Johannes Pl&ouml;tner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
geb., mit 2 DVDs
1302 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1704-0
Pfeil 14 Grundlegende Verwaltungsaufgaben
  Pfeil 14.1 Rechteverwaltung
    Pfeil 14.1.1 chmod
    Pfeil 14.1.2 chown
    Pfeil 14.1.3 Erweiterte Rechte
    Pfeil 14.1.4 umask
    Pfeil 14.1.5 Access Control Lists
  Pfeil 14.2 Softwareinstallation
    Pfeil 14.2.1 Paketverwaltung und Ports
    Pfeil 14.2.2 APT – Advanced Packaging Tool
    Pfeil 14.2.3 Pakete in Handarbeit: dpkg und rpm
    Pfeil 14.2.4 .tgz Packages unter Slackware
    Pfeil 14.2.5 Das Gentoo Portage System
    Pfeil 14.2.6 BSD-Ports
    Pfeil 14.2.7 Softwareinstallation ohne Pakete
  Pfeil 14.3 Tätigkeiten automatisieren
    Pfeil 14.3.1 Skripts
    Pfeil 14.3.2 Cronjobs
    Pfeil 14.3.3 Punktgenau mit »at«
  Pfeil 14.4 Logging
    Pfeil 14.4.1 Die Logdateien
    Pfeil 14.4.2 Der syslogd
    Pfeil 14.4.3 logrotate
    Pfeil 14.4.4 logcheck
  Pfeil 14.5 Dateisystemverwaltung
    Pfeil 14.5.1 Die /etc/fstab
    Pfeil 14.5.2 Das Tool »mount«
    Pfeil 14.5.3 Platz beschränken: Quotas
    Pfeil 14.5.4 du und df
    Pfeil 14.5.5 SoftRAID und LVM
    Pfeil 14.5.6 Backups, Archive
  Pfeil 14.6 Kernel kompilieren
    Pfeil 14.6.1 Die Kernel-Quellen besorgen
    Pfeil 14.6.2 Die Konfiguration
    Pfeil 14.6.3 Den Kernel übersetzen
    Pfeil 14.6.4 Den Bootloader anpassen
    Pfeil 14.6.5 BSD-Kernel kompilieren
  Pfeil 14.7 Kernelmodule verwalten
    Pfeil 14.7.1 modprobe
    Pfeil 14.7.2 lsmod
    Pfeil 14.7.3 insmod und rmmod
    Pfeil 14.7.4 /etc/modules
    Pfeil 14.7.5 modconf
  Pfeil 14.8 Linux' SysRq
    Pfeil 14.8.1 Aktivierung von SysRq
    Pfeil 14.8.2 Tastenkombinationen
  Pfeil 14.9 Lokalisierung
    Pfeil 14.9.1 Die Tastaturbelegung
    Pfeil 14.9.2 Die deutsche Sprache
    Pfeil 14.9.3 Das Einstellen der Uhr
    Pfeil 14.9.4 Texte von anderen Plattformen
  Pfeil 14.10 Zusammenfassung
  Pfeil 14.11 Aufgaben


Galileo Computing - Zum Seitenanfang

14.4 Logging  Zur nächsten ÜberschriftZur vorigen Überschrift

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.


Galileo Computing - Zum Seitenanfang

14.4.1 Die Logdateien  Zur nächsten ÜberschriftZur vorigen Überschrift

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.


Galileo Computing - Zum Seitenanfang

14.4.2 Der syslogd  Zur nächsten ÜberschriftZur vorigen Überschrift

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.

Abbildung Tux

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

    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.

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.


Galileo Computing - Zum Seitenanfang

14.4.3 logrotate  Zur nächsten ÜberschriftZur vorigen Überschrift

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.

Abbildung Tux

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.


Galileo Computing - Zum Seitenanfang

14.4.4 logcheck  topZur vorigen Überschrift

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.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






 <<   zurück
  Zum Katalog
Zum Katalog: Linux, Ausgabe 2011






Linux, Ausgabe 2011
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Linux Hochverfügbarkeit






 Linux Hoch-
 verfügbarkeit


Zum Katalog: LPIC-1






 LPIC-1


Zum Katalog: Debian GNU/Linux






 Debian GNU/Linux


Zum Katalog: openSUSE 11.2






 openSUSE 11.2


Zum Katalog: Shell-Programmierung






 Shell-Programmierung


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de