Protokolle in Red Hat Enterprise Linux analysieren

Red Hat Enterprise LinuxRed Hat Enterprise LinuxBeginner
Jetzt üben

💡 Dieser Artikel wurde von AI-Assistenten übersetzt. Um die englische Version anzuzeigen, können Sie hier klicken

Einführung

In diesem Lab erhalten Sie praktische Erfahrung in der Analyse und Speicherung von Systemprotokollen auf Red Hat Enterprise Linux 9 unter Verwendung von journalctl und rsyslog. Sie beginnen mit dem Verständnis der Kernarchitektur der Systemprotokollierung, einschließlich der Rollen von systemd-journald und rsyslog, und der Identifizierung wichtiger Protokolldateien. Anschließend lernen Sie, Syslog-Dateien mit gängigen Befehlen zu überprüfen und zu filtern, benutzerdefinierte Syslog-Nachrichten manuell zu senden sowie Systemjournal-Einträge mit journalctl zu untersuchen und zu filtern. Das Lab behandelt auch die Konfiguration der persistenten Systemjournal-Speicherung und die Aufrechterhaltung einer genauen Systemzeit mithilfe von timedatectl und chronyd, wodurch Sie mit wesentlichen Fähigkeiten für die Systemanalyse und -fehlerbehebung ausgestattet werden.

Systemprotokollarchitektur und wichtige Dateien verstehen

In diesem Schritt lernen Sie die grundlegenden Komponenten der Systemprotokollierung in Red Hat Enterprise Linux 9 kennen, wobei der Schwerpunkt auf den Diensten systemd-journald und rsyslog sowie den von ihnen verwalteten wichtigen Protokolldateien liegt. Das Verständnis dieser Architektur ist für eine effektive Systemanalyse und -fehlerbehebung unerlässlich.

Zunächst wollen wir uns den Dienst systemd-journald ansehen. Dieser Dienst ist das Herzstück der Ereignisprotokollierung des Betriebssystems. Er sammelt Ereignismeldungen aus verschiedenen Quellen, darunter der Systemkernel, frühe Boot-Prozesse, Standardausgabe/Fehler von Daemons und Syslog-Ereignisse. Der Dienst systemd-journald speichert diese Protokolle in einer strukturierten, indizierten Binärdatei, dem sogenannten Journal.

Als Nächstes betrachten wir den Dienst rsyslog. Während systemd-journald Protokolle sammelt, liest rsyslog Syslog-Nachrichten aus dem Journal, sobald sie eintreffen. Anschließend verarbeitet er diese Nachrichten und zeichnet sie in traditionellen Protokolldateien im Verzeichnis /var/log auf oder leitet sie basierend auf seiner Konfiguration an andere Dienste weiter. Diese rsyslog-Dateien bleiben auch nach Neustarts erhalten.

Werfen wir einen Blick auf einige der wichtigen Protokolldateien, die von rsyslog im Verzeichnis /var/log verwaltet werden. Sie können den Befehl ls verwenden, um den Inhalt dieses Verzeichnisses aufzulisten.

ls /var/log

Sie sehen eine Liste verschiedener Protokolldateien. Je nach Ihrem System sollten Sie Dateien wie anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure und andere sehen. Einige der häufigsten sind:

  • /var/log/messages: Diese Datei enthält die meisten allgemeinen Syslog-Nachrichten, mit Ausnahme derer, die sich auf Authentifizierung, E-Mail-Verarbeitung, Ausführung geplanter Jobs und Debugging beziehen.
  • /var/log/secure: Diese Datei speichert Syslog-Nachrichten, die sich auf Sicherheits- und Authentifizierungsereignisse beziehen.
  • /var/log/maillog: Diese Datei enthält Syslog-Nachrichten über den Mailserver.
  • /var/log/cron: Diese Datei protokolliert Syslog-Nachrichten über die Ausführung geplanter Jobs.
  • /var/log/boot.log: Diese Datei enthält Nicht-Syslog-Konsolenmeldungen über den Systemstart.

