Analyser les journaux dans Red Hat Enterprise Linux

Introduction

Dans ce laboratoire, vous acquerrez une expérience pratique de l'analyse et du stockage des journaux système sur Red Hat Enterprise Linux 9 en utilisant journalctl et rsyslog. Vous commencerez par comprendre l'architecture fondamentale de la journalisation système, y compris les rôles de systemd-journald et rsyslog, ainsi que l'identification des fichiers journaux clés. Par la suite, vous apprendrez à examiner et filtrer les fichiers syslog à l'aide de commandes courantes, à envoyer manuellement des messages syslog personnalisés, et à explorer et filtrer les entrées du journal système avec journalctl. Le laboratoire couvre également la configuration du stockage persistant du journal système et le maintien d'une heure système précise à l'aide de timedatectl et chronyd, vous dotant ainsi des compétences essentielles pour l'analyse et le dépannage du système.

Comprendre l'architecture des journaux système et les fichiers clés

Dans cette étape, vous découvrirez les composants fondamentaux de la journalisation système dans Red Hat Enterprise Linux 9, en vous concentrant spécifiquement sur les services systemd-journald et rsyslog, ainsi que sur les fichiers journaux clés qu'ils gèrent. Comprendre cette architecture est crucial pour une analyse et un dépannage système efficaces.

Tout d'abord, explorons le service systemd-journald. Ce service est au cœur de la journalisation des événements du système d'exploitation. Il collecte les messages d'événements provenant de diverses sources, notamment le noyau système, les processus de démarrage précoces, la sortie/erreur standard des démons et les événements syslog. Le service systemd-journald stocke ces journaux dans un fichier binaire structuré et indexé appelé le journal.

Ensuite, nous examinerons le service rsyslog. Alors que systemd-journald collecte les journaux, rsyslog lit les messages syslog du journal dès leur arrivée. Il traite ensuite ces messages et les enregistre dans des fichiers journaux traditionnels situés dans le répertoire /var/log ou les transmet à d'autres services en fonction de sa configuration. Ces fichiers rsyslog persistent après les redémarrages.

Examinons quelques-uns des fichiers journaux importants gérés par rsyslog dans le répertoire /var/log. Vous pouvez utiliser la commande ls pour lister le contenu de ce répertoire.

ls /var/log

Vous verrez une liste de divers fichiers journaux. Selon votre système, vous devriez voir des fichiers tels que anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure, et d'autres. Parmi les plus courants, on trouve :

/var/log/messages : Ce fichier contient la plupart des messages syslog généraux, à l'exclusion de ceux liés à l'authentification, au traitement du courrier, à l'exécution de tâches planifiées et au débogage.
/var/log/secure : Ce fichier stocke les messages syslog liés aux événements de sécurité et d'authentification.
/var/log/maillog : Ce fichier contient les messages syslog concernant le serveur de messagerie.
/var/log/cron : Ce fichier enregistre les messages syslog concernant l'exécution des tâches planifiées.
/var/log/boot.log : Ce fichier contient des messages de console non-syslog concernant le démarrage du système.

Pour afficher le contenu de ces fichiers, vous pouvez utiliser des commandes comme cat, less ou tail. Notez que la plupart des fichiers journaux dans /var/log nécessitent des privilèges root pour être lus, vous devrez donc utiliser sudo. Par exemple, visualisons les dernières lignes du fichier /var/log/messages en utilisant tail.

sudo tail /var/log/messages

Vous pouvez également consulter le contenu du fichier /var/log/secure, qui est important pour l'audit de sécurité.

sudo tail /var/log/secure

Comprendre l'objectif de ces fichiers vous aidera à localiser rapidement les informations pertinentes lors du dépannage des problèmes système.

Examiner et filtrer les fichiers Syslog avec des commandes courantes

Dans cette étape, vous apprendrez à examiner et filtrer efficacement les fichiers syslog à l'aide de commandes Linux courantes. Les messages Syslog sont classés par facility (quel sous-système produit le message) et priority (la gravité du message). Comprendre ces catégories est crucial pour une analyse efficace des journaux.

Tout d'abord, passons en revue le concept des facilités et priorités Syslog.

