Linux Professional Institute Learning Logo.
Weiter zum Inhalt
  • Home
    • Alle Ressourcen
    • LPI Lernmaterialien
    • Mitmachen
    • Publishing Partner
    • Publishing Partner werden
    • Über uns
    • FAQ
    • Mitwirkende
    • Roadmap
    • Kontakt
  • LPI.org
108.2 Lektion 1
Thema 105: Shells und Shell-Skripte
105.1 Die Shell-Umgebung anpassen und verwenden
  • 105.1 Lektion 1
  • 105.1 Lektion 2
  • 105.1 Lektion 3
105.2 Einfache Skripte anpassen oder schreiben
  • 105.2 Lektion 1
  • 105.2 Lektion 2
Thema 106: Benutzerschnittstellen und Desktops
106.1 X11 installieren und konfigurieren
  • 106.1 Lektion 1
106.2 Grafische Desktops
  • 106.2 Lektion 1
106.3 Barrierefreiheit
  • 106.3 Lektion 1
Thema 107: Administrative Aufgaben
107.1 Benutzer- und Gruppenkonten und dazugehörige Systemdateien verwalten
  • 107.1 Lektion 1
  • 107.1 Lektion 2
107.2 Systemadministrationsaufgaben durch Einplanen von Jobs automatisieren
  • 107.2 Lektion 1
  • 107.2 Lektion 2
107.3 Lokalisierung und Internationalisierung
  • 107.3 Lektion 1
Thema 108: Grundlegende Systemdienste
108.1 Die Systemzeit verwalten
  • 108.1 Lektion 1
  • 108.1 Lektion 2
108.2 Systemprotokollierung
  • 108.2 Lektion 1
  • 108.2 Lektion 2
108.3 Grundlagen von Mail Transfer Agents (MTA)
  • 108.3 Lektion 1
108.4 Drucker und Druckvorgänge verwalten
  • 108.4 Lektion 1
Thema 109: Netzwerkgrundlagen
109.1 Grundlagen von Internetprotokollen
  • 109.1 Lektion 1
  • 109.1 Lektion 2
109.2 Persistente Netzwerkkonfiguration
  • 109.2 Lektion 1
  • 109.2 Lektion 2
109.3 Grundlegende Netzwerkfehlerbehebung
  • 109.3 Lektion 1
  • 109.3 Lektion 2
109.4 Clientseitiges DNS konfigurieren
  • 109.4 Lektion 1
Thema 110: Sicherheit
110.1 Administrationsaufgaben für Sicherheit durchführen
  • 110.1 Lektion 1
110.2 Einen Rechner absichern
  • 110.2 Lektion 1
110.3 Daten durch Verschlüsselung schützen
  • 110.3 Lektion 1
  • 110.3 Lektion 2
How to get certified
  1. Thema 108: Grundlegende Systemdienste
  2. 108.2 Systemprotokollierung
  3. 108.2 Lektion 1

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 d in Daemon-Namen, z.B. klogd oder rsyslogd.

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 und access_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 und other_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 und mysql-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 und log.smbd.

Note

Der genaue Name und der Inhalt der Logsateien variiert bei verschiedenen Linux-Distributionen. Es gibt auch distributionspezifische Logs, z.B. /var/log/dpkg.log (mit Informationen zu dpkg-Paketen) in Debian GNU/Linux und seinen Derivaten.

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 oder more

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 oder zmore

Wie less und more, aber für Logs, die mit gzip komprimiert sind (eine übliche Funktion von logrotate):

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 der tail 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 (oder w):

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 oder last -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. gnome-logs und KSystemLog.

Wie Meldungen in Logs umgewandelt werden

Der folgende Vorgang veranschaulicht, wie eine Meldung in eine Logdatei geschrieben wird:

  1. Anwendungen, Dienste und der Kernel schreiben Nachrichten in spezielle Dateien (Sockets und Speicherpuffer), z.B. /dev/log oder /dev/kmsg.

  2. rsyslogd holt die Informationen aus den Sockets oder Speicherpuffern.

  3. Abhängig von den Regeln in /etc/rsyslog.conf und/oder den Dateien in /etc/ryslog.d/ verschiebt rsyslogd 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 systemctl list-sockets --all.

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

0

kern

Linux-Kernel-Meldungen

1

user

Meldungen der Benutzerebene

2

mail

Mailsystem

3

daemon

System-Daemons

4

auth, authpriv

Sicherheits-/Autorisierungsmeldungen

5

syslog

syslogd-Meldungen

6

lpr

Zeilendrucker-Subsystem

7

news

Netzwerknachrichten-Subsystem

8

uucp

UUCP (Unix-to-Unix Copy Protocol) Subsystem

9

cron

Cron-Daemon

10

auth, authpriv

Sicherheits-/Autorisierungsmeldungen

11

ftp

FTP (File Transfer Protocol) Daemon

12

ntp

