Linux-Magazin: Syslog

Teil 1: Der System-Log-Dämon

System-Logging bietet eine einfache Möglichkeit, die Ausgabe von Programmen zentral aufzufangen und zu verwalten. In diesem Teil wird der Syslog-Dämon auf Linux-Seite betrachtet.

Wohl jeder, der ein Linux-System aufgesetzt hat, ist auf das Duo syslogd/klogd gestoßen. Diese Programme gehören zu den ersten Dämonen, die beim Hochfahren des Systems gestartet werden. Sie sind zudem mit die letzten Programme, die beim Herunterfahren beendet werden.

Der Begriff "Dämon" hat in diesem Zusammenhang nichts dämonisches oder magisches an sich. Ein Dämon auf einem Unix-System bezeichnet ein Syustemprogramm, welches im Hintergrund arbeitet und seine Aufgabe erledigt. Ein Dämon kann dabei essentielle Aufgaben für das laufende System übernehmen (z.B. init, update, kswapd) oder dem System spezielle Dienste zur Verfügung stellen (z.B. sshd, ircd, httpd).

Würde der syslogd später gestartet werden, dann würden je nach Anzahl der gestarteten Programme kaum noch Bootmeldungen auf der Konsole zu sehen sein, da diese von Syslog-Meldungen überflutet wäre. Die beiden Programme können sowohl allein als auch zusammenarbeiten.

Der syslogd liest System-Meldungen vom lokalen System sowie vom Netzwerk und bereitet diese auf. Dazu wird der Unix-Domain-Socket /dev/log geöffnet und regelmäßig ausgelesen. Soll der Server ebenfalls auf Syslog-Nachrichten aus dem Netzwerk reagieren (z.B. auf einem Loghost), dann muß dieses bei der aktuellen Version (ab 1.3) explizit mit dem Schalter "-r" eingeschaltet werden. Dieses wurde eingeführt, um einen sogenannten Denial of Service Attack abzuwehren. Wenn der Dämon nämlich auf den UDP-Port horcht, dann kann jeder Rechner irgendwo im Netz darauf schreiben und u.U. die Platte füllen.

Syslog-Nachrichten

Tabelle 1: Syslog-Typen (Facilities)
Facility	Bedeutung
LOG_KERN	Kernel-Nachrichten
LOG_USER	Nachrichten von Usern
LOG_MAIL	E-Mail-Subsystem
LOG_DAEMON	Verschiedene Dämonen
LOG_SYSLOG	Syslog-interne Nachrichten
LOG_LPR	Drucker-Subsystem
LOG_NEWS	News-Subsystem
LOG_UUCP	UUCP-Subsystem
LOG_CRON	Cron-Dämon
LOG_AUTHPRIV	Authorisierung aller Art
LOG_LOCAL0-7	Reserviert für lokalen Bedarf

Jede Syslog-Nachricht besteht aus zwei Komponenten: dem eigentlichen Text und einer Kombination aus Typ (Facility) und Priorität (Level). Die Facility beschreibt den Typ der Nachricht. Es wird zwischen verschiedenen Subsystemen unterschieden, größtenteils historisch bedingt sind. Die verschiedenen Typen sind in Tabelle 1 aufgelistet. Local0 bis 7 sind normalerweise bei einem frisch installierten System unbenutzt und können vom Administrator für weitere Subsysteme (z.B. Web-Programme, System-Skripte etc.) vergeben werden.

Nachdem der Syslog-Dämon den Typ und die Priorität dekodiert hat, ergänzt er die Nachricht um einen Zeitstempel und einen Hostnamen (näheres im Abschnitt Kommandozeile). Dadurch können die Quelle und Uhrzeit rückverfolgt werden.

Der Level zeigt die Wichtigkeit der Nachricht an. Diese läuft von unwichtig ("debug") bis zu kurz vor Systemausfall ("alert"). Auf diese Weise kann der syslogd dafür sorgen, daß besonders kritische Meldungen auf der Konsole ausgegeben werden, damit noch versucht werden kann, das Schlimmste zu verhindern.

Tabelle 2: Syslog-Prioritäten
Level	Bedeutung
LOG_EMERG	Das System ist unbrauchbar
LOG_ALERT	Es müssen dringend Aktionen eingeleitet werden
LOG_CRIT	Kritische Nachricht
LOG_ERR	Normaler Fehler
LOG_WARNING	Warnung
LOG_NOTICE	Normale, aber bedeutende Nachricht
LOG_INFO	Normale Nachricht
LOG_DEBUG	Meist unwichtige Nachricht