Facilités Syslog : Elles indiquent la source du message de journal. Les exemples incluent kern (messages du noyau), user (messages au niveau utilisateur), mail (messages du système de messagerie), daemon (messages des démons système), auth (messages d'authentification et de sécurité) et cron (messages du démon d'horloge).

Priorités Syslog : Elles définissent la gravité du message, allant de emerg (système inutilisable) à debug (message de niveau débogage). L'ordre de gravité, du plus élevé au plus bas, est : emerg, alert, crit, err, warning, notice, info, debug.

Les fichiers journaux peuvent devenir très volumineux, ce qui rend difficile la recherche d'informations spécifiques. Par conséquent, le filtrage est essentiel. Vous pouvez utiliser des commandes comme grep, awk et sed pour filtrer le contenu des fichiers journaux.

Commençons par visualiser l'intégralité du contenu de /var/log/messages en utilisant less. Cette commande vous permet de faire défiler le fichier. Appuyez sur q pour quitter less. N'oubliez pas d'utiliser sudo car les fichiers journaux nécessitent des privilèges root pour être lus.

sudo less /var/log/messages

Maintenant, essayons de filtrer les messages. Supposons que vous soyez intéressé par les messages liés à l' authentification. Ces messages se trouvent généralement dans /var/log/secure. Utilisez grep pour rechercher les lignes contenant le mot "authentication" dans /var/log/secure. N'oubliez pas d'utiliser sudo pour accéder au fichier journal.

sudo grep "authentication" /var/log/secure

Vous pourriez ne voir aucune sortie s'il n'y a pas de messages d'authentification récents. Essayons un terme de recherche plus courant, comme "sshd", qui concerne le démon SSH.

sudo grep "sshd" /var/log/secure

Vous devriez voir une sortie montrant les activités du démon SSH, les tentatives d'authentification ou d'autres événements liés à la sécurité. La sortie exacte dépendra de l'activité actuelle du système et peut inclure des entrées comme :

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

Les messages de journal contiennent également des horodatages. Vous pouvez filtrer les messages par date et heure. Par exemple, pour voir les messages d'une date spécifique, vous pouvez combiner grep avec la date. Essayons de trouver les messages de la date d'aujourd'hui dans /var/log/messages. Utilisez le format de date actuel qui apparaît dans vos journaux système.

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

Rotation des fichiers journaux : Pour éviter que les fichiers journaux ne consomment trop d'espace disque, les systèmes utilisent logrotate. Cet utilitaire fait pivoter les fichiers journaux, renommant les anciens (par exemple, /var/log/messages devient /var/log/messages-20220320) et en créant de nouveaux, vides. Après une certaine période (généralement quatre semaines), les fichiers journaux pivotés les plus anciens sont supprimés. Une tâche planifiée exécute logrotate quotidiennement pour gérer ce processus.

