Analysieren von Protokollen in Red Hat Enterprise Linux

Einführung

In diesem Lab sammeln Sie praktische Erfahrungen bei der Analyse und Speicherung von Systemprotokollen unter Red Hat Enterprise Linux 9 mithilfe von journalctl und rsyslog. Sie beginnen mit dem Verständnis der Kernarchitektur der Systemprotokollierung, einschließlich der Rollen von systemd-journald und rsyslog, und identifizieren wichtige Protokolldateien. Anschließend lernen Sie, Syslog-Dateien mit gängigen Befehlen zu überprüfen und zu filtern, manuell benutzerdefinierte Syslog-Nachrichten zu senden sowie System-Journal-Einträge mit journalctl zu untersuchen und zu filtern. Das Lab behandelt zudem die Konfiguration einer persistenten System-Journal-Speicherung sowie die Aufrechterhaltung einer präzisen Systemzeit mittels timedatectl und chronyd, wodurch Sie mit wesentlichen Fähigkeiten für die Systemanalyse und Fehlerbehebung ausgestattet werden.

Systemprotokoll-Architektur 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 entscheidend für eine effektive Systemanalyse und Fehlerbehebung.

Zuerst betrachten wir den Dienst systemd-journald. Dieser Dienst bildet den Kern der Ereignisprotokollierung des Betriebssystems. Er sammelt Ereignismeldungen aus verschiedenen Quellen, einschließlich des System-Kernels, früher Boot-Prozesse, Standardausgabe/-fehler von Daemons und Syslog-Ereignissen. 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 es diese Nachrichten und schreibt sie in traditionelle Protokolldateien im Verzeichnis /var/log oder leitet sie basierend auf seiner Konfiguration an andere Dienste weiter. Diese rsyslog-Dateien bleiben über Neustarts hinweg erhalten.

Lassen Sie uns einige der wichtigen Protokolldateien untersuchen, 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. Abhängig von Ihrem System sollten Sie Dateien wie anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure und andere sehen. Zu den gebräuchlichsten gehören:

• /var/log/messages: Diese Datei enthält die meisten allgemeinen Syslog-Nachrichten, mit Ausnahme derjenigen, die sich auf Authentifizierung, E-Mail-Verarbeitung, Ausführung geplanter Aufgaben und Debugging beziehen.
• /var/log/secure: Diese Datei speichert Syslog-Nachrichten zu Sicherheits- und Authentifizierungsereignissen.
• /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 Aufgaben.
• /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 für die meisten Protokolldateien in /var/log Root-Rechte zum Lesen erforderlich sind, 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, die für Sicherheitsaudits wichtig ist.

sudo tail /var/log/secure

Das Verständnis des Zwecks dieser Dateien hilft Ihnen dabei, bei der Fehlerbehebung schnell relevante Informationen zu finden.

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

In diesem Schritt lernen Sie, wie Sie Syslog-Dateien effektiv mit gängigen Linux-Befehlen überprüfen und filtern. Syslog-Nachrichten werden nach facility (welches Subsystem die Nachricht erzeugt) und priority (Schweregrad der Nachricht) kategorisiert. Das Verständnis dieser Kategorien ist für eine effiziente Protokollanalyse entscheidend.

Zuerst betrachten wir das Konzept der Syslog-Facilities und -Prioritäten.

Syslog-Facilities: Diese geben die Quelle der Protokollnachricht an. Beispiele sind kern (Kernel-Meldungen), user (Benutzerebene-Meldungen), mail (Mail-System-Meldungen), daemon (System-Daemon-Meldungen), auth (Authentifizierungs- und Sicherheitsmeldungen) und cron (Clock-Daemon-Meldungen).

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

Protokolldateien können sehr groß werden, was es schwierig macht, spezifische Informationen zu finden. Daher ist 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 blättern. 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 im Zusammenhang mit authentication. Diese Nachrichten finden sich typischerweise 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 Authentifizierungsmeldungen gibt. Versuchen wir einen gebräuchlicheren Suchbegriff wie "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 zeigt. Die genaue Ausgabe hängt von der aktuellen Systemaktivität ab und kann Einträge enthalten wie:

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 zu sehen, 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 erscheint.

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