Die Fähigkeit, den Syslog-Mechanismus zu benutzen, liegt in der libc begründet, der wichtigsten Bibliothek im System, verborgen. Auf die Benutzung der entsprechenden Funktionen wird im nächsten Teil eingegangen.

Die Serverseite muß nun konfiguriert werden, denn was bringt ein systemweiter Logging-Mechanismus, wenn doch nur alles auf einem Haufen landet? Der große Vorteil beim Syslog ist, daß die Log-Nachrichten an eine zentrale Stelle, nämlich dem syslogd, geschickt werden und dort zentral verwaltet und auseinanderdividiert werden können.

Je nach Inhalt, der anhand von Facility und Level unterschieden wird, werden die Log-Nachrichten in unterschiedliche Dateien aufgeteilt, auf der Consle ausgegeben oder über das Netz an einen sogenannten Loghost weitergeschickt.

Die Konfigurationsdatei /etc/syslog.conf

Konfiguriert wird der syslogd in der Datei /etc/syslog.conf. Jede nicht mit # auskommentierte Zeile beschreibt eine Logdatei im weiteren Sinne (es muß sich nicht wirklich um eine Datei handeln). Sie besteht aus zwei Feldern, einem sogenannten Selector und einer Action. Getrennt werden sie durch eine beliebige Anzahl von Leerzeichen oder/und Tabulatoren.

Linux' syslogd ist zwar aus dem BSD'schen erwachsen, wurde jedoch schon frühzeitig um wichtige Merkmale erweitert. Zum einen ist die Unterstützung des Kernel-Log-Dämons völlig neu und zum anderen wurde die Flexibilität der Selectoren erheblich gesteigert.

Der Selector besteht aus einer Liste von Facility.Level-Paaren, die durch ein Semikolon voneinander getrennt sind. Die hier verwendeten Zeichenketten sind die kleingeschriebenen Facility- und Levelkonstanten aus den Tabellen 1 und 2 ohne führendes LOG_. Ein Level steht dabei - wie beim Urahn BSD - für diesen Level und alle wichtigeren. Der Level "info" schließt also "crit" und "emerg" mit ein, nicht jedoch "debug".

Mit der Zeile

  mail.info;news.warn	/var/log/info

wird also mail.info bis mail.emerg und news.warn bis news.emerg in der Datei /var/log/info gespeichert.

Die Besonderheit des Linux'schen Syslog-Dämons sind die Modifizierer, die hier zusätzlich angewendet werden können. So können sowohl als Facility als auch als Level das Zeichen * (alle Facilities bzw. alle Level) und das Schlüsselwort none (kein Level dieser Facility bzw. kein solcher Level) angegeben werden.

Demnach bewirkt folgende Zeile

  mail.info;news.warn;none.crit	/var/log/info

daß keine Nachrichten mit einer Priorität crit und höher geschrieben werden.

 # /etc/syslog.conf
 #
 # For info about the format of this file, see "man syslog.conf".
 #

 *.*					/var/log/syslog
 auth.*					/var/log/auth
 daemon.*				/var/log/daemon
 mail.*					/var/log/mail
 news.warning				/var/log/news
 uucp.*					/var/log/uucp
 lpr.*					/var/log/lpr
 cron.*					/var/log/cron
 user.*					/var/log/user

 kern.*					/var/log/kernel
 kern.*					/dev/tty23
 kern.crit				@escher

 *.=emerg		  		*

 # Store alert and emerg in alert
 #
 *.alert				/var/log/alert

 # Store critical stuff in critical
 #
 *.=crit		  		/var/log/critical
 #
 # mail.info reflects tcpd
 # auth.warning shows all root login atempts
 #
 mail.=info;auth.=warning		/dev/tty14

 *.=info;*.=notice			/var/log/messages
 *.=debug				/var/log/debug

 *.=info;*.=notice;news,local2.none	/dev/tty15
 *.*					/dev/tty24
 local2.*				/var/log/bootpd

 *.=info;*.=notice			@tapiola

 mail.=info				|/dev/xKonsole

Abbildung 1: Konfiguration auf einem Loghost

Wird ein Gleichheitszeichen vor der Priorität gesetzt, dann wird ausschließlich exakt dieser Priorität, und nicht die höheren zusätzlich, verwendet. So lassen sich einzelne Facility.Level-Paare herausfiltern und die Logdateien dabei besser sortieren. Als Clou besteht bei Linux noch die Möglichkeit, die Wirkung mit einem Ausrufezeichen umzukehren.