Vous pouvez observer les fichiers journaux pivotés en listant à nouveau le contenu de /var/log. Vous pourriez voir des fichiers avec des extensions de date ou des extensions .gz (s'ils ont été compressés).

ls -l /var/log/messages*

Exemple de sortie :

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

Cela montre comment logrotate gère les anciens fichiers journaux.

Enfin, analysons l'anatomie d'une entrée syslog. Un message de journal typique dans /var/log/secure ressemble à ceci :

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 : L'horodatage de l'entrée de journal.
host : L'hôte qui a envoyé le message de journal.
sshd[1433] : Le nom du programme ou du processus (sshd) et son PID (1433) qui a envoyé le message de journal.
Failed password for … : Le contenu réel du message.

Comprendre ce format vous aide à analyser et interpréter les entrées de journal plus efficacement.

Envoyer manuellement des messages Syslog personnalisés

Dans cette étape, vous apprendrez à envoyer manuellement des messages syslog personnalisés à l'aide de la commande logger. Il s'agit d'une technique utile pour tester les configurations du service rsyslog ou pour injecter des messages personnalisés dans les journaux système à des fins de débogage ou de surveillance.

La commande logger envoie des messages au service rsyslog. Par défaut, elle envoie le message avec la facilité user et la priorité notice (user.notice), sauf indication contraire avec l'option -p.

Commençons par envoyer un simple message de test vers l'emplacement de journalisation par défaut, qui est généralement /var/log/messages.

logger "This is a test message from labex."

Après avoir exécuté la commande, vous pouvez vérifier que le message a été enregistré en consultant le fichier /var/log/messages. Utilisez tail pour afficher les dernières lignes du fichier. N'oubliez pas d'utiliser sudo pour accéder au fichier journal.

sudo tail /var/log/messages

Vous devriez voir votre message personnalisé à la fin de la sortie, similaire à ceci :

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

Maintenant, essayons d'envoyer un message avec une facilité et une priorité spécifiques. Rappelez-vous de l'étape précédente que les messages syslog sont classés par facilité et priorité. Par exemple, local7.notice signifie que le message sera enregistré avec la facilité local7 et la priorité notice. La facilité local7 est souvent utilisée pour des applications personnalisées ou des messages de démarrage, et elle est généralement dirigée vers /var/log/boot.log par la configuration de rsyslog.

Pour envoyer un message au service rsyslog afin qu'il soit enregistré dans le fichier journal /var/log/boot.log, exécutez la commande logger suivante :

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

Maintenant, vérifiez que ce message a bien été écrit dans /var/log/boot.log. Utilisez sudo pour accéder au fichier journal.

sudo tail /var/log/boot.log

Vous devriez voir votre message personnalisé dans la sortie :

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

Cela démontre comment vous pouvez contrôler où vos messages personnalisés sont enregistrés en spécifiant la facilité et la priorité. Cette capacité est très utile pour tester les configurations de rsyslog et pour injecter des événements spécifiques dans vos journaux système.

Explorer et filtrer les entrées du journal système avec journalctl

Dans cette étape, vous apprendrez à explorer et filtrer les entrées du journal système à l'aide de la commande journalctl. Comme vous l'avez appris, le service systemd-journald stocke les données de journalisation dans un fichier binaire structuré et indexé appelé le journal. La commande journalctl est votre outil principal pour interagir avec ce journal.

Commençons par visualiser tous les messages du journal. Lorsque vous exécutez journalctl sans aucune option, il affiche toutes les entrées de journal disponibles, en commençant par la plus ancienne. Comme vous êtes connecté en tant que labex avec des privilèges sudo, vous aurez un accès complet au journal.

journalctl

Vous verrez une grande quantité de sortie. Appuyez sur q pour quitter la visionneuse journalctl. Notez que journalctl met en évidence les messages de journal importants : les messages avec une priorité notice ou warning sont en gras, tandis que les messages avec une priorité error ou supérieure sont en rouge.

Maintenant, explorons quelques options courantes de journalctl pour filtrer et visualiser des entrées spécifiques.

1. Visualiser les N dernières entrées de journal (option -n) : Par défaut, journalctl -n affiche les 10 dernières entrées de journal. Vous pouvez spécifier un nombre différent, par exemple, les 5 dernières entrées :

journalctl -n 5

Vous devriez voir les 5 entrées de journal les plus récentes.

2. Suivre les nouvelles entrées de journal (option -f) : Similaire à la commande tail -f, l'option journalctl -f affiche les 10 dernières lignes du journal système et continue d'afficher les nouvelles entrées de journal au fur et à mesure qu'elles sont ajoutées. C'est très utile pour la surveillance en temps réel.

journalctl -f

Pour quitter cette sortie continue, appuyez sur Ctrl+C.

3. Filtrer par priorité (option -p) : Vous pouvez filtrer la sortie par le niveau de priorité des entrées de journal. L'option journalctl -p affiche les entrées à un niveau de priorité spécifié (par nom ou par numéro) ou supérieur. Les niveaux de priorité, par ordre croissant, sont debug, info, notice, warning, err, crit, alert et emerg.

Listons les entrées de journal à la priorité err ou supérieure :

journalctl -p err

Vous pourriez voir des messages d'erreur liés à divers composants du système.

4. Filtrer par unité systemd (option -u) : Vous pouvez afficher les messages pour une unité systemd spécifiée en utilisant l'option journalctl -u et le nom de l'unité. Par exemple, pour visualiser les journaux spécifiquement pour le service sshd :

journalctl -u sshd.service

Cela affichera toutes les entrées de journal liées au démon SSH.

5. Filtrer par plage horaire (options --since et --until) : Lorsque vous recherchez des événements spécifiques, vous pouvez limiter la sortie à une période donnée. Les options --since et --until prennent un argument temporel au format "YYYY-MM-DD hh:mm:ss". Les guillemets doubles sont requis s'il y a des espaces dans l'argument. Vous pouvez également utiliser des termes relatifs comme yesterday, today, tomorrow, ou des durées comme "-1 hour".

Visualisons toutes les entrées de journal depuis le début d'aujourd'hui :

journalctl --since today

Maintenant, visualisons les entrées de la dernière heure :

journalctl --since "-1 hour"

6. Visualiser une sortie détaillée (option -o verbose) : Pour voir des détails supplémentaires sur chaque entrée de journal, y compris les champs internes du journal, vous pouvez utiliser l'option -o verbose. Cela peut être utile pour un dépannage avancé.

journalctl -n 1 -o verbose

Cela affichera la dernière entrée de journal avec tous ses détails détaillés. Notez des champs comme _COMM (nom de la commande), _EXE (chemin vers l'exécutable), _PID (ID du processus), _UID (ID de l'utilisateur) et _SYSTEMD_UNIT (unité systemd). Ces champs peuvent être utilisés pour un filtrage plus précis.

Par exemple, pour trouver des entrées d'un processus sshd spécifique avec un PID connu (vous pouvez obtenir un PID à partir d'une sortie journalctl -u sshd.service précédente) :