Um den Inhalt dieser Dateien anzuzeigen, können Sie Befehle wie cat, less oder tail verwenden. Beachten Sie, dass die meisten Protokolldateien in /var/log Root-Rechte zum Lesen erfordern, daher müssen Sie sudo verwenden. Lassen Sie uns beispielsweise die letzten Zeilen der Datei /var/log/messages mit tail anzeigen.

sudo tail /var/log/messages

Sie können auch den Inhalt der Datei /var/log/secure anzeigen, was für die Sicherheitsüberwachung wichtig ist.

sudo tail /var/log/secure

Das Verständnis des Zwecks dieser Dateien hilft Ihnen, relevante Informationen schnell zu finden, wenn Sie Systemprobleme beheben.

Syslog-Dateien mit gängigen Befehlen überprüfen und filtern

In diesem Schritt lernen Sie, wie Sie Syslog-Dateien mithilfe gängiger Linux-Befehle effektiv überprüfen und filtern können. Syslog-Nachrichten werden nach Facility (welches Subsystem die Nachricht erzeugt) und Priority (der Schweregrad der Nachricht) kategorisiert. Das Verständnis dieser Kategorien ist für eine effiziente Protokollanalyse unerlässlich.

Zunächst wollen wir das Konzept der Syslog-Facilities und -Prioritäten betrachten.

Syslog-Facilities: Diese geben die Quelle der Protokollnachricht an. Beispiele sind kern (Kernel-Nachrichten), user (Nachrichten auf Benutzerebene), mail (Nachrichten des Mailsystems), daemon (Nachrichten von System-Daemons), auth (Authentifizierungs- und Sicherheitsnachrichten) und cron (Nachrichten des Clock-Daemons).

Syslog-Prioritäten: Diese definieren den Schweregrad der Nachricht, der von emerg (System unbrauchbar) bis debug (Debugging-Nachricht) reicht. Die Reihenfolge der Schweregrade von höchster zu niedrigster Priorität ist: emerg, alert, crit, err, warning, notice, info, debug.

Protokolldateien können sehr groß werden, was es schwierig macht, bestimmte Informationen zu finden. Daher ist das Filtern unerlässlich. Sie können Befehle wie grep, awk und sed verwenden, um den Inhalt von Protokolldateien zu filtern.

Beginnen wir damit, den gesamten Inhalt von /var/log/messages mit less anzuzeigen. Mit diesem Befehl können Sie durch die Datei scrollen. Drücken Sie q, um less zu beenden. Denken Sie daran, sudo zu verwenden, da Protokolldateien Root-Rechte zum Lesen erfordern.

sudo less /var/log/messages

Versuchen wir nun, Nachrichten zu filtern. Angenommen, Sie interessieren sich für Nachrichten, die sich auf die Authentifizierung beziehen. Diese Nachrichten finden Sie in der Regel in /var/log/secure. Verwenden Sie grep, um in /var/log/secure nach Zeilen zu suchen, die das Wort "authentication" enthalten. Denken Sie daran, sudo zu verwenden, um auf die Protokolldatei zuzugreifen.

sudo grep "authentication" /var/log/secure

Möglicherweise sehen Sie keine Ausgabe, wenn es keine aktuellen Authentifizierungsnachrichten gibt. Versuchen wir es mit einem gebräuchlicheren Suchbegriff, wie z. B. "sshd", der sich auf den SSH-Daemon bezieht.

sudo grep "sshd" /var/log/secure

Sie sollten eine Ausgabe sehen, die SSH-Daemon-Aktivitäten, Authentifizierungsversuche oder andere sicherheitsrelevante Ereignisse anzeigt. Die genaue Ausgabe hängt von der aktuellen Systemaktivität ab und kann Einträge wie die folgenden enthalten:

Dec 16 10:15:30 host sshd[1234]: Accepted publickey for labex from 172.25.0.10 port 12345 ssh2
Dec 16 10:15:30 host sshd[1234]: pam_unix(sshd:session): session opened for user labex(uid=1000) by (uid=0)
...output omitted...

Protokollnachrichten enthalten auch Zeitstempel. Sie können Nachrichten nach Datum und Uhrzeit filtern. Um beispielsweise Nachrichten von einem bestimmten Datum anzuzeigen, können Sie grep mit dem Datum kombinieren. Versuchen wir, Nachrichten vom heutigen Datum in /var/log/messages zu finden. Verwenden Sie das aktuelle Datumsformat, das in Ihren Systemprotokollen angezeigt wird.

sudo grep "$(date '+%b %d')" /var/log/messages

Log-Datei-Rotation (Protokolldatei-Rotation):
Um zu verhindern, dass Protokolldateien zu viel Festplattenspeicher verbrauchen, verwenden Systeme logrotate. Dieses Dienstprogramm rotiert Protokolldateien, benennt alte um (z. B. /var/log/messages wird zu /var/log/messages-20220320) und erstellt neue, leere. Nach einer bestimmten Zeit (in der Regel vier Wochen) werden die ältesten rotierten Protokolldateien verworfen. Ein geplanter Job führt täglich logrotate aus, um diesen Prozess zu verwalten.

Sie können rotierte Protokolldateien beobachten, indem Sie den Inhalt von /var/log erneut auflisten. Möglicherweise sehen Sie Dateien mit Datumsangaben oder Erweiterungen wie .gz (wenn sie komprimiert wurden).

ls -l /var/log/messages*

Beispielausgabe:

-rw-------. 1 root root 123456 Mar 20 23:59 /var/log/messages
-rw-------. 1 root root  78901 Mar 13 23:59 /var/log/messages-20220320
-rw-------. 1 root root  54321 Mar 06 23:59 /var/log/messages-20220313.gz
...output omitted...

Dies zeigt, wie logrotate ältere Protokolldateien verwaltet.

Analysieren wir abschließend die Anatomie eines Syslog-Eintrags. Eine typische Protokollnachricht in /var/log/secure sieht so aus:

Dec 16 10:11:48 host sshd[1433]: Failed password for student from 172.25.0.10 port 59344 ssh2

  • Dec 16 10:11:48: Der Zeitstempel des Protokolleintrags.
  • host: Der Host, der die Protokollnachricht gesendet hat.
  • sshd[1433]: Der Programm- oder Prozessname (sshd) und seine PID (1433), die die Protokollnachricht gesendet haben.
  • Failed password for …: Der eigentliche Nachrichteninhalt.

Das Verständnis dieses Formats hilft Ihnen, Protokolleinträge effektiver zu parsen und zu interpretieren.

Benutzerdefinierte Syslog-Nachrichten manuell senden

In diesem Schritt lernen Sie, wie Sie mithilfe des Befehls logger manuell benutzerdefinierte Syslog-Nachrichten senden können. Dies ist eine nützliche Technik zum Testen von rsyslog-Dienstkonfigurationen oder zum Einfügen benutzerdefinierter Nachrichten in die Systemprotokolle zu Debugging- oder Überwachungszwecken.

Der Befehl logger sendet Nachrichten an den rsyslog-Dienst. Standardmäßig sendet er die Nachricht mit der user-Facility und der notice-Priorität (user.notice), sofern nicht anders mit der Option -p angegeben.

Beginnen wir damit, eine einfache Testnachricht an den Standardprotokollspeicherort zu senden, der sich in der Regel in /var/log/messages befindet.

logger "This is a test message from labex."

Nachdem Sie den Befehl ausgeführt haben, können Sie überprüfen, ob die Nachricht protokolliert wurde, indem Sie die Datei /var/log/messages überprüfen. Verwenden Sie tail, um die letzten Zeilen der Datei anzuzeigen. Denken Sie daran, sudo zu verwenden, um auf die Protokolldatei zuzugreifen.

sudo tail /var/log/messages