Eine weitere Ergänzung ist das Komma. So können mehrere Typen zusammengefaßt werden. Die foglenden Prioritäten beziehen sich dann auf alle angegebenen Typen. So bewirkt folgende Zeile, daß Nachrichten beliebigen Typs mit den Prioritäten "info" und "notice" auf der 15. Konsole ausgegeben werden. Lediglich die Typen "news" und "local2" werden davon ausgeschlossen.

  *.=info;*.=notice;news,local2.none	/dev/tty15

Abbildung 1 zeigt eine beispielhafte Konfigurationsdatei auf einem Loghost. Abbildung 2 enthält das daraus resultierende Muster (erzeugt mit syslogd -d). Ein X bedeutet dabei, daß von diesem Typen nichts gelogt wird.

Action mit Syslog

Der geneigte Leser wird sich nun fragen, ob das schon alles war. Kann der syslogd nur in normale Dateien schreiben? Nein, keineswegs! Allerdings sind normale Dateien der übliche Speicherplatz für Logs jeglicher Art. Beschreibt der Dateiname ein Terminal (tty), dann wird diese Datei besonders behandelt und die Nachrichten werden dort ungepuffert ausgegeben. So können Nachrichten, die der tcpd schreibt, wenn sich z.B. jemand über das Netzwerk einloggt, aufgefangen und auf einer Konsole ausgegeben werden.

Der syslogd kann selbstverständlich derart konfiguriert werden, daß er Nachrichten auf die Konsole bestimmter User oder afu die aller zu der Zeit eingelogten Benutzern schreibt. Letzteres ist gerade dann sinnvoll, wenn das System droht, aufgrund schwerwiegender Probleme, auszufallen, damit die Benutzer noch rechtzeitig versuchen können, ihre Daten zu sichern.

Eine äußerst nützliche Action ist das Weiterleiten von Nachrichten an einen anderen Rechner. Damit wird die Wartung in einem Netzwerk erleichtert, denn es müssen nicht mehr auf jedem Rechner die Logdateien gesichtet werden, sondern lediglich auf dem Loghost. Zudem hat es bei entsprechender Konfiguration gewisse Vorteile, wenn Kernel-Crash-Meldungen vor dem endgültigen Ableben des Rechners an einen anderen Rechner geschickt werden konnten. In meinem Umfeld war es schon mehrfach nur dadurch möglich, den Grund des Crashes herauszufinden. Die Besitzer von headless (ohne Monitor) Servern sind diesem Service ebenfalls dankbar.

 0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  X FILE: /var/log/syslog
 1:  X  X  X  X FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/auth
 2:  X  X  X FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/daemon
 3:  X  X FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/mail
 4:  X  X  X  X  X  X  X 1F  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/news
 5:  X  X  X  X  X  X  X  X FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/uucp
 6:  X  X  X  X  X  X FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/lpr
 7:  X  X  X  X  X  X  X  X  X FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/cron
 8:  X FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/user
 9: FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: /var/log/kernel
10: FF  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X TTY: /dev/tty23
11:  7  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FORW: escher
12:  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  X WALL:
13:  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  X FILE: /var/log/alert
14:  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  X FILE: /var/log/critical
15:  X  X 40  X 10  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X TTY: /dev/tty14
16: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60  X FILE: /var/log/messages
17: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80  X FILE: /var/log/debug
18: 60 60 60 60 60 60 60  X 60 60 60 60 60 60 60 60 60 60  X 60 60 60 60 60  X TTY: /dev/tty15
19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  X TTY: /dev/tty24
20:  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FF  X  X  X  X  X  X FILE: /var/log/bootpd
21: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60  X FORW: tapiola
22:  X  X 40  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X FILE: |/dev/xKonsole

Abbildung 2: Bitmuster für Syslogmeldungen auf einem Loghost

In der Urfassung gab es jedoch ein kleines Problemchen damit: Es war sehr einfach, durch Unachtsamkeit eine Endlosschleife zu erzeugen. Mittlerweile werden keine Nachrichten mehr weitergeleitet, wenn sie bereits über das Netzwerk empfangen wurden. Es war allerdings schon possierlich mitanzusehen, wie sich zwei syslogds gegenseitig "zumüllen" ...

Als Action kann auch eine durch Kommata getrennte Liste von Benutzern angegeben werden. Wenn sie eingelogt sind, erscheinen die Meldungen auf ihren Konsolen. Zum Schluß beherrscht auch der syslogd ein wall(1), dann schreibt er die Meldungen auf jedes geöffnete Terminal. Ein Verhalten, das bei sehr kritischen Meldungen sinnvoll ist. Die Liste der Actions ist in Tabelle 3 zusammengestellt.

