Inhaltsverzeichnis
Bewertung 1
Die Kandidaten sollten in der Lage sein, syslogd als zentralen Logserver zu konfigurieren. Dieses Prüfungsziel beinhaltet die Konfiguration von syslogd, dass er seine Ausgaben an den zentralen Logserver weiterleitet, das Aufnehmen entfernter Verbindungen in das Logbuch und die Verwendung von grep und anderen Textutilities zur automatischen Analyse des Logbuchs.
Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:
- syslog.conf
- sysklogd
- /etc/hosts
Den Aufbau und die Konfiguration des Syslogdaemons haben wir bereits in der Vorbereitung auf das LPI102-Examen genau besprochen. Im Zweifelsfall sollte das Kapitel 1.111.3 dieses Kurses noch einmal durchgearbeitet werden. Hier werden wir uns auf die Aufgabenstellung konzentrieren, die uns das Prüfungsziel vorgibt und das entsprechende Grundwissen voraussetzen.
Die Organisation des Logbuches wurde von der orginal-BSD Syslog Architektur etwas entfernt, auch wenn die Konfiguration davon unbeinflusst bleibt. Linux benutzt heute zwei Logdaemonen, zum einen den schon bekannten syslogd, zum anderen – speziell für Kernelmeldungen – den klogd. Der syslogd ist damit weiterhin zuständig für Systemmeldungen, der klogd erzeugt Kernelmeldungen, die aber auch an den syslogd weitergegeben werden. Der Vorteil des klogd ist, dass er – etwa über die Datei System.map – genauer über die intenen Kerneladressen Bescheid weiss. Der syslogd, der diese Fähigkeit unterstützt wird sysklogd genannt, auch wenn das Binary weiterhin den Namen syslogd trägt.
Aufbau eines zentralen Logservers
Damit der Syslog-Daemon tatsächlich bereit ist, die Logeinträge fremder Rechner aufzunehmen, muß er mit der Option -r (remote) gestartet werden. Das ist die erste und zwingende Voraussetzung, damit alles andere funktioniert.
Diese Einstellung wird am besten in dem entsprechenden init-Script vorgenommen, das den syslog aufruft. Also meist etwas wie /etc/init.d/syslogd. Dort sollten wir also der Zeile, die den Daemon selbst aufruft diese Option anhängen, etwa
/sbin/syslogd -r
Diese Einstellung ist nur auf dem Rechner notwendig (und empfehlenswert), der den zentralen Syslogdienst zur Verfügung stellen soll. Alle anderen Rechner im Netz bleiben davon unbetroffen.
Durch den Aufruf mit -r ist unser syslogd jetzt automatisch in der Lage, ankommende syslog-Pakete anderer Rechner entgegenzunehmen. Was er jeweils mit den angenommenen Meldungen anfängt, hängt wiederum davon ab, was in der Datei syslog.conf eingetragen ist. Die Meldungen kommen ja auch wieder mit der Angabe der Herkunft und Priorität, können also genauso eingeordnet werden, wie normale lokale Meldungen.
Clientseitige Einstellungen für den zentralen Logserver
Damit ein beliebiger Rechner seine syslog-Meldungen an einen zentralen Logserver weitergibt, muß er eine entsprechende Regel in der Datei /etc/syslog.conf besitzen. Im einfachsten Fall werden einfach alle Meldungen an dem Logserver übertragen. Das kann mit der Anweisung
*.* @Logserver
eingestellt werden. Stegt diese Zeile in der Datei /etc/syslog.conf, so werden alle Meldungen an den Logserver übertragen. Statt „Logserver“ steht hier natürlich der Hostname des zentralen Logservers!
Natürlich ist es auch möglich, nur bestimmte Meldungen an den Logserver zu schicken, oder verschiedene Meldungen an verschiedene Server zu schicken.
Ein wichtiger Punkt, der dabei zu beachten ist, ist der, dass viele Logmeldungen sehr früh beim Booten entstehen. Zu dieser Zeit kann es sein, dass der Syslog-Daemon noch keinen Nameserverzugriff hat, über den er den Namen des Logservers auflösen kann. Es empfiehlt sich also, den Logserver in die Datei /etc/hosts aufzunehmen, damit er möglichst früh zur Verfügung steht.
In beiden Fällen, also wenn syslog als zentraler Logserver dient, oder als Client eines Logservers, muß die Voraussetzung erfüllt sein, dass in der Datei /etc/services ein entsprechender Eintrag für die Portnummer 514 steht.
syslog 514/udp
Ohne diesen Eintrag kann syslogd weder Pakete ins Netz senden, noch Pakete aus dem Netz empfangen.
Automatische Analyse der Logbuchdateien
In vielen Fällen ist die Funktionalität des Syslog-Daemons sehr hilfreich, aber eine Fähigkeit fehlt ihm selbst, das Starten von bestimmten Programmen, wenn bestimmte Ereignisse aufgezeichnet werden. Diese Funktionalität müssten wir selbst schaffen, wenn wir sie nutzen wollen.
Die einfachste Möglichkeit liegt darin, die entsprechenden Logbuchdateien mit Hilfe der Textutils nach bestimmten Zeilen zu durchsuchen und je nach Ergebnis die entsprechenden Schritte einzuleiten.
Die einfachste Form dieser Untersuchung bietet uns das Programm grep. Dieses Programm sucht ja nach regulären Ausdrücken innerhalb einer Datei oder seines Eingabedatenstroms. Ein anderes häufig verwendetes Tool ist awk.
Syslog-Messages selbst erzeugen
Als Programmierer für Unix-Programme ist man ständig konfrontiert, mit der Notwendigkeit, syslog-Meldumgen zu erstellen. Diese Aufgabenstellung stellt aber keinerlei Problem dar, weil die Standard-Library eine entsprechende Bibliotheksfunktion zur Verfügung stellt. Etwas anders sieht es aus, wenn wir ein Shellscript schreiben und innerhalb dieses Scripts eine Syslog-Meldung erzeugen wollen. Oder, wenn wir eine neue Konfiguration des Syslog-Daemons ausprobieren wollen um zu sehen, ob bestimmte Meldungen auch tatsächlich da ankommen, wo wir sie haben wollen.
Für diese Aufgabenstellung gibt es den Befehl logger. Er bietet eine Userschnittstelle zu der oben angeführten Bibliotheksfunktion und ermöglicht es uns so, direkt Syslog-Meldungen beliebiger Priorität und Herkunft von Hand zu erstellen. Die (vereinfachte) Aufrufform ist
logger [-p Herkunft.Priorität] Meldungstext
Wird die Option -p weggelassen, so wird user.notice angenommen. Der Meldungstext kann auch aus einer Datei übernommen werden, wenn diese Datei mit -f spezifiziert wurde. Wird weder eine Meldung angegeben, noch eine Datei spezifiziert, so erwartet logger die Meldung von der Standard-Eingabe.
Gültige Herkunftbezeichner sind: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security(Synonym für authpriv), syslog, user, uucp und local0 bis local7.
Gültige Prioritätsbezeichner sind: alert, crit, debug, emerg, err, error (Synonym für err), info, notice, panic (Synonym für emerg), warning, warn (Synonym für warning).