Am Ende der Ausgabe sollte Ihre benutzerdefinierte Nachricht angezeigt werden, ähnlich wie diese:

...
Dec 16 10:30:00 host labex: This is a test message from labex.

Versuchen wir nun, eine Nachricht mit einer bestimmten Facility und Priorität zu senden. Erinnern Sie sich aus dem vorherigen Schritt, dass Syslog-Nachrichten nach Facility und Priorität kategorisiert werden. Zum Beispiel bedeutet local7.notice, dass die Nachricht mit der local7-Facility und der notice-Priorität protokolliert wird. Die local7-Facility wird häufig für benutzerdefinierte Anwendungen oder Boot-Nachrichten verwendet und wird in der Regel durch die rsyslog-Konfiguration an /var/log/boot.log weitergeleitet.

Um eine Nachricht an den rsyslog-Dienst zu senden, die in der Protokolldatei /var/log/boot.log aufgezeichnet werden soll, führen Sie den folgenden logger-Befehl aus:

logger -p local7.notice "Log entry created by labex for boot.log"

Überprüfen Sie nun, ob diese Nachricht in /var/log/boot.log geschrieben wurde. Verwenden Sie sudo, um auf die Protokolldatei zuzugreifen.

sudo tail /var/log/boot.log

Sie sollten Ihre benutzerdefinierte Nachricht in der Ausgabe sehen:

...
Dec 16 10:31:00 host labex: Log entry created by labex for boot.log

Dies zeigt, wie Sie steuern können, wo Ihre benutzerdefinierten Nachrichten protokolliert werden, indem Sie die Facility und die Priorität angeben. Diese Fähigkeit ist sehr nützlich zum Testen von rsyslog-Konfigurationen und zum Einfügen bestimmter Ereignisse in Ihre Systemprotokolle.

System-Journal-Einträge mit journalctl untersuchen und filtern

In diesem Schritt lernen Sie, wie Sie System-Journal-Einträge mithilfe des Befehls journalctl untersuchen und filtern können. Wie Sie gelernt haben, speichert der Dienst systemd-journald Protokolldaten in einer strukturierten, indizierten Binärdatei, dem sogenannten Journal. Der Befehl journalctl ist Ihr primäres Werkzeug für die Interaktion mit diesem Journal.

Beginnen wir damit, alle Nachrichten im Journal anzuzeigen. Wenn Sie journalctl ohne Optionen ausführen, werden alle verfügbaren Protokolleinträge angezeigt, beginnend mit dem ältesten. Da Sie als labex mit sudo-Rechten angemeldet sind, haben Sie vollen Zugriff auf das Journal.

journalctl

Sie werden eine große Menge an Ausgabe sehen. Drücken Sie q, um die journalctl-Anzeige zu beenden. Beachten Sie, dass journalctl wichtige Protokollnachrichten hervorhebt: Nachrichten mit der Priorität notice oder warning werden fett formatiert, während Nachrichten mit der Priorität error oder höher rot formatiert werden.

Lassen Sie uns nun einige gängige journalctl-Optionen zum Filtern und Anzeigen bestimmter Einträge untersuchen.

1. Anzeigen der letzten N Protokolleinträge (Option -n):
Standardmäßig zeigt journalctl -n die letzten 10 Protokolleinträge an. Sie können eine andere Zahl angeben, z. B. die letzten 5 Einträge:

journalctl -n 5

Sie sollten die 5 neuesten Protokolleinträge sehen.

2. Neuen Journal-Einträgen folgen (Option -f):
Ähnlich wie der Befehl tail -f gibt die Option journalctl -f die letzten 10 Zeilen des Systemjournals aus und gibt weiterhin neue Journal-Einträge aus, sobald diese angehängt werden. Dies ist sehr nützlich für die Echtzeitüberwachung.

journalctl -f

Um diese kontinuierliche Ausgabe zu beenden, drücken Sie Ctrl+C.