Protokolldatei-Rotation: Um zu verhindern, dass Protokolldateien zu viel Speicherplatz beanspruchen, verwenden Systeme logrotate. Dieses Dienstprogramm rotiert Protokolldateien, benennt alte um (z. B. wird /var/log/messages zu /var/log/messages-20220320) und erstellt neue, leere Dateien. Nach einem bestimmten Zeitraum (typischerweise vier Wochen) werden die ältesten rotierten Protokolldateien gelöscht. Ein geplanter Job führt logrotate täglich 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 Datumserweiterungen oder .gz-Erweiterungen (falls 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.

Lassen Sie uns abschließend den Aufbau eines Syslog-Eintrags analysieren. 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 dabei, Protokolleinträge effektiver zu parsen und zu interpretieren.

Benutzerdefinierte Syslog-Nachrichten manuell senden

In diesem Schritt lernen Sie, wie Sie mit dem Befehl logger manuell benutzerdefinierte Syslog-Nachrichten senden. 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 nichts anderes mit der Option -p angegeben wird.

Beginnen wir damit, eine einfache Testnachricht an den Standard-Protokollspeicherort zu senden, der typischerweise /var/log/messages ist.

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

Sie sollten Ihre benutzerdefinierte Nachricht am Ende der Ausgabe sehen, ähnlich wie hier:

...
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 daran, dass Syslog-Nachrichten nach Facility und Priorität kategorisiert sind. Zum Beispiel bedeutet local7.notice, dass die Nachricht mit der local7-Facility und der notice-Priorität protokolliert wird. Die local7-Facility wird oft für benutzerdefinierte Anwendungen oder Boot-Meldungen verwendet und wird durch die rsyslog-Konfiguration typischerweise an /var/log/boot.log weitergeleitet.

Um eine Nachricht an den rsyslog-Dienst zu senden, damit sie in der Protokolldatei /var/log/boot.log aufgezeichnet wird, 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 Priorität angeben. Diese Fähigkeit ist sehr nützlich zum Testen von rsyslog-Konfigurationen und zum Einfügen spezifischer Ereignisse in Ihre Systemprotokolle.

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

In diesem Schritt lernen Sie, wie Sie System-Journal-Einträge mit dem Befehl journalctl untersuchen und filtern. 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 Ausgaben sehen. Drücken Sie q, um den journalctl-Viewer zu beenden. Beachten Sie, dass journalctl wichtige Protokollnachrichten hervorhebt: Nachrichten mit der Priorität notice oder warning sind fett gedruckt, während Nachrichten mit der Priorität error oder höher in roter Schrift erscheinen.

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

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

journalctl -n 5

Sie sollten die 5 aktuellsten Protokolleinträge sehen.

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

journalctl -f

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

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

Lassen Sie uns Journal-Einträge mit der Priorität err oder höher auflisten:

journalctl -p err

Möglicherweise sehen Sie Fehlermeldungen zu verschiedenen Systemkomponenten.

4. Nach systemd-Unit filtern (-u Option): Sie können Nachrichten für eine bestimmte 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

Dies zeigt alle Protokolleinträge an, die sich auf den SSH-Daemon beziehen.

5. Nach Zeitbereich filtern (--since und --until Optionen): Wenn Sie nach bestimmten Ereignissen suchen, können Sie die Ausgabe auf einen bestimmten Zeitrahmen begrenzen. Beide Optionen, --since und --until, akzeptieren ein Zeitargument im Format "YYYY-MM-DD hh:mm:ss". Doppelte 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 seit Beginn des heutigen Tages anzeigen:

journalctl --since today

Lassen Sie uns nun Einträge aus der letzten Stunde anzeigen:

journalctl --since "-1 hour"

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

journalctl -n 1 -o verbose

Dies zeigt den letzten Protokolleintrag mit allen ausführlichen Details. 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 bei 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.

Persistente System-Journal-Speicherung konfigurieren

In diesem Schritt lernen Sie, wie Sie das System-Journal so konfigurieren, dass es über Neustarts hinweg erhalten bleibt. Standardmäßig speichert Red Hat Enterprise Linux 9 das System-Journal im Verzeichnis /run/log, das ein temporäres Dateisystem ist. Dies bedeutet, dass alle Journal-Einträge nach einem Systemneustart gelöscht werden. Um historische Protokolldaten beizubehalten, müssen Sie den Dienst systemd-journald für 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 über Neustarts hinweg 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 über Neustarts hinweg 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 persistente Speicherung; andernfalls verwendet es flüchtige Speicherung. Dies ist der Standardwert, wenn Sie den Parameter Storage nicht setzen.
• none: Es wird keine Speicherung verwendet. Alle Protokolle werden verworfen, können aber weiterhin weitergeleitet werden.

Lassen Sie uns die Datei /etc/systemd/journald.conf ändern, 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]. Entfernen Sie das Kommentarzeichen (#) vor der Zeile Storage und setzen Sie den Wert auf persistent.

Ihre Datei sollte ähnlich wie diese 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 Strg+X, dann Y zur Bestätigung des Speicherns und Enter zur Bestätigung des Dateinamens drücken.

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 den Effekt des Neustarts des Dienstes, indem wir sicherstellen, dass das Verzeichnis /var/log/journal erstellt wurde und die richtigen Berechtigungen besitzt, was systemd-journald in einer nicht-containerisierten Umgebung beim Neustart tun würde.

Erstellen wir zuerst das Verzeichnis, falls es nicht existiert, und setzen die entsprechenden Berechtigungen.

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 Mechanismus zur Protokollrotation. 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 journalctl-Ausgabe schließlich Einträge vom aktuellen Systemstart sowie von früheren Systemstarts. Um die Ausgabe auf einen bestimmten Systemstart zu begrenzen, verwenden Sie die Option journalctl -b.

Um alle erkannten Systemstart-Ereignisse aufzulisten:

journalctl --list-boots

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

Um Einträge nur vom aktuellen Systemstart anzuzeigen:

journalctl -b

Um Einträge vom vorherigen Boot anzuzeigen (z. B. den vor dem aktuellen, normalerweise -1):

journalctl -b -1

Dies schließt die Konfiguration der persistenten Journal-Speicherung ab.

Genaue Systemzeit mit timedatectl und chronyd aufrechterhalten

In diesem Schritt lernen Sie, wie Sie die Systemzeit mit dem Befehl timedatectl genau halten und die Rolle des Dienstes chronyd verstehen. Eine genaue Zeitmessung ist entscheidend für Protokollierung, Sicherheit und viele Netzwerkdienste.

1. Verwendung von timedatectl zur Verwaltung von Systemzeit und Zeitzonen:

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

Lassen Sie uns die aktuellen Zeiteinstellungen Ihres Systems überprüfen:

timedatectl

Sie sollten eine Ausgabe ähnlich dieser sehen (die genaue Zeit 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 sind basierend auf der IANA-Zeitzonendatenbank (Internet Assigned Numbers Authority) benannt, typischerweise nach Kontinent/Ozean und dann der größten Stadt.

Um die Zeitzone des Systems zu ändern, verwenden Sie die Option set-timezone. Ändern wir beispielsweise die Zeitzone auf America/Phoenix. Sie benötigen hierfü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.

Bevor Sie die Systemzeit manuell ändern, müssen Sie die NTP-Synchronisation vorübergehend deaktivieren. Die Option set-ntp aktiviert oder deaktiviert die NTP-Synchronisation für die automatische Zeitanpassung. Sie akzeptiert true oder false als Argument. Deaktivieren wir die NTP-Synchronisation für einen Moment (wir werden sie später wieder aktivieren).

sudo timedatectl set-ntp false

Überprüfen Sie den Status des NTP-Dienstes:

timedatectl

Sie sollten NTP service: inactive sehen.

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

sudo timedatectl set-time 09:00:00

Überprüfen Sie die Zeitänderung:

timedatectl

2. Verständnis und Konfiguration des Dienstes chronyd:

Der Dienst chronyd ist ein Daemon, der die Echtzeituhr (RTC) des Systems genau hält, indem er sie mit NTP-Servern (Network Time Protocol) 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.

Lassen Sie uns die Standarddatei chrony.conf anzeigen.

cat /etc/chrony.conf

Sie sehen Zeilen, die mit server oder pool beginnen und die NTP-Quellen definieren. Die Option iburst wird empfohlen, da sie vier Messungen schnell durchführt, um eine genauere anfängliche Synchronisation zu erreichen.

Das stratum einer NTP-Zeitquelle gibt deren Qualität an. Ein stratum 0 ist eine Referenzuhr, stratum 1 ist direkt mit einer Referenzuhr verbunden, und stratum 2 synchronisiert sich von einem stratum 1-Server.

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

Lassen Sie uns die NTP-Synchronisation mit timedatectl wieder aktivieren.

sudo timedatectl set-ntp true

Überprüfen Sie den Status des NTP-Dienstes 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 deren Synchronisationsstatus an.

chronyc sources -v

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

  .-- 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 Systemprotokoll-Architektur in Red Hat Enterprise Linux 9 gewonnen, wobei wir uns auf das Zusammenspiel zwischen systemd-journald und rsyslog konzentriert haben. Wir haben gelernt, dass systemd-journald strukturierte, indizierte Binärprotokolle im Journal sammelt und speichert, während rsyslog diese Nachrichten verarbeitet und 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 mit gängigen Befehlen geübt. Wir haben auch gelernt, wie man manuell benutzerdefinierte Syslog-Nachrichten sendet.

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