108.2 Lektion 1
Zertifikat: |
LPIC-1 |
---|---|
Version: |
5.0 |
Thema: |
108 Grundlegende Systemdienste |
Lernziel: |
108.2 Systemprotokollierung |
Lektion: |
1 von 2 |
Einführung
Logs oder Log-Dateien können der beste Freund des Systemadministrators sein. Logs sind Dateien (in der Regel Textdateien), in denen alle System- und Netzwerkereignisse chronologisch ab dem Zeitpunkt des Systemstarts registriert werden. Die Bandbreite der Informationen, die in Logs zu finden sind, umfasst also praktisch jeden Aspekt des Systems: fehlgeschlagene Authentifizierungsversuche, Programm- und Servicefehler, von der Firewall blockierte Hosts usw. So machen Logs das Leben von Systemadministratoren sehr viel einfacher, wenn es um die Fehlersuche, die Überprüfung von Ressourcen, die Erkennung ungewöhnlichen Verhaltens von Programmen usw. geht.
In dieser Lektion geht es um eine der gebräuchlichsten Logging-Funktionen, die derzeit in GNU/Linux-Distributionen zu finden sind: rsyslog
. Wir werden die verschiedenen Arten von Logs untersuchen, wo diese gespeichert werden, welche Informationen sie enthalten und wie diese Informationen bezogen und gefiltert werden. Darüber hinaus geht es um Logs in zentralisierten Servern über IP-Netzwerke hinweg sowie die Log Rotation und den Kernel Ring Buffer.
System-Logging
In dem Moment, in dem der Kernel und die verschiedenen Prozesse in Ihrem System starten und miteinander kommunizieren, werden viele Informationen in Form von Meldungen erzeugt, die — zum größten Teil — in Logs gesendet werden.
Ohne Logging wäre die Suche nach einem Ereignis auf einem Server überaus schwierig, daher ist eine standardisierte und zentralisierte Nachverfolgung von aller Systemereignisse wichtig. Logs sind entscheidend und aussagekräftig, wenn es um Fehlersuche und Sicherheit geht — und sie sind zuverlässige Datenquellen für Systemstatistiken und Trendvorhersagen.
Abgesehen von systemd-journald
(das wir in der nächsten Lektion besprechen), wurde das Logging traditionell von drei dedizierten Diensten übernommen: syslog
, syslog-ng
(Syslog New Generation) und rsyslog
(“the rocket-fast system for log processing”). rsyslog
brachte wichtige Verbesserungen (z.B. RELP-Unterstützung) und ist heute die beliebteste Wahl. Jeder dieser Dienste sammelt Meldungen von anderen Diensten und Programmen und speichert diese in Protokolldateien, typischerweise unter /var/log
. Einige Dienste kümmern sich jedoch selbst um ihre Logs (zum Beispiel der Apache-HTTPD-Webserver oder das Drucksystem CUPS). Ebenso nutzt der Linuxkernel einen speicherinternen Ring Buffer (Ringpuffer) für die Speicherung seiner Log-Meldungen.
Note
|
RELP steht für Reliable Event Logging Protocol und erweitert die Funktionalität des Syslog-Protokolls für eine zuverlässige Zustellung von Nachrichten. |
Da rsyslog
zum Standard-Log-System in allen größeren Distros geworden ist, werden wir uns in dieser Lektion darauf konzentrieren. rsyslog
folgt dem Client-Server-Modell. Client und Server können sich auf demselben Rechner oder auf verschiedenen Rechnern befinden. Nachrichten werden in einem bestimmten Format gesendet und empfangen und können in zentralisierten rsyslog
-Servern über IP-Netzwerke hinweg aufbewahrt werden. Der Daemon von rsyslog
(rsyslogd
) arbeitet mit klogd
(der Kernelnachrichten verwaltet) zusammen. In den nächsten Abschnitten stellen wir rsyslog
und seine Logging-Infrastruktur vor.
Note
|
Ein Daemon ist ein Dienst, der im Hintergrund läuft. Beachten Sie das abschließende |
Log-Typen
Da Logs variable Daten sind, befinden sie sich normalerweise in /var/log
. Grob lassen sich System-Logs und Dienst- oder Programm-Logs unterscheiden.
Hier einige System-Logs und die darin enthaltenen Informationen:
/var/log/auth.log
-
Aktivitäten im Zusammenhang mit Authentifizierungsprozessen: angemeldete Benutzer,
sudo
-Informationen, Cron-Jobs, fehlgeschlagene Anmeldeversuche etc. /var/log/syslog
-
Eine zentrale Datei für praktisch alle von
rsyslogd
erfassten Logs. Da hier sehr viele Informationen zusammenkommen, werden die Logs entsprechend der in/etc/rsyslog.conf
hitnerlegten Konfiguration auf andere Dateien verteilt. /var/log/debug
-
Debug-Informationen von Programmen.
/var/log/kern.log
-
Kernelmeldungen.
/var/log/messages
-
Meldungen, die sich nicht auf den Kernel, sondern auf andere Dienste beziehen. Es ist auch das standardmäßige Remote-Client-Log-Ziel in einer zentralisierten Logserver-Implementierung.
/var/log/daemon.log
-
Informationen zu Daemons oder anderen Diensten im Hintergrund.
/var/log/mail.log
-
Informationen zum E-Mail-Server, z.B. Postfix.
/var/log/Xorg.0.log
-
Informationen zur Grafikkarte.
/var/run/utmp
and/var/log/wtmp
-
Erfolgreiche Anmeldungen.
/var/log/btmp
-
Fehlgeschlagene Anmeldeversuche, z.B. Brute-Force-Angriffe über ssh.
/var/log/faillog
-
Fehlgeschlagene Authentifizierungsversuche.
/var/log/lastlog
-
Datum und Uhrzeit der letzten Benutzeranmeldungen.
Hier einige Beispiele für Service-Logs:
/var/log/cups/
-
Verzeichnis für Logs des Common Unix Printing System. Es enthält in der Regel die folgenden Standardprotokolldateien:
error_log
,page_log
undaccess_log
. /var/log/apache2/
or/var/log/httpd
-
Verzeichnis für Logs des Apache Web Servers. Es enthält in der Regel die folgenden Standard-Logdateien:
access.log
,error_log
undother_vhosts_access.log
. /var/log/mysql
-
Verzeichnis für Logs des relationalen Datenbankmanagementsystems MySQL. Es enthält in der Regel die folgenden Standard-Logdateien:
error_log
,mysql.log
undmysql-slow.log
. /var/log/samba/
-
Verzeichnis für Logs des SMB-Protokolls (Session Message Block). Es enthält in der Regel die folgenden Standard-Logdateien:
log.
,log.nmbd
undlog.smbd
.
Note
|
Der genaue Name und der Inhalt der Logsateien variiert bei verschiedenen Linux-Distributionen. Es gibt auch distributionspezifische Logs, z.B. |
Logdateien lesen
Um Logdateien zu lesen, stellen Sie zunächst sicher, dass root sind oder Leserechte für die Datei haben. Sie können eine Reihe von Dienstprogrammen verwenden, wie z.B.:
less
odermore
-
Pager für das seitenweise Anzeigen und Blättern:
root@debian:~# less /var/log/auth.log Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting. Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22. Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22. Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting. Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22. Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22. Sep 12 18:49:46 debian sshd[905]: Accepted password for carol from 192.168.1.65 port 44296 ssh2 Sep 12 18:49:46 debian sshd[905]: pam_unix(sshd:session): session opened for user carol by (uid=0) Sep 12 18:49:46 debian systemd-logind[331]: New session 2 of user carol. Sep 12 18:49:46 debian systemd: pam_unix(systemd-user:session): session opened for user carol by (uid=0) (...)
zless
oderzmore
-
Wie
less
undmore
, aber für Logs, die mitgzip
komprimiert sind (eine übliche Funktion vonlogrotate
):root@debian:~# zless /var/log/auth.log.3.gz Aug 19 20:05:57 debian sudo: carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/sbin/shutdown -h now Aug 19 20:05:57 debian sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0) Aug 19 20:05:57 debian lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event2 (Power Button) Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event3 (Sleep Button) Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event4 (Video Bus) Aug 19 23:50:49 debian systemd-logind[333]: New seat seat0. Aug 19 23:50:49 debian sshd[409]: Server listening on 0.0.0.0 port 22. (...)
tail
-
Zeigt die letzten Zeilen einer Datei an (die Vorgabe sind 10 Zeilen). Besonders hilfreich ist die Option
-f
, mit dertail
neue Zeilen dynamisch anzeigt, sobald sie an ein Log angehängt werden:root@suse-server:~# tail -f /var/log/messages 2019-09-14T13:57:28.962780+02:00 suse-server sudo: pam_unix(sudo:session): session closed for user root 2019-09-14T13:57:38.038298+02:00 suse-server sudo: carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/messages 2019-09-14T13:57:38.039927+02:00 suse-server sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0) 2019-09-14T14:07:22+02:00 debian carol: appending new message from client to remote server...
head
-
Zeigt die ersten Zeilen einer Datei an (die Vorgabe ist 10 Zeilen):
root@suse-server:~# head -5 /var/log/mail 2019-06-29T11:47:59.219806+02:00 suse-server postfix/postfix-script[1732]: the Postfix mail system is not running 2019-06-29T11:48:01.355361+02:00 suse-server postfix/postfix-script[1925]: starting the Postfix mail system 2019-06-29T11:48:01.391128+02:00 suse-server postfix/master[1930]: daemon started -- version 3.3.1, configuration /etc/postfix 2019-06-29T11:55:39.247462+02:00 suse-server postfix/postfix-script[3364]: stopping the Postfix mail system 2019-06-29T11:55:39.249375+02:00 suse-server postfix/master[1930]: terminating on signal 15
grep
-
Filtert die Datei, so dass Sie nach bestimmten Zeichenfolgen suchen können:
root@debian:~# grep "dhclient" /var/log/syslog Sep 13 11:58:48 debian dhclient[448]: DHCPREQUEST of 192.168.1.4 on enp0s3 to 192.168.1.1 port 67 Sep 13 11:58:49 debian dhclient[448]: DHCPACK of 192.168.1.4 from 192.168.1.1 Sep 13 11:58:49 debian dhclient[448]: bound to 192.168.1.4 -- renewal in 1368 seconds. (...)
Wie Sie vielleicht bemerkt haben, erscheint die Ausgabe in folgendem Format:
-
Zeitstempel
-
Hostname, von dem die Nachricht stammt
-
Name des Programms/Dienstes, der die Meldung erzeugt hat
-
PID des Programms, das die Meldung erzeugt hat
-
Beschreibung der Aktion, die stattgefunden hat
Es gibt einige Beispiele, in denen Logs nicht als Text, sondern als Binärdateien vorliegen — folglich sind hier für die Analyse spezielle Befehle notwendig:
/var/log/wtmp
-
Verwenden Sie
who
(oderw
):root@debian:~# who root pts/0 2020-09-14 13:05 (192.168.1.75) root pts/1 2020-09-14 13:43 (192.168.1.75)
/var/log/btmp
-
Verwenden Sie
utmpdump
oderlast -f
:root@debian:~# utmpdump /var/log/btmp Utmp dump of /var/log/btmp [6] [01287] [ ] [dave ] [ssh:notty ] [192.168.1.75 ] [192.168.1.75 ] [2019-09-07T19:33:32,000000+0000]
/var/log/faillog
-
Verwenden Sie
faillog
:root@debian:~# faillog -a | less Login Failures Maximum Latest On root 0 0 01/01/70 01:00:00 +0100 daemon 0 0 01/01/70 01:00:00 +0100 bin 0 0 01/01/70 01:00:00 +0100 sys 0 0 01/01/70 01:00:00 +0100 sync 0 0 01/01/70 01:00:00 +0100 games 0 0 01/01/70 01:00:00 +0100 man 0 0 01/01/70 01:00:00 +0100 lp 0 0 01/01/70 01:00:00 +0100 mail 0 0 01/01/70 01:00:00 +0100 (...)
/var/log/lastlog
-
Verwenden Sie
lastlog
:root@debian:~# lastlog | less Username Port From Latest root Never logged in daemon Never logged in bin Never logged in sys Never logged in (...) sync Never logged in avahi Never logged in colord Never logged in saned Never logged in hplip Never logged in carol pts/1 192.168.1.75 Sat Sep 14 13:43:06 +0200 2019 dave pts/3 192.168.1.75 Mon Sep 2 14:22:08 +0200 2019
Note
|
Es gibt auch grafische Werkzeuge zum Lesen von Logdateien, z.B. |
Wie Meldungen in Logs umgewandelt werden
Der folgende Vorgang veranschaulicht, wie eine Meldung in eine Logdatei geschrieben wird:
-
Anwendungen, Dienste und der Kernel schreiben Nachrichten in spezielle Dateien (Sockets und Speicherpuffer), z.B.
/dev/log
oder/dev/kmsg
. -
rsyslogd
holt die Informationen aus den Sockets oder Speicherpuffern. -
Abhängig von den Regeln in
/etc/rsyslog.conf
und/oder den Dateien in/etc/ryslog.d/
verschiebtrsyslogd
die Informationen in die entsprechende Protokolldatei (normalerweise in/var/log
zu finden).
Note
|
Ein Socket ist eine spezielle Datei zur Übertragung von Informationen zwischen verschiedenen Prozessen. Um alle Sockets auf Ihrem System aufzulisten, nutzen Sie den Befehl |
Einrichtungen, Prioritäten und Aktionen
Die Konfigurationsdatei von rsyslog
heißt /etc/rsylog.conf
(in manchen Distributionen finden Sie die Konfigurationsdateien auch in /etc/rsyslog.d/
). Sie ist normalerweise in drei Abschnitte unterteilt: MODULES
, GLOBAL DIRECTIVES
und RULES
. Werfen wir einen Blick auf die Datei rsyslog.conf
auf einem Rechner mit einem Debian GNU/Linux 10 (Buster) — wir nutzen dazu sudo less /etc/rsyslog.conf
.
MODULES
enthält Modulunterstützung für Logging, Nachrichtenfähigkeit und UDP/TCP-Log-Empfang:
################# #### MODULES #### ################# module(load="imuxsock") # provides support for local system logging module(load="imklog") # provides kernel logging support #module(load="immark") # provides --MARK-- message capability # provides UDP syslog reception #module(load="imudp") #input(type="imudp" port="514") # provides TCP syslog reception #module(load="imtcp") #input(type="imtcp" port="514")
Mit GLOBAL DIRECTIVES
konfigurieren wir z.B. Logs und Log-Verzeichnisberechtigungen:
########################### #### GLOBAL DIRECTIVES #### ########################### # # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Set the default permissions for all log files. # $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Where to place spool and state files # $WorkDirectory /var/spool/rsyslog # # Include all config files in /etc/rsyslog.d/ # $IncludeConfig /etc/rsyslog.d/*.conf
In RULES
kommen Facilities (Einrichtungen), pPriorities (Prioritäten) und Actions (Aktionen) ins Spiel. Die Einstellungen in diesem Abschnitt weisen den Logging-Daemon an, Nachrichten nach bestimmten Regeln zu filtern und zu protokollieren oder zu senden, wo es erforderlich ist. Um diese Regeln zu verstehen, klären wir zunächst die Konzepte von Einrichtungen und Prioritäten von rsyslog
. Jede Lognachricht erhält eine Facility-Nummer und ein Schlüsselwort, die mit dem Linux-internen Subsystem verbunden sind, das die Nachricht erzeugt:
Nummer | Schlüsselwort | Beschreibung |
---|---|---|
|
|
Linux-Kernel-Meldungen |
|
|
Meldungen der Benutzerebene |
|
|
Mailsystem |
|
|
System-Daemons |
|
|
Sicherheits-/Autorisierungsmeldungen |
|
|
syslogd-Meldungen |
|
|
Zeilendrucker-Subsystem |
|
|
Netzwerknachrichten-Subsystem |
|
|
UUCP (Unix-to-Unix Copy Protocol) Subsystem |
|
|
Cron-Daemon |
|
|
Sicherheits-/Autorisierungsmeldungen |
|
|
FTP (File Transfer Protocol) Daemon |
|
|
NTP (Network Time Protocol) Daemon |
|
|
Log-Audit |
|
|
Log-Alarm |
|
|
Cron-Daemon |
|
|
Lokale Verwendung 0-7 |
Außerdem wird jeder Nachricht eine Prioritätsstufe zugewiesen:
Code | Schweregrad | Schlüsselwort | Beschreibung |
---|---|---|---|
|
Emergency |
|
System ist unbrauchbar |
|
Alert |
|
Sofortige Maßnahmen erforderlich |
|
Critical |
|
Kritischer Zustand |
|
Error |
|
Fehlerzustand |
|
Warning |
|
Warnung |
|
Notice |
|
Normaler aber signifikanter Zustand |
|
Informational |
|
Information |
|
Debug |
|
Debug-Level-Meldungen |
Hier ein Auszug der rsyslog.conf
vom System mit Debian GNU/Linux 10 (buster) mit einigen Beispielregeln:
############### #### RULES #### ############### # First some standard log files. Log by facility. # auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Some "catch-all" log files. # *.=debug;\ auth,authpriv.none;\ news.none;mail.none -/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages
Das Regelformat lautet: <facility>.<priority>
<action>
Der Selektor <facility>.<priority>
filtert die übereinstimmenden Meldungen. Die Prioritätsebenen sind hierarchisch inklusiv, was bedeutet, dass rsyslog Nachrichten mit der angegebenen Priorität und höher abgleichen wird. Der Selektor <action>
zeigt an, welche Aktion ausgeführt, d.h. wohin die Log-Meldung gesendet werden soll. Hier einige Beispiele:
auth,authpriv.* /var/log/auth.log
Unabhängig von ihrer Priorität (*
) werden alle Meldungen von den Facilities auth
oder authpriv
nach /var/log/auth.log
gesendet.
*.*;auth,authpriv.none -/var/log/syslog
Alle Nachrichten werden unabhängig von ihrer Priorität (*
) von allen Einrichtungen (*
) unter Ausschluss derjenigen von auth
oder authpriv
(Suffix .none
) nach /var/log/syslog
geschrieben. Das Minuszeichen (-
) vor dem Pfad verhindert übermäßige Schreibvorgänge auf der Festplatte. Beachten Sie das Semikolon (;
), um den Selektor aufzuteilen, und das Komma (,
), um zwei Einrichtungen in derselben Regel (auth,authpriv
) zu verketten.
mail.err /var/log/mail.err
Nachrichten von der Facility mail
mit einer Prioritätsstufe von error
oder höher (critical
, alert
oder emergency
) werden an /var/log/mail.err
gesendet.
*.=debug;\ auth,authpriv.none;\ news.none;mail.none -/var/log/debug
Nachrichten von allen Einrichtungen mit der Priorität debug
und keiner anderen (=
) werden nach /var/log/debug
geschrieben — mit Ausnahme aller Nachrichten, die von den Einrichtungen auth
, authpriv
, news
und mail
kommen (beachten Sie die Syntax: ;\
).
Manuelle Einträge in das System-Log: logger
Der Befehl logger
ist nützlich für Shellskripte oder für Testzwecke. Der Befehl hängt jede Nachricht, die er empfängt, an /var/log/syslog
an (oder an /var/log/messages
, wenn die Protokollierung auf einem entfernten zentralen Log-Server erfolgt, wie wir später noch sehen werden):
carol@debian:~$ logger this comment goes into "/var/log/syslog"
Um die letzte Zeile in /var/log/syslog
auszugeben, nutzen Sie den Befehl tail
mit der Option -1
:
root@debian:~# tail -1 /var/log/syslog Sep 17 17:55:33 debian carol: this comment goes into /var/log/syslog
rsyslog
als zentraler Log-Server
Zur Erläuterung dieses Themas werden wir einen neuen Host zu unserem Setup hinzufügen. Der Aufbau lautet wie folgt:
Rolle | Hostname | OS | IP-Adresse |
---|---|---|---|
Zentraler Log-Server |
|
openSUSE Leap 15.1 |
192.168.1.6 |
Client |
|
Debian GNU/Linux 10 (buster) |
192.168.1.4 |
Beginnen wir mit der Konfiguration des Servers und stellen zunächst sicher, dass rsyslog
läuft und funktioniert:
root@suse-server:~# systemctl status rsyslog rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-09-17 18:45:58 CEST; 7min ago Docs: man:rsyslogd(8) http://www.rsyslog.com/doc/ Main PID: 832 (rsyslogd) Tasks: 5 (limit: 4915) CGroup: /system.slice/rsyslog.service └─832 /usr/sbin/rsyslogd -n -iNONE
openSUSE wird mit einer eigenen Konfigurationsdatei für Remote-Logging ausgeliefert: /etc/rsyslog.d/remote.conf
. Wir aktivieren den Empfang von Nachrichten von Clients (entfernten Hosts) über TCP und kommentieren dazu die Zeilen aus, die das Modul laden und den TCP-Server auf Port 514 starten:
# ######### Receiving Messages from Remote Hosts ########## # TCP Syslog Server: # provides TCP syslog reception and GSS-API (if compiled to support it) $ModLoad imtcp.so # load module ##$UDPServerAddress 10.10.0.1 # force to listen on this IP only $InputTCPServerRun 514 # Starts a TCP server on selected port # UDP Syslog Server: #$ModLoad imudp.so # provides UDP syslog reception ##$UDPServerAddress 10.10.0.1 # force to listen on this IP only #$UDPServerRun 514 # start a UDP syslog server at standard port 514
Danach müssen wir den rsyslog-Dienst neu starten und überprüfen, ob der Server auf Port 514 lauscht:
root@suse-server:~# systemctl restart rsyslog root@suse-server:~# netstat -nltp | grep 514 [sudo] password for root: tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 2263/rsyslogd tcp6 0 0 :::514 :::* LISTEN 2263/rsyslogd
Anschließend sollten wir die Ports in der Firewall öffnen und die Konfiguration neu laden:
root@suse-server:~# firewall-cmd --permanent --add-port 514/tcp success root@suse-server:~# firewall-cmd --reload success
Note
|
Mit der Version openSUSE Leap 15.0 hat |
Templates und Filterbedingungen
Standardmäßig werden die Logs des Clients in die Datei /var/log/messages
des Servers geschrieben — zusammen mit denen des Servers selbst. Wir werden jedoch ein Template (Vorlage) und eine Filter Condition (Filterbedingung) erstellen, um die Logs unseres Clients in eigenen, übersichtlichen Verzeichnissen speichern zu lassen. Dazu fügen wir Folgendes in /etc/rsyslog.conf
(oder /etc/rsyslog.d/remote.conf
) ein:
$template RemoteLogs,"/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log" if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs & stop
- Template
-
Die Vorlage entspricht der ersten Zeile und ermöglicht es Ihnen, ein Format für Log-Namen mit dynamischer Dateinamengenerierung anzugeben. Eine Vorlage besteht aus:
-
Template-Direktive (
$template
) -
Name des Templates (
RemoteLogs
) -
Template-Text (
"/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log"
) -
Optionen (optional)
-
Unser Template heißt RemoteLogs
und sein Text besteht aus einem Pfad in /var/log
. Alle Logs unseres entfernten Hosts werden im Verzeichnis remotehosts
abgelegt, wo ein Unterverzeichnis, basierend auf dem Hostnamen des Rechners (%HOSTNAME%
), erstellt wird. Jeder Dateiname in diesem Verzeichnis besteht aus dem Datum (%$NOW%
), dem Schweregrad (Priorität) der Meldung im Textformat (%syslogseverity-text%
) und dem Suffix .log
. Die Wörter zwischen den Prozentzeichen sind Properties und erlauben Ihnen den Zugriff auf den Inhalt der Log-Meldung (Datum, Priorität etc.). Eine syslog
-Meldung hat eine Reihe wohldefinierter Eigenschaften, die Sie in Templates verwenden können. Auf diese Eigenschaften wird mit dem sogenannten Property Replacer zugegriffen — über den sie auch zu ändern sind --, was bedeutet, dass sie zwischen Prozentzeichen geschrieben werden.
- Filter Condition
-
Die übrigen zwei Zeilen entsprechen der Filterbedingung und der zugehörigen Aktion:
-
Ausdrucksbasierter Filter (
if $FROMHOST-IP=='192.168.1.4'
) -
Aktion (
then ?RemoteLogs
,& stop
)
-
Die erste Zeile prüft die IP-Adresse des entfernten Rechners, der das Protokoll sendet, und, wenn mit der unseres Debian-Clients übereinstimmend, wendet das Template RemoteLogs
an. Die letzte Zeile (& stop
) garantiert, dass die Meldungen nicht gleichzeitig an /var/log/messages
gesendet werden, sondern nur an Dateien im Verzeichnis /var/log/remotehosts
.
Note
|
Mehr über Templates, Eigenschaften und Regeln erfahren Sie in den Manpages zu |
Mit der aktualisierten Konfiguration starten wir rsyslog
neu und bestätigen, dass es noch kein Verzeichnis remotehosts
in /var/log
gibt:
root@suse-server:~# systemctl restart rsyslog root@suse-server:~# ls /var/log/ acpid chrony localmessages pbl.log Xorg.0.log alternatives.log cups mail pk_backend_zypp Xorg.0.log.old apparmor firebird mail.err samba YaST2 audit firewall mail.info snapper.log zypp boot.log firewalld mail.warn tallylog zypper.log boot.msg krb5 messages tuned boot.omsg lastlog mysql warn btmp lightdm NetworkManager wtmp
Der Server ist nun konfiguriert — wenden wir uns nun dem Client zu.
Auch hier müssen wir sicherstellen, dass rsyslog
installiert ist und läuft:
root@debian:~# sudo systemctl status rsyslog rsyslog.service - System Logging Service Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: Active: active (running) since Thu 2019-09-17 18:47:54 CEST; 7min ago Docs: man:rsyslogd(8) http://www.rsyslog.com/doc/ Main PID: 351 (rsyslogd) Tasks: 4 (limit: 4915) CGroup: /system.slice/rsyslog.service └─351 /usr/sbin/rsyslogd -n
In unserer Beispielumgebung haben wir die Namensauflösung auf dem Client implementiert, indem wir die Zeile 192.168.1.6 suse-server
zu /etc/hosts
hinzugefügt haben. Somit können wir den Server entweder über den Namen (suse-server
) oder die IP-Adresse (192.168.1.6
) ansprechen.
Unser Debian-Client hat keine Datei remote.conf
in /etc/rsyslog.d/
, also wenden wir unsere Konfigurationen in /etc/rsyslog.conf
an. Dazu schreiben wir die folgende Zeile an das Ende der Datei:
*.* @@suse-server:514
Abschließend starten wir rsyslog
neu:
root@debian:~# systemctl restart rsyslog
Gehen wir nun zurück zu unserem suse-server
und überprüfen die Existenz von remotehosts
in /var/log
:
root@suse-server:~# ls /var/log/remotehosts/debian/ 2019-09-17.info.log 2019-09-17.notice.log
Wir haben bereits zwei Logs in /var/log/remotehosts
, wie in unserem Template beschrieben. Um diesen Abschnitt abzuschließen, führen wir tail -f
von 2019-09-17.notice.log
auf suse-server
aus, während wir ein Log manuell von unserem Debian-Client senden und bestätigen, dass die Meldungen wie erwartet an die Logdatei angehängt werden (die Option -t
liefert ein Tag für unsere Meldung):
root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log 2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' 2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17 2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)
carol@debian:~$ logger -t DEBIAN-CLIENT Hi from 192.168.1.4
root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log 2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' 2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17 2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run) 2019-09-17T21:04:21+02:00 debian DEBIAN-CLIENT: Hi from 192.168.1.4
Der Mechanismus der Log-Rotation
Logs rotieren regelmäßig, was zwei Hauptzwecken dient:
-
Verhindern, dass ältere Logdateien mehr Speicherplatz als nötig belegen.
-
Logs auf eine überschaubare Länge reduzieren, um sie leichter abzurufen.
Das Dienstprogramm für die Log-Rotation heißt logrotate
, und seine Aufgabe umfasst Aktionen wie das Verschieben von Logdateien unter einem neuen Namen, das Archivieren und/oder Komprimieren, manchmal das Versenden von E-Mails an den Systemadministrator und schließlich das Löschen der Dateien ab einem gewissen Alter. Es gibt verschiedene Konventionen für die Benennung dieser rotierten Logdateien (z.B. Hinzufügen eines Suffixes mit dem Datum zum Dateinamen). Gängige Praxis ist jedoch das einfache Hinzufügen eines Suffixes mit einer Ganzzahl:
root@debian:~# ls /var/log/messages* /var/log/messages /var/log/messages.1 /var/log/messages.2.gz /var/log/messages.3.gz /var/log/messages.4.gz
Schauen wir uns an, was bei der nächsten Log-Rotation passiert:
-
messages.4.gz
wird gelöscht und geht verloren. -
Der Inhalt von
messages.3.gz
wird nachmessages.4.gz
verschoben. -
Der Inhalt von
messages.2.gz
wird nachmessages.3.gz
verschoben. -
Der Inhalt von
messages.1
wird nachmessages.2.gz
verschoben. -
Der Inhalt von
messages
wird nachmessages.1
verschoben —messages
ist leer und bereit, neue Protokolleinträge aufzunehmen.
Beachten Sie, dass — gemäß den logrotate
-Direktiven, die wir noch kennenlernen werden — die drei älteren Logdateien komprimiert sind, die beiden jüngsten jedoch nicht. Außerdem werden wir die Protokolle der letzten 4-5 Wochen aufbewahren. Um Nachrichten zu lesen, die 1 Woche alt sind, werden wir messages.1
konsultieren (und so weiter).
logrotate
wird als automatisierter Prozess oder Cron-Job täglich durch das Skript /etc/cron.daily/logrotate
ausgeführt und liest die Konfigurationsdatei /etc/logrotate.conf
. Diese Datei enthält einige globale Optionen und ist gut kommentiert, denn zu Beginn jeder Option steht eine kurze Erläuterung:
carol@debian:~$ sudo less /etc/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 # uncomment this if you want your log files compressed #compress # packages drop log rotation information into this directory include /etc/logrotate.d (...)
Wie Sie sehen, sind auch die Konfigurationsdateien in /etc/logrotate.d
für bestimmte Pakete enthalten. Diese Dateien enthalten größtenteils lokale Definitionen und geben an, welche Logs rotiert werden sollen — denken Sie daran, dass lokale Definitionen Vorrang vor globalen haben und dass spätere Definitionen frühere überschreiben. Im Folgenden sehen Sie einen Auszug aus einer Definition in /etc/logrotate.d/rsyslog
:
/var/log/messages { rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate invoke-rc.d rsyslog rotate > /dev/null endscript }
Jede Direktive ist von ihrem Wert durch Leerzeichen und/oder ein optionales Gleichheitszeichen (=
) getrennt. Die Angaben zwischen postrotate
und endscript
müssen in jeweils einer eigenen Zeile stehen. Die Erklärung lautet wie folgt:
rotate 4
-
Bewahrt die Logs von 4 Wochen.
weekly
-
Rotiert die Logdateien wöchentlich.
missingok
-
Keine Fehlermeldung ausgeben, wenn die Logdatei fehlt, sondern einfach mit der nächsten fortfahren.
notifempty
-
Nicht rotieren, wenn das Log leer ist.
compress
-
Logdateien mit
gzip
komprimieren (Standard). delaycompress
-
Komprimierung der vorherigen Logdatei auf den nächsten Rotationszyklus verschieben (nur wirksam in Kombination mit
compress
). Dies ist nützlich, wenn einem Programm nicht gesagt werden kann, dass es seine Logdatei schließen soll, und es daher möglicherweise noch eine Zeit lang in die vorherige Logdatei schreibt. sharedscripts
-
Bezogen auf prerotate- und postrotate-Skripte. Um zu verhindern, dass ein Skript mehrfach ausgeführt wird, führen Sie die Skripte nur einmal aus, unabhängig davon, wie viele Logdateien mit einem bestimmten Muster übereinstimmen (z.B.
/var/log/mail/*
). Die Skripte werden jedoch nicht ausgeführt, wenn keines der Logs im Muster rotiert werden muss. Werden die Skripte mit Fehlern beendet, werden außerdem alle verbleibenden Aktionen für alle Logs nicht ausgeführt. postrotate
-
Beginn eines postrotate-Skripts anzeigen.
invoke-rc.d rsyslog rotate > /dev/null
-
/bin/sh
verwenden, uminvoke-rc.d rsyslog rotate > /dev/null
nach dem Rotieren der Logs auszuführen. endscript
-
Ende des postrotate-Skripts anzeigen.
Note
|
Eine vollständige Liste der Direktiven und Erklärungen finden Sie in der Manpage von |
Der Kernel-Ringpuffer
Da der Kernel mehrere Meldungen generiert, bevor rsyslogd
beim Booten zur Verfügung steht, bedarf es eines Mechanismus zur Registrierung dieser Meldungen. Hier kommt der Kernel Ring Buffer (Kernel-Ringpuffer) ins Spiel, eine Datenstruktur fester Größe — daher verschwinden die ältesten Nachrichten, wenn der Log wächst.
Der Befehl dmesg
gibt den Kernel-Ringpuffer aus. Aufgrund der Größe des Puffers werden Sie ihn normalerweise in Kombination mit dem Textfilterprogramm grep
nutzen, etwa um nach Meldungen zu suchen, die sich auf USB-Geräte beziehen:
root@debian:~# dmesg | grep "usb" [ 1.241182] usbcore: registered new interface driver usbfs [ 1.241188] usbcore: registered new interface driver hub [ 1.250968] usbcore: registered new device driver usb [ 1.339754] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.19 [ 1.339756] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 (...)
Geführte Übungen
-
Welche Dienstprogramme/Befehle würden Sie in den folgenden Szenarien verwenden:
Zweck und Protokolldatei Dienstprogramm Lese
/var/log/syslog.7.gz
Lese
/var/log/syslog
Filtere für das Wort
renewal
in/var/log/syslog
Lese
/var/log/faillog
Lese
/var/log/syslog
dynamisch -
Ordnen Sie die folgenden Logeinträge so, dass sie eine gültige Logmeldung mit der richtigen Struktur darstellen:
-
debian-server
-
sshd
-
[515]:
-
Sep 13 21:47:56
-
Server listening on 0.0.0.0 port 22
Die richtige Reihenfolge ist:
-
-
Welche Regeln würden Sie zu
/etc/rsyslog.conf
hinzufügen, um folgende Aufgaben zu erfüllen:-
Alle Nachrichten der Facility
mail
mit einer Priorität/Schwere voncrit
(und höher) nach/var/log/mail.crit
senden: -
Alle Nachrichten der Facility
mail
mit den Prioritätenalert
undemergency
nach/var/log/mail.urgent
senden: -
Alle Nachrichten (unabhängig von Facility und Priorität) nach
/var/log/allmessages
senden, außer jenen, die von den Facilitiescron
undntp
kommen: -
Wenn alle erforderlichen Einstellungen richtig konfiguriert sind, zunächst alle Nachrichten der Facility
mail
an einen entfernten Host mit der IP-Adresse192.168.1.88
unter Verwendung von TCP und Angabe des Standardports senden: -
Alle Meldungen mit der Priorität
warning
(und zwar nurwarning
) unabhängig von ihrer Facility nach/var/log/warnings
schreiben, um übermäßiges Schreiben auf die Festplatte zu verhindern:
-
-
Betrachten Sie folgenden Abschnitt aus
/etc/logrotate.d/samba
und erklären Sie die verschiedenen Optionen:carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba /var/log/samba/log.smbd { weekly missingok rotate 7 postrotate [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null endscript compress delaycompress notifempty }
Option Bedeutung weekly
missingok
rotate 7
postrotate
endscript
compress
delaycompress
notifyempty
Offene Übungen
-
Im Abschnitt “Templates und Filterbedingungen” haben wir einen ausdrucksbasierten Filter als Filterbedingung verwendet. Eigenschaftsbasierte Filter sind ein weiterer Typus, den es nur in
rsyslogd
gibt. Übersetzen Sie unseren ausdrucksbasierten in einen eigenschaftsbasierten Filter:Ausdrucksbasierter Filter Eigenschaftsbasierter Filter if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
-
omusrmsg
ist ein eingebautesrsyslog
-Modul, das die Benachrichtigung von Benutzern erleichtert — es sendet Logmeldungen an das Benutzerterminal. Schreiben Sie eine Regel, um alle èmergency`-Meldungen aller Facilities sowohl an root als auch an den regulären Benutzercarol
zu senden.
Zusammenfassung
In dieser Lektion haben Sie gelernt:
-
Logging ist essentiell für die Systemverwaltung.
-
rsyslogd
ist das Dienstprogramm, das Logs pflegt. -
Einige Dienste kümmern sich selbst um ihre Logs.
-
Logs werden grob in System- und Dienst-/Programm-Logs eingeteilt.
-
Es gibt eine Reihe von Dienstprogrammen, die für das Lesen von Logs geeignet sind:
less
,more
,zless
,zmore
,grep
,head
undtail
. -
Die meisten Logdateien sind Klartextdateien; es gibt jedoch auch eine kleine Anzahl binärer Logdateien.
-
rsyslogd
erhält die relevanten Logging-Informationen aus speziellen Dateien (Sockets und Speicherpuffern), bevor sie verarbeitet werden. -
Um Logs zu klassifizieren, wendet
rsyslogd
Regeln aus/etc/rsyslog.conf
oder/etc/rsyslog.d/*
an. -
Jeder Benutzer kann seine eigenen Meldungen mit dem Dienstprogramm
logger
manuell in das System-Log eintragen. -
rsyslog
speichert bei Bedarf alle Logs über IP-Netzwerke hinweg auf einem zentralen Logserver. -
Templates dienen dazu, die Namen von Logdateien dynamisch zu formatieren.
-
Log-Rotation bewirkt zwei Dinge: Sie verhindert, dass alte Logs zu viel Speicherplatz beanspruchen und sie hält die Logs überschaubar.
Lösungen zu den geführten Übungen
-
Welche Dienstprogramme/Befehle würden Sie in den folgenden Szenarien verwenden:
Zweck und Protokolldatei Dienstprogramm Lese
/var/log/syslog.7.gz
zmore
oderzless
Lese
/var/log/syslog
more
oderless
Filtere für das Wort
renewal
in/var/log/syslog
grep
Lese
/var/log/faillog
faillog -a
Lese
/var/log/syslog
dynamicallytail -f
-
Ordnen Sie die folgenden Logeinträge so, dass sie eine gültige Logmeldung mit der richtigen Struktur darstellen:
-
debian-server
-
sshd
-
[515]:
-
Sep 13 21:47:56
-
Server listening on 0.0.0.0 port 22
Die richtige Reihenfolge ist:
Sep 13 21:47:56 debian-server sshd[515]: Server listening on 0.0.0.0 port 22
-
-
Welche Regeln würden Sie zu
/etc/rsyslog.conf
hinzufügen, um folgende Aufgaben zu erfüllen:-
Alle Nachrichten der Facility
mail
mit einer Priorität/Schwere voncrit
(und höher) nach/var/log/mail.crit
senden:mail.crit /var/log/mail.crit
-
Alle Nachrichten der Facility
mail
mit den Prioritätenalert
undemergency
nach/var/log/mail.urgent
senden:mail.alert /var/log/mail.urgent
-
Alle Nachrichten (unabhängig von Facility und Priorität) nach
/var/log/allmessages
senden, außer jenen, die von den Facilitiescron
undntp
kommen:*.*;cron.none;ntp.none /var/log/allmessages
-
Wenn alle erforderlichen Einstellungen richtig konfiguriert sind, zunächst alle Nachrichten der Facility
mail
an einen entfernten Host mit der IP-Adresse192.168.1.88
unter Verwendung von TCP und Angabe des Standardports senden:mail.* @@192.168.1.88:514
-
Alle Meldungen mit der Priorität
warning
(und zwar nurwarning
) unabhängig von ihrer Facility nach/var/log/warnings
schreiben, um übermäßiges Schreiben auf die Festplatte zu verhindern:*.=warning -/var/log/warnings
-
-
Betrachten Sie folgenden Abschnitt aus
/etc/logrotate.d/samba
und erklären Sie die verschiedenen Optionen:carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba /var/log/samba/log.smbd { weekly missingok rotate 7 postrotate [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null endscript compress delaycompress notifempty }
Option Bedeutung weekly
Logs wöchentlich rotieren
missingok
Keine Fehlermeldung ausgeben, wenn das Log fehlt — mit dem nächsten fortfahren
rotate 7
Logs 7 Wochen aufbewahren
postrotate
Skript in der nachfolgenden Zeile ausführen, nachdem das Log rotiert wurde
endscript
Kennzeichnet das Ende des postrotate-Skripts
compress
Komprimiert die Logs mit
gzip
delaycompress
Verschiebt in Kombination mit
compress
die Komprimierung auf den nächsten Rotationszyklusnotifyempty
Rotiert das Log nicht, wenn es leer ist
Lösungen zu den offenen Übungen
-
Im Abschnitt “Templates und Filterbedingungen” haben wir einen ausdrucksbasierten Filter als Filterbedingung verwendet. Eigenschaftsbasierte Filter sind ein weiterer Typus, den es nur in
rsyslogd
gibt. Übersetzen Sie unseren ausdrucksbasierten in einen eigenschaftsbasierten Filter:Ausdrucksbasierter Filter Eigenschaftsbasierter Filter if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
:fromhost-ip, isequal, "192.168.1.4" ?RemoteLogs
-
omusrmsg
ist ein eingebautesrsyslog
-Modul, das die Benachrichtigung von Benutzern erleichtert (es sendet Protokollmeldungen an das Benutzerterminal). Schreiben Sie eine Regel, um alle Notfallmeldungen aller Einrichtungen sowohl anroot
als auch an den regulären Benutzer `carol`zu senden.*.emerg :omusrmsg:root,carol