3. Filtern nach Priorität (Option -p):
Sie können die Ausgabe nach der Prioritätsebene der Journal-Einträge filtern. Die Option journalctl -p zeigt Einträge mit einer angegebenen Prioritätsebene (nach Name oder Nummer) oder höher an. Die Prioritätsebenen sind in aufsteigender Reihenfolge debug, info, notice, warning, err, crit, alert und emerg.

Listen wir Journal-Einträge mit der Priorität err oder höher auf:

journalctl -p err

Möglicherweise sehen Sie Fehlermeldungen, die sich auf verschiedene Systemkomponenten beziehen.

4. Filtern nach systemd-Unit (Option -u):
Sie können Nachrichten für eine angegebene systemd-Unit anzeigen, indem Sie die Option journalctl -u und den Unit-Namen verwenden. Um beispielsweise Protokolle speziell für den Dienst sshd anzuzeigen:

journalctl -u sshd.service

Dadurch werden alle Protokolleinträge im Zusammenhang mit dem SSH-Daemon angezeigt.

5. Filtern nach Zeitbereich (Optionen --since und --until):
Wenn Sie nach bestimmten Ereignissen suchen, können Sie die Ausgabe auf einen bestimmten Zeitraum beschränken. Sowohl die Optionen --since als auch --until akzeptieren ein Zeitargument im Format "YYYY-MM-DD hh:mm:ss". Anführungszeichen sind erforderlich, wenn das Argument Leerzeichen enthält. Sie können auch relative Begriffe wie yesterday, today, tomorrow oder Zeitdauern wie "-1 hour" verwenden.

Lassen Sie uns alle Journal-Einträge ab Beginn des heutigen Tages anzeigen:

journalctl --since today

Zeigen wir nun Einträge der letzten Stunde an:

journalctl --since "-1 hour"

6. Ausführliche Ausgabe anzeigen (Option -o verbose):
Um zusätzliche Details zu jedem Protokolleintrag anzuzeigen, einschließlich interner Journalfelder, können Sie die Option -o verbose verwenden. Dies kann bei der erweiterten Fehlerbehebung hilfreich sein.

journalctl -n 1 -o verbose

Dadurch wird der letzte Protokolleintrag mit allen seinen ausführlichen Details angezeigt. Beachten Sie Felder wie _COMM (Befehlsname), _EXE (Pfad zur ausführbaren Datei), _PID (Prozess-ID), _UID (Benutzer-ID) und _SYSTEMD_UNIT (systemd-Unit). Diese Felder können für eine präzisere Filterung verwendet werden.

Um beispielsweise Einträge von einem bestimmten sshd-Prozess mit einer bekannten PID zu finden (Sie können eine PID aus einer vorherigen journalctl -u sshd.service-Ausgabe erhalten):

journalctl _SYSTEMD_UNIT=sshd.service _PID=<PID_NUMBER>

Ersetzen Sie <PID_NUMBER> durch eine tatsächliche PID, die Sie aus sshd-Einträgen beobachtet haben. Wenn Sie beispielsweise sshd[1433] gesehen haben, würden Sie _PID=1433 verwenden.

journalctl _SYSTEMD_UNIT=sshd.service _PID=1433

Dieser Befehl zeigt, wie Sie mehrere Filter kombinieren können, um Ihre Suche im Journal einzugrenzen.

Konfigurieren der persistenten System-Journal-Speicherung

In diesem Schritt lernen Sie, wie Sie das System-Journal so konfigurieren, dass es auch nach Neustarts erhalten bleibt. Standardmäßig speichert Red Hat Enterprise Linux 9 das System-Journal im Verzeichnis /run/log, einem temporären Dateisystem. Dies bedeutet, dass alle Journal-Einträge nach einem Systemneustart gelöscht werden. Um historische Protokolldaten zu erhalten, müssen Sie den Dienst systemd-journald für die persistente Speicherung konfigurieren.