Tabelle 3: Mögliche Actions
Action	Bedeutung
/filename	Schreibe in die Datei bzw. auf das Terminal
@hostname	Leite die Nachrichten zu am angegebenen Rechner weiter
\|pipe	Schreibe in die angegebene Pipe, damit andere Programme (z.B. xKonsole diese auslesen können
user	Schreibe auf das Terminal des angegebenen Users
*	wall: Schreibe auf alle benutzten Terminals

Im Gegensatz zum Original von BSD werden Kernel-Nachrichten unter Linux gesondert behandelt. Dazu wurde der zusätzliche Typ "kern" eingeführt. Der Kernel schickt sie jedoch nicht direkt an den Syslog-Dämon, sondern läßt sie zuerst vom Kernel-Log-Dämon auswerten. Dieses wird im dritten Teil näher erläutert.

Kommandozeile

Der Syslog-Dämon erweitert empfangene Nachrichten um den Rechnernamen, von dem sie kommen. Wurden sie lokal erzeugt, dann wird der einfache Name verwendet. Der Dämon schaut beim Programmstart nach, in welcher Domain er sich befindet und schneidet diese jeweils ab.

Schwierig wurde es, wenn sich ein Loghost in einer Umgebung befindet, in der mehrere Domains, jedoch eindeutige Rechnernamen verwendet werden. Durch Anhängen der Domain wird die Logdatei nicht unbedingt leserlicher, insbesondere dann, wenn die Nachrichten selbst bereits über 40 Zeichen lang sind. Man ist schnell bei einer Breite von über 100 Zeichen angekommen.

Aus diesem Grund wurden in der Version 1.3 des Syslog-Dämons zwei neue Parameter eingeführt, die zum einen weitere Domains quasi als lokal erklären (Parameter -s) und zum anderen einzelne Hosts spezifizieren (Parameter -l), die ebenfalls als lokal anzusehen sind. Beide Parameter verstehen eine Liste von Namen, dessen Elemente durch Doppelpunkte voneinander getrennt werden. Derartige Rechnernamen werden fortan ohne Domain geschrieben.

Eine weitere wichtige Änderung zu älteren Versionen bzw. zum Original betrifft den Empfang von Nachrichten aus dem Netzwerk. Früher haben die Syslog-Dämonen immer auf dem Syslog-Port (UDP) gehorcht und Nachrichten empfangen. Dieses Verhalten muß jetzt explizit mit dem Parameter -r wieder eingeschaltet werden, um Syslog-Floods vorzubeugen. Die restlichen Parameter werden in Tabelle 4 erläutert.

Tabelle 4: Parameter vom syslogd
Parameter	Wirkung
-d	Schaltet Debugging an. Das Programm schreibt auf die Konsole und schaltet sich nicht in den Hintergrund.
-f filename	Verwende filename anstelle von /etc/syslog.conf.
-h	Leite Nachrichten aus dem Netzwerk doch weiter.
-l hostlist	Definiert die angegebenen Rechner als lokal und schreibt nur deren einfache Rechnernamen.
-m interval	Beschreibt das Intervall zwischen den -- MARK -- Zeilen, welche die Funktionstüchtigkeit des Dämons anzeigen. Voreingestellt sind 20 Minuten.
-n	Schaltet den Dämon nicht automatisch in den Hintergrund, was extrem wichtig ist, wenn er vom Init-Prozeß und nicht per /etc/init.d gestartet wird.
-p socket	Verwendet einen anderen Socket als /dev/log.
-r	Gibt an, daß der Dämon auch auf Nachrichten aus dem Netzwerk hören und diese bearbeiten soll.
-s domainlist	Definiert die angegebenen Rechner als lokal und schreibt nur deren einfachen Rechnernamen.
-v	Druckt die Versionsnummer und beendet sich.

Troubleshooting

Syslog empfängt keine Nachrichten von anderen Rechnern

Es wurde vergessen, daß der aktuelle syslogd mit dem Parameter "-r" gestartet werden muß, wenn er Nachrichten aus dem Netzwerk empfangen soll.

Der Syslog-Dämon startet nicht bzw. braucht sehr lange

Auf einem System, das gleichzeitig für sich selbst Nameserver spielt, kann es zu Problemen kommen, wenn der syslogd vor dem named gestartet wird, jedoch Adressen vom Nameserver beziehen will.

Die Rechnernamen, die in der Konfigurationsdatei /etc/syslog.conf genannt werden, sollten in der Datei /etc/hosts eingetragen sein.

Martin Schulze