Analyser les journaux sous 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 de base de la journalisation système, y compris les rôles de systemd-journald et rsyslog, et 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 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 en apprendrez davantage sur 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 efficaces du système.

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 de diverses sources, notamment le noyau du système, les premiers processus de démarrage, la sortie/erreur standard des daemons 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 au fur et à mesure qu'ils arrivent. Il traite ensuite ces messages et les enregistre dans des fichiers journaux traditionnels 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. En fonction de votre système, vous devriez voir des fichiers tels que anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure, et d'autres. Certains des plus courants incluent :

• /var/log/messages : Ce fichier contient la plupart des messages syslog généraux, à l'exclusion de ceux liés à l'authentification, au traitement des e-mails, à l'exécution des tâches planifiées et au débogage.
• /var/log/secure : Ce fichier stocke les messages syslog liés à la sécurité et aux événements 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 les messages de la console non-syslog concernant le démarrage du système.

Pour afficher le contenu de ces fichiers, vous pouvez utiliser des commandes telles que 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, examinons les dernières lignes du fichier /var/log/messages en utilisant tail.

sudo tail /var/log/messages

Vous pouvez également afficher 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 (qui 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, examinons le concept des Syslog Facilities et des Priorités.

Syslog Facilities (Facilités Syslog) : Celles-ci indiquent la source du message de journal. Des exemples incluent kern (messages du noyau), user (messages au niveau de l'utilisateur), mail (messages du système de messagerie), daemon (messages des daemons système), auth (messages d'authentification et de sécurité) et cron (messages du daemon d'horloge).

Syslog Priorities (Priorités Syslog) : Celles-ci définissent la gravité du message, allant de emerg (système inutilisable) à debug (message de niveau de 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 telles que grep, awk et sed pour filtrer le contenu des fichiers journaux.

Commençons par afficher 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 daemon SSH.

sudo grep "sshd" /var/log/secure

Vous devriez voir une sortie montrant les activités du daemon 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 telles que :

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 (Log File Rotation) :
Pour empêcher les fichiers journaux de consommer 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 pouvez 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 du journal.
• host : L'hôte qui a envoyé le message du journal.
• sshd[1433] : Le nom du programme ou du processus (sshd) et son PID (1433) qui a envoyé le message du 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 à l'emplacement de journal 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 vérifiant 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 par 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 les applications personnalisées ou les 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 é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 l'endroit 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 principal outil pour interagir avec ce journal.

Commençons par afficher 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. Étant donné que 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 de priorité notice ou warning sont en gras, tandis que les messages de priorité error ou supérieure sont en texte rouge.

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

1. Afficher les N dernières entrées du journal (option -n) :
Par défaut, journalctl -n affiche les 10 dernières entrées du 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 du journal (option -f) :
Semblable à 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 du journal au fur et à mesure qu'elles sont ajoutées. Ceci 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 du 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 du 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 d'une unité systemd spécifiée en utilisant l'option journalctl -u et le nom de l'unité. Par exemple, pour afficher les journaux spécifiquement pour le service sshd :

journalctl -u sshd.service

Cela affichera toutes les entrées du journal liées au daemon SSH.

5. Filtrer par plage de temps (options --since et --until) :
Lorsque vous recherchez des événements spécifiques, vous pouvez limiter la sortie à une période spécifique. Les options --since et --until prennent toutes deux un argument de temps au format "AAAA-MM-JJ hh:mm:ss". Des guillemets doubles sont requis s'il y a des espaces dans l'argument. Vous pouvez également utiliser des termes relatifs comme yesterday (hier), today (aujourd'hui), tomorrow (demain), ou des durées comme "-1 hour" ("-1 heure").

Affichons toutes les entrées du journal depuis le début d'aujourd'hui :

journalctl --since today

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

journalctl --since "-1 hour"

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

journalctl -n 1 -o verbose

Cela affichera la dernière entrée du journal avec tous ses détails verbose. Remarquez les champs comme _COMM (nom de la commande), _EXE (chemin de 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 les entrées d'un processus sshd spécifique avec un PID connu (vous pouvez obtenir un PID à partir d'une sortie précédente de journalctl -u sshd.service) :

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 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 du journal, vous devez configurer le service systemd-journald pour le 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 la valeur 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 transférés.

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

Dans 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 (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 sur Y pour confirmer l'enregistrement, et sur Entrée pour confirmer le nom du fichier.

Pour que les modifications prennent effet, vous devez redémarrer le service systemd-journald. Étant donné que cet environnement est un conteneur Docker, systemctl n'est pas disponible. Au lieu de cela, nous allons simuler 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 au 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 du 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 les journaux persistants, le système ne conserve pas toutes les données pour toujours. Le journal dispose d'un mécanisme de rotation des journaux intégré. Vous pouvez configurer les limites de taille et les périodes de conservation dans le fichier /etc/systemd/journald.conf à l'aide de paramètres tels que SystemMaxUse, SystemKeepFree, SystemMaxFileSize et MaxRetentionSec.

Enfin, lorsque les journaux persistants sont activés, la sortie de journalctl inclut les entrées du démarrage actuel du système ainsi que les démarrages précédents du système. 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 du système reconnus :

journalctl --list-boots

Vous verrez une liste des ID de démarrage et leurs plages de temps 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 afficher les entrées du démarrage système actuel uniquement :

journalctl -b

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

journalctl -b -1

Ceci conclut la configuration du stockage persistant du journal.

Maintenir l'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 gestion précise de l'heure est cruciale pour la journalisation, la sécurité et de nombreux services réseau.

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

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 l'heure actuelle de votre système) :

               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 modifier le fuseau horaire du système, vous utilisez l'option set-timezone. Par exemple, modifions le fuseau horaire en 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 en America/Phoenix.

Vous pouvez également définir manuellement l'heure actuelle du système à l'aide de l'option set-time. Le format est "AAAA-MM-JJ hh:mm:ss", mais vous pouvez omettre la date ou l'heure. Définissons l'heure sur 09:00:00 (pour la date actuelle).

sudo timedatectl set-time 09:00:00

Vérifiez le changement d'heure :

timedatectl

Enfin, l'option set-ntp active ou désactive la synchronisation NTP pour le réglage automatique de l'heure. Elle prend true ou false comme argument. Désactivons la synchronisation NTP pendant 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.

2. Comprendre et configurer le service chronyd :

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

Le fichier de configuration pour 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 prend quatre mesures rapidement pour une synchronisation initiale plus précise.

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

Étant donné que 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 approfondie 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 les fichiers journaux traditionnels dans /var/log. Nous avons exploré les principaux fichiers journaux tels que /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 pour accéder aux événements système détaillés. Nous avons ensuite configuré le stockage persistant du journal système pour assurer la conservation des données de journalisation après les redémarrages. Enfin, nous avons abordé la maintenance d'une heure système précise à l'aide de timedatectl et chronyd, en reconnaissant son importance pour des horodatages de journal 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.