Die Konfiguration für systemd-journald befindet sich in der Datei /etc/systemd/journald.conf. Der Parameter Storage in dieser Datei bestimmt, ob Journale flüchtig oder persistent gespeichert werden.

Der Parameter Storage kann auf einen der folgenden Werte gesetzt werden:

  • persistent: Speichert Journale im Verzeichnis /var/log/journal, das auch nach Neustarts erhalten bleibt. Wenn dieses Verzeichnis nicht existiert, erstellt systemd-journald es.
  • volatile: Speichert Journale im temporären Verzeichnis /run/log/journal. Daten in /run bleiben nach Neustarts nicht erhalten. Dies ist das Standardverhalten, wenn Storage nicht explizit gesetzt ist und /var/log/journal nicht existiert.
  • auto: Wenn das Verzeichnis /var/log/journal existiert, verwendet systemd-journald die persistente Speicherung; andernfalls verwendet es die flüchtige Speicherung. Dies ist die Standardeinstellung, wenn Sie den Parameter Storage nicht setzen.
  • none: Es wird kein Speicher verwendet. Alle Protokolle werden verworfen, obwohl sie weiterhin weitergeleitet werden können.

Ändern wir die Datei /etc/systemd/journald.conf, um die persistente Journal-Speicherung zu aktivieren. Sie verwenden sudo nano, um diese Datei zu bearbeiten.

sudo nano /etc/systemd/journald.conf