journalctl _SYSTEMD_UNIT=sshd.service _PID=<PID_NUMBER>

Remplacez <PID_NUMBER> par un PID réel que vous avez observé à partir des entrées sshd. Par exemple, si vous avez vu sshd[1433], vous utiliseriez _PID=1433.

journalctl _SYSTEMD_UNIT=sshd.service _PID=1433

Cette commande démontre comment vous pouvez combiner plusieurs filtres pour affiner votre recherche dans le journal.

Configurer le stockage persistant du journal système

Dans cette étape, vous apprendrez à configurer le journal système pour qu'il persiste après les redémarrages. Par défaut, Red Hat Enterprise Linux 9 stocke le journal système dans le répertoire /run/log, qui est un système de fichiers temporaire. Cela signifie que toutes les entrées du journal sont effacées après un redémarrage du système. Pour conserver les données historiques des journaux, vous devez configurer le service systemd-journald pour un stockage persistant.

La configuration de systemd-journald se trouve dans le fichier /etc/systemd/journald.conf. Le paramètre Storage dans ce fichier détermine si les journaux sont stockés de manière volatile ou persistante.

Le paramètre Storage peut être défini sur l'une des valeurs suivantes :

persistent : Stocke les journaux dans le répertoire /var/log/journal, qui persiste après les redémarrages. Si ce répertoire n'existe pas, systemd-journald le créera.
volatile : Stocke les journaux dans le répertoire temporaire /run/log/journal. Les données dans /run ne persistent pas après les redémarrages. C'est le comportement par défaut si Storage n'est pas explicitement défini et que /var/log/journal n'existe pas.
auto : Si le répertoire /var/log/journal existe, systemd-journald utilise le stockage persistant ; sinon, il utilise le stockage volatile. C'est le comportement par défaut si vous ne définissez pas le paramètre Storage.
none : Aucun stockage n'est utilisé. Tous les journaux sont supprimés, bien qu'ils puissent toujours être transmis.

Modifions le fichier /etc/systemd/journald.conf pour activer le stockage persistant du journal. Vous utiliserez sudo nano pour modifier ce fichier.

sudo nano /etc/systemd/journald.conf