NTP (Network Time Protocol) Daemon

13

security

Log-Audit

14

console

Log-Alarm

15

cron

Cron-Daemon

16 - 23

local0 through local7

Lokale Verwendung 0-7

Außerdem wird jeder Nachricht eine Prioritätsstufe zugewiesen:

Code Schweregrad Schlüsselwort Beschreibung

0

Emergency

emerg, panic

System ist unbrauchbar

1

Alert

alert

Sofortige Maßnahmen erforderlich

2

Critical

crit

Kritischer Zustand

3

Error

err, error

Fehlerzustand

4

Warning

warn, warning

Warnung

5

Notice

notice

Normaler aber signifikanter Zustand

6

Informational

info

Information

7

Debug

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

suse-server

openSUSE Leap 15.1

192.168.1.6

Client

debian

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 firewalld die klassische SuSEFirewall2 vollständig ersetzt.

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 rsyslog.conf.

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:

  1. messages.4.gz wird gelöscht und geht verloren.

  2. Der Inhalt von messages.3.gz wird nach messages.4.gz verschoben.

  3. Der Inhalt von messages.2.gz wird nach messages.3.gz verschoben.

  4. Der Inhalt von messages.1 wird nach messages.2.gz verschoben.

  5. Der Inhalt von messages wird nach messages.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, um invoke-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 logrotate.conf.

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

  1. 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

  2. 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:

  3. 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 von crit (und höher) nach /var/log/mail.crit senden:

    • Alle Nachrichten der Facility mail mit den Prioritäten alert und emergency 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 Facilities cron und ntp kommen:

    • Wenn alle erforderlichen Einstellungen richtig konfiguriert sind, zunächst alle Nachrichten der Facility mail an einen entfernten Host mit der IP-Adresse 192.168.1.88 unter Verwendung von TCP und Angabe des Standardports senden:

    • Alle Meldungen mit der Priorität warning (und zwar nur warning) unabhängig von ihrer Facility nach /var/log/warnings schreiben, um übermäßiges Schreiben auf die Festplatte zu verhindern:

  4. 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

  1. 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

  2. omusrmsg ist ein eingebautes rsyslog-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 Benutzer carol 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 und tail.

  • 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

  1. Welche Dienstprogramme/Befehle würden Sie in den folgenden Szenarien verwenden:

    Zweck und Protokolldatei Dienstprogramm

    Lese /var/log/syslog.7.gz

    zmore oder zless

    Lese /var/log/syslog

    more oder less

    Filtere für das Wort renewal in /var/log/syslog

    grep

    Lese /var/log/faillog

    faillog -a

    Lese /var/log/syslog dynamically

    tail -f

  2. 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
  3. 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 von crit (und höher) nach /var/log/mail.crit senden:

      mail.crit                 /var/log/mail.crit
    • Alle Nachrichten der Facility mail mit den Prioritäten alert und emergency 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 Facilities cron und ntp 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-Adresse 192.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 nur warning) unabhängig von ihrer Facility nach /var/log/warnings schreiben, um übermäßiges Schreiben auf die Festplatte zu verhindern:

      *.=warning                        -/var/log/warnings
  4. 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 Rotationszyklus

    notifyempty

    Rotiert das Log nicht, wenn es leer ist

Lösungen zu den offenen Übungen

  1. 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

  2. omusrmsg ist ein eingebautes rsyslog-Modul, das die Benachrichtigung von Benutzern erleichtert (es sendet Protokollmeldungen an das Benutzerterminal). Schreiben Sie eine Regel, um alle Notfallmeldungen aller Einrichtungen sowohl an root als auch an den regulären Benutzer `carol`zu senden.

    *.emerg                        :omusrmsg:root,carol

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Nächste Lektion

108.2 Systemprotokollierung (108.2 Lektion 2)

Nächste Lektion lesen

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

LPI ist eine Non-Profit-Organisation.

© 2023 Linux Professional Institute (LPI) ist eine globale Organisation für Zertifizierungsstandards und zur Karriereplanung für Open-Source-Profis. Mit mehr als 200.000 Zertifikatsinhabern ist es die weltweit erste und größte herstellerneutrale Linux- und Open-Source-Zertifizierungsstelle. LPI verfügt über zertifizierte Fachleute in über 180 Ländern, bietet Prüfungen in mehreren Sprachen an und hat Hunderte von Trainingspartnern.

Unser Ziel ist es, wirtschaftliche und kreative Möglichkeiten für alle zu ermöglichen, indem wir Open-Source-Wissens- und Kompetenzzertifizierungen allgemein zugänglich machen.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Kontaktieren Sie uns
  • Datenschutz und Cookie-Richtlinien

Haben Sie einen Fehler entdeckt oder möchten Sie helfen, diese Seite zu verbessern? Lassen Sie es uns wissen.

© 1999–2023 The Linux Professional Institute Inc. Alle Rechte vorbehalten.