Suchen Sie im nano-Editor den Abschnitt [Journal]. Entkommentieren Sie die Zeile Storage (entfernen Sie das # am Anfang) und setzen Sie ihren Wert auf persistent.

Ihre Datei sollte in etwa so aussehen (nur relevante Zeilen werden angezeigt):

[Journal]
Storage=persistent
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#Audit=no
#FlushIntervalSec=
#SyncIntervalSec=
#ReadKMsg=yes
#Audit=yes

Nachdem Sie die Änderung vorgenommen haben, speichern Sie die Datei, indem Sie Ctrl+X drücken, dann Y zum Bestätigen des Speicherns und Enter zum Bestätigen des Dateinamens.

Damit die Änderungen wirksam werden, müssen Sie den Dienst systemd-journald neu starten. Da diese Umgebung ein Docker-Container ist, ist systemctl nicht verfügbar. Stattdessen simulieren wir die Auswirkung des Neustarts des Dienstes, indem wir sicherstellen, dass das Verzeichnis /var/log/journal erstellt wird und die korrekten Berechtigungen hat, was systemd-journald in einer nicht containerisierten Umgebung beim Neustart tun würde.

Erstellen wir zunächst das Verzeichnis, falls es nicht existiert, und legen wir die entsprechenden Berechtigungen fest.

sudo mkdir -p /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

Um nun zu überprüfen, ob die persistente Speicherung konfiguriert und aktiv ist, können Sie prüfen, ob das Verzeichnis /var/log/journal Unterverzeichnisse mit hexadezimalen Namen und .journal-Dateien enthält. Diese Dateien speichern die strukturierten und indizierten Journal-Einträge.

ls -l /var/log/journal

Sie sollten ein Unterverzeichnis mit einem langen hexadezimalen Namen sehen (z. B. 4ec03abd2f7b40118b1b357f479b3112). In diesem Verzeichnis finden Sie .journal-Dateien.

ls -l /var/log/journal/ <YOUR_HEX_ID> /

Ersetzen Sie <YOUR_HEX_ID> durch die tatsächliche hexadezimale ID, die Sie in der vorherigen ls-Befehlsausgabe gefunden haben. Zum Beispiel:

ls -l /var/log/journal/4ec03abd2f7b40118b1b357f479b3112/

Sie sollten Dateien wie system.journal und möglicherweise user-1000.journal sehen.

Auch bei persistenten Journalen behält das System nicht alle Daten für immer. Das Journal verfügt über einen integrierten Log-Rotation-Mechanismus. Sie können Größenbeschränkungen und Aufbewahrungsfristen in der Datei /etc/systemd/journald.conf mithilfe von Parametern wie SystemMaxUse, SystemKeepFree, SystemMaxFileSize und MaxRetentionSec konfigurieren.

Wenn persistente Journale aktiviert sind, enthält die Ausgabe von journalctl Einträge vom aktuellen Systemstart sowie von früheren Systemstarts. Um die Ausgabe auf einen bestimmten Systemstart zu beschränken, verwenden Sie die Option journalctl -b.

So listen Sie alle erkannten Systemstart-Ereignisse auf:

journalctl --list-boots

Sie sehen eine Liste der Boot-IDs und ihrer entsprechenden Zeitbereiche. Der aktuelle Boot ist normalerweise 0. Frühere Boots sind negative Zahlen (-1, -2 usw.).

So zeigen Sie nur Einträge vom aktuellen Systemstart an:

journalctl -b

So zeigen Sie Einträge vom vorherigen Boot an (z. B. dem vor dem aktuellen, normalerweise -1):

journalctl -b -1

Hiermit ist die Konfiguration der persistenten Journal-Speicherung abgeschlossen.

Aufrechterhaltung der genauen Systemzeit mit timedatectl und chronyd

In diesem Schritt lernen Sie, wie Sie die genaue Systemzeit mithilfe des Befehls timedatectl verwalten und die Rolle des Dienstes chronyd verstehen. Eine genaue Zeitmessung ist entscheidend für die Protokollierung, Sicherheit und viele Netzwerkdienste.

1. Verwenden von timedatectl zur Verwaltung der Systemzeit und Zeitzonen:

Der Befehl timedatectl bietet einen Überblick über die aktuellen zeitrelevanten Systemeinstellungen, einschließlich der lokalen Zeit, der Weltzeit (UTC), der RTC-Zeit, der Zeitzone und des NTP-Synchronisationsstatus.

Überprüfen wir die aktuellen Zeiteinstellungen Ihres Systems:

timedatectl

Sie sollten eine Ausgabe ähnlich dieser sehen (die genaue Uhrzeit und das Datum spiegeln Ihre aktuelle Systemzeit wider):

               Local time: Sun 2025-06-15 21:46:11 EDT
           Universal time: Mon 2025-06-16 01:46:11 UTC
                 RTC time: Mon 2025-06-16 01:46:10
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sie können alle verfügbaren Zeitzonen mit der Option list-timezones auflisten:

timedatectl list-timezones | less

Drücken Sie q, um less zu beenden. Die Zeitzonen werden basierend auf der IANA (Internet Assigned Numbers Authority) Zeitzonendatenbank benannt, typischerweise nach Kontinent/Ozean und dann nach der größten Stadt.

Um die Zeitzone des Systems zu ändern, verwenden Sie die Option set-timezone. Ändern wir beispielsweise die Zeitzone in America/Phoenix. Sie benötigen dafür sudo-Rechte.

sudo timedatectl set-timezone America/Phoenix

Überprüfen Sie nun die Änderung:

timedatectl

Sie sollten sehen, dass die Zeitzone auf America/Phoenix aktualisiert wurde.

Sie können die aktuelle Systemzeit auch manuell mit der Option set-time einstellen. Das Format lautet "YYYY-MM-DD hh:mm:ss", aber Sie können das Datum oder die Uhrzeit weglassen. Stellen wir die Uhrzeit auf 09:00:00 (für das aktuelle Datum) ein.

sudo timedatectl set-time 09:00:00

Überprüfen Sie die Zeitänderung:

timedatectl

Schließlich aktiviert oder deaktiviert die Option set-ntp die NTP-Synchronisierung für die automatische Zeitanpassung. Sie nimmt true oder false als Argument. Deaktivieren wir die NTP-Synchronisierung für einen Moment (wir werden sie später wieder aktivieren).

sudo timedatectl set-ntp false

Überprüfen Sie den NTP-Dienststatus:

timedatectl

Sie sollten NTP service: inactive sehen.

2. Verstehen und Konfigurieren des Dienstes chronyd:

Der Dienst chronyd ist ein Daemon, der die Real-Time Clock (RTC) des Systems genau hält, indem er sie mit NTP (Network Time Protocol) Servern synchronisiert. Er ist der Standard-NTP-Client in Red Hat Enterprise Linux.

Die Konfigurationsdatei für chronyd ist /etc/chrony.conf. Standardmäßig verwendet er öffentliche NTP-Server. In einem realen Szenario könnten Sie ihn so konfigurieren, dass er interne NTP-Server verwendet.

Betrachten wir die Standarddatei chrony.conf.

cat /etc/chrony.conf

Sie sehen Zeilen, die mit server oder pool beginnen, die die NTP-Quellen definieren. Die Option iburst wird empfohlen, da sie schnell vier Messungen vornimmt, um eine genauere initiale Synchronisierung zu erreichen.

Der stratum einer NTP-Zeitquelle gibt ihre Qualität an. Ein stratum 0 ist eine Referenzuhr, stratum 1 ist direkt an eine Referenzuhr angeschlossen, und stratum 2 synchronisiert sich von einem stratum 1-Server.

Da systemctl in dieser Containerumgebung nicht verfügbar ist, können wir chronyd nicht direkt neu starten, um Konfigurationsänderungen anzuwenden. Wir können die Konfigurationsänderung jedoch simulieren, indem wir die Datei ändern.

Aktivieren wir die NTP-Synchronisierung mit timedatectl erneut.

sudo timedatectl set-ntp true

Überprüfen Sie den NTP-Dienststatus erneut:

timedatectl

Sie sollten NTP service: active sehen.

Der Befehl chronyc fungiert als Client für den Dienst chronyd. Sie können ihn verwenden, um den Synchronisationsstatus zu überwachen. Der Befehl chronyc sources zeigt die aktuellen Zeitquellen und ihren Synchronisationsstatus an.

chronyc sources -v

Die Ausgabe zeigt Details zu den NTP-Quellen. Das Sternchen * im Feld S (Source state) gibt die Quelle an, mit der sich chronyd derzeit synchronisiert.

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 100.100.61.88                 1   5   377    16  +1824us[+2180us] +/-   85ms
...output omitted...

Diese Ausgabe bestätigt, dass Ihr System seine Zeit aktiv mit einem NTP-Server synchronisiert.

Zusammenfassung

In diesem Lab haben wir ein umfassendes Verständnis der Systemprotokollarchitektur in Red Hat Enterprise Linux 9 erlangt und uns dabei auf das Zusammenspiel zwischen systemd-journald und rsyslog konzentriert. Wir haben gelernt, dass systemd-journald strukturierte, indizierte Binärprotokolle im Journal sammelt und speichert, während rsyslog diese Nachrichten verarbeitet und sie in traditionelle Protokolldateien in /var/log schreibt. Wir haben wichtige Protokolldateien wie /var/log/messages, /var/log/secure und andere untersucht und das Überprüfen und Filtern von Syslog-Dateien mithilfe gängiger Befehle geübt. Wir haben auch gelernt, wie man benutzerdefinierte Syslog-Nachrichten manuell sendet.

Darüber hinaus haben wir uns mit der Untersuchung und Filterung von Systemjournal-Einträgen mit journalctl befasst und seine Fähigkeiten für den Zugriff auf detaillierte Systemereignisse verstanden. Anschließend haben wir die persistente Systemjournal-Speicherung konfiguriert, um die Aufbewahrung von Protokolldaten über Neustarts hinweg sicherzustellen. Schließlich haben wir die Aufrechterhaltung der genauen Systemzeit mithilfe von timedatectl und chronyd behandelt und deren Bedeutung für genaue Protokollzeitstempel und die allgemeine Systemintegrität erkannt. Dieses Lab vermittelte wesentliche Fähigkeiten für eine effektive Systemanalyse und Fehlerbehebung durch robustes Protokollmanagement.