À l'intérieur de l'éditeur nano, recherchez la section [Journal]. Décommentez la ligne Storage (supprimez le # au début) et définissez sa valeur sur persistent.

Votre fichier devrait ressembler à ceci (en ne montrant que les lignes pertinentes) :

[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

Après avoir effectué la modification, enregistrez le fichier en appuyant sur Ctrl+X, puis Y pour confirmer l'enregistrement, et Enter pour confirmer le nom du fichier.

Pour que les modifications prennent effet, vous devez redémarrer le service systemd-journald. Comme cet environnement est un conteneur Docker, systemctl n'est pas disponible. Au lieu de cela, nous simulerons l'effet du redémarrage du service en nous assurant que le répertoire /var/log/journal est créé et possède les autorisations correctes, ce que systemd-journald ferait lors d'un redémarrage dans un environnement non conteneurisé.

Tout d'abord, créons le répertoire s'il n'existe pas et définissons les autorisations appropriées.

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

Maintenant, pour vérifier que le stockage persistant est configuré et actif, vous pouvez vérifier si le répertoire /var/log/journal contient des sous-répertoires avec des noms hexadécimaux et des fichiers .journal. Ces fichiers stockent les entrées de journal structurées et indexées.

ls -l /var/log/journal

Vous devriez voir un sous-répertoire avec un long nom hexadécimal (par exemple, 4ec03abd2f7b40118b1b357f479b3112). À l'intérieur de ce répertoire, vous trouverez des fichiers .journal.

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

Remplacez <YOUR_HEX_ID> par l'ID hexadécimal réel que vous avez trouvé dans la sortie de la commande ls précédente. Par exemple :

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

Vous devriez voir des fichiers comme system.journal et éventuellement user-1000.journal.

Même avec des journaux persistants, le système ne conserve pas toutes les données indéfiniment. Le journal dispose d'un mécanisme de rotation des journaux intégré. Vous pouvez configurer des limites de taille et des périodes de rétention dans le fichier /etc/systemd/journald.conf en utilisant des paramètres comme SystemMaxUse, SystemKeepFree, SystemMaxFileSize et MaxRetentionSec.

Enfin, lorsque les journaux persistants sont activés, la sortie de journalctl inclut les entrées du démarrage système actuel ainsi que des démarrages système précédents. Pour limiter la sortie à un démarrage système spécifique, utilisez l'option journalctl -b.

Pour lister tous les événements de démarrage système reconnus :

journalctl --list-boots

Vous verrez une liste d'ID de démarrage et leurs plages horaires correspondantes. Le démarrage actuel est généralement 0. Les démarrages précédents sont des nombres négatifs (-1, -2, etc.).

Pour visualiser les entrées du démarrage système actuel uniquement :

journalctl -b

Pour visualiser les entrées du démarrage précédent (par exemple, celui avant l'actuel, généralement -1) :

journalctl -b -1

Ceci conclut la configuration du stockage persistant du journal.

Maintenir une heure système précise avec timedatectl et chronyd

Dans cette étape, vous apprendrez à maintenir une heure système précise à l'aide de la commande timedatectl et à comprendre le rôle du service chronyd. Une tenue de l'heure précise est cruciale pour la journalisation, la sécurité et de nombreux services réseau.

1. Utiliser timedatectl pour gérer l'heure et les fuseaux horaires du système :

La commande timedatectl fournit une vue d'ensemble des paramètres système actuels liés à l'heure, y compris l'heure locale, l'heure universelle (UTC), l'heure RTC, le fuseau horaire et l'état de synchronisation NTP.

Vérifions les paramètres d'heure actuels de votre système :

timedatectl

Vous devriez voir une sortie similaire à celle-ci (l'heure et la date exactes refléteront votre heure système actuelle) :

               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

Vous pouvez lister tous les fuseaux horaires disponibles en utilisant l'option list-timezones :

timedatectl list-timezones | less

Appuyez sur q pour quitter less. Les fuseaux horaires sont nommés en fonction de la base de données des fuseaux horaires de l'Internet Assigned Numbers Authority (IANA), généralement par continent/océan, puis par la plus grande ville.

Pour changer le fuseau horaire du système, vous utilisez l'option set-timezone. Par exemple, changeons le fuseau horaire pour America/Phoenix. Vous avez besoin des privilèges sudo pour cela.

sudo timedatectl set-timezone America/Phoenix

Maintenant, vérifiez le changement :

timedatectl

Vous devriez voir le fuseau horaire mis à jour sur America/Phoenix.

Avant de modifier manuellement l'heure du système, vous devez désactiver temporairement la synchronisation NTP. L'option set-ntp active ou désactive la synchronisation NTP pour l'ajustement automatique de l'heure. Elle prend true ou false comme argument. Désactivons la synchronisation NTP pour un moment (nous la réactiverons plus tard).

sudo timedatectl set-ntp false

Vérifiez l'état du service NTP :

timedatectl

Vous devriez voir NTP service: inactive.

Maintenant, vous pouvez régler manuellement l'heure actuelle du système en utilisant l'option set-time. Le format est "YYYY-MM-DD hh:mm:ss", mais vous pouvez omettre la date ou l'heure. Réglons l'heure sur 09:00:00 (pour la date actuelle).

sudo timedatectl set-time 09:00:00

Vérifiez le changement d'heure :

timedatectl

2. Comprendre et configurer le service chronyd :

Le service chronyd est un démon qui maintient l'horloge temps réel (RTC) du système précise en la synchronisant avec des serveurs NTP (Network Time Protocol). C'est le client NTP par défaut dans Red Hat Enterprise Linux.

Le fichier de configuration de chronyd est /etc/chrony.conf. Par défaut, il utilise des serveurs NTP publics. Dans un scénario réel, vous pourriez le configurer pour utiliser des serveurs NTP internes.

Visualisons le fichier chrony.conf par défaut.

cat /etc/chrony.conf

Vous verrez des lignes commençant par server ou pool, qui définissent les sources NTP. L'option iburst est recommandée car elle effectue quatre mesures rapidement pour une synchronisation initiale plus précise.

La stratum d'une source de temps NTP indique sa qualité. Une stratum 0 est une horloge de référence, stratum 1 est directement connectée à une horloge de référence, et stratum 2 se synchronise à partir d'un serveur stratum 1.

Comme systemctl n'est pas disponible dans cet environnement de conteneur, nous ne pouvons pas redémarrer directement chronyd pour appliquer les modifications de configuration. Cependant, nous pouvons simuler la modification de configuration en modifiant le fichier.

Réactivons la synchronisation NTP en utilisant timedatectl.

sudo timedatectl set-ntp true

Vérifiez à nouveau l'état du service NTP :

timedatectl

Vous devriez voir NTP service: active.

La commande chronyc agit comme un client du service chronyd. Vous pouvez l'utiliser pour surveiller l'état de la synchronisation. La commande chronyc sources affiche les sources de temps actuelles et leur état de synchronisation.

chronyc sources -v

La sortie affichera des détails sur les sources NTP. L'astérisque * dans le champ S (Source state) indique la source avec laquelle chronyd est actuellement synchronisé.

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

Cette sortie confirme que votre système synchronise activement son heure avec un serveur NTP.

Résumé

Dans ce laboratoire, nous avons acquis une compréhension complète de l'architecture des journaux système dans Red Hat Enterprise Linux 9, en nous concentrant sur l'interaction entre systemd-journald et rsyslog. Nous avons appris que systemd-journald collecte et stocke des journaux binaires structurés et indexés dans le journal, tandis que rsyslog traite ces messages et les écrit dans des fichiers journaux traditionnels dans /var/log. Nous avons exploré des fichiers journaux clés comme /var/log/messages, /var/log/secure, et d'autres, et nous nous sommes entraînés à examiner et filtrer les fichiers syslog à l'aide de commandes courantes. Nous avons également appris à envoyer manuellement des messages syslog personnalisés.

De plus, nous avons approfondi l'exploration et le filtrage des entrées du journal système à l'aide de journalctl, en comprenant ses capacités d'accès aux événements système détaillés. Nous avons ensuite configuré le stockage persistant du journal système pour assurer la rétention des données de journalisation après les redémarrages. Enfin, nous avons couvert le maintien d'une heure système précise à l'aide de timedatectl et chronyd, en reconnaissant son importance pour des horodatages de journaux précis et l'intégrité globale du système. Ce laboratoire a fourni des compétences essentielles pour une analyse et un dépannage système efficaces grâce à une gestion robuste des journaux.