One place for hosting & domains

      journaux

      Comment utiliser Journalctl pour consulter et manipuler les journaux Systemd


      Introduction

      L’un des avantages les plus éloquents de systemd est la journalisation des processus et des systèmes. Lorsque vous utilisez d’autres outils, les journaux se retrouvent généralement dispersés dans le système, traités par différents daemons et processus et leur interprétation peut s’avérer difficile lorsqu’ils s’étendent sur plusieurs applications. Systemd tente de résoudre ces problèmes en offrant une solution de gestion centralisée pour la journalisation de tous les processus du noyau et de l’espace utilisateur. Le système qui collecte et gère ces journaux est ce que l’on nomme le journal.

      Le journal est implémenté avec le daemon journald, qui gère tous les messages produits par le noyau, initrd, services, etc. Dans ce guide, nous allons traiter de la façon d’utiliser l’utilitaire journalctl qui peut servir à accéder et manipuler les données contenues dans le journal.

      Concept général

      L’une des principales motivations du journal systemd consiste à centraliser la gestion des journaux, quelle que soit l’origine des messages. Comme une grande partie du processus de démarrage et de gestion des services est traitée par le processus systemd, il est logique de normaliser la méthode de collecte et d’accès aux journaux. Le daemon journald collecte des données de toutes les sources disponibles et les stocke sous un format binaire qui permet une manipulation facile et dynamique.

      Cela nous offre un certain nombre d’avantages importants. En interagissant avec les données à l’aide d’un seul utilitaire, les administrateurs peuvent afficher les données du journal de façon dynamique en fonction de leurs besoins. Vous pouvez tout simplement visualiser les données de démarrage sur les trois derniers démarrages ou combiner les entrées du journal de manière séquentielle à partir de deux services liés pour déboguer un problème de communication.

      Le stockage des données du journal sous un format binaire signifie également que vous pouvez afficher les données sous des formats de sortie arbitraires en fonction de ce dont vous avez besoin à un moment donné. Par exemple, pour assurer une gestion quotidienne des journaux, vous avez peut-être l’habitude de visualiser les journaux sous un format syslog standard, mais si vous décidez ultérieurement de présenter les interruptions de service sous forme de graphique, vous pouvez générer chaque entrée en tant qu’objet JSON pour que votre service de graphique puisse le prendre en charge. Étant donné que les données ne sont pas écrites sur le disque en texte clair, vous n’aurez besoin d’aucune conversion si vous avez besoin d’un format à la demande différent.

      Le journal systemd peut soit être utilisé avec une implémentation syslog existante, soit remplacer la fonctionnalité syslog en fonction de vos besoins. Bien que le journal systemd couvre la plupart des besoins de journalisation de l’administrateur, il peut également venir compléter les mécanismes de journalisation existants. Par exemple, il se peut que vous utilisiez un serveur syslog centralisé pour compiler des données à partir de plusieurs serveurs, mais vous souhaitez peut-être également pouvoir imbriquer les journaux de plusieurs services sur un seul système avec le journal systemd. Vous pouvez faire les deux en combinant ces technologies.

      Configurer l’heure du système

      L’un des avantages de l’utilisation d’un journal binaire pour la journalisation est la possibilité d’afficher les enregistrements de journaux en UTC ou à l’heure locale selon les besoins. Par défaut, systemd affichera les résultats en utilisant l’heure locale.

      Pour cette raison, avant de commencer à travailler sur le journal, nous veillerons à ce que le fuseau horaire soit correctement défini. En fait, la suite systemd est fournie avec un outil nommé timedatectl qui peut vous y aider.

      Tout d’abord, déterminez quels sont les fuseaux horaires disponibles avec l’option list-timezones :

      timedatectl list-timezones
      

      Cela répertoriera les fuseaux horaires disponibles sur votre système. Une fois que vous trouverez celui qui correspond à l’emplacement de votre serveur, vous pouvez le configurer en utilisant l’option set-timezone :

      sudo timedatectl set-timezone zone
      

      Pour vous assurer que votre machine utilise maintenant l’heure qui convient, utilisez la commande timedatectl seule ou avec l’option status. L’affichage sera le même :

      timedatectl status
      
            Local time: Thu 2015-02-05 14:08:06 EST
        Universal time: Thu 2015-02-05 19:08:06 UTC
              RTC time: Thu 2015-02-05 19:08:06
             Time zone: America/New_York (EST, -0500)
           NTP enabled: no
      NTP synchronized: no
       RTC in local TZ: no
            DST active: n/a
      

      La première ligne devrait afficher la bonne heure.

      Visualisation du journal de base

      Pour voir les journaux collectés par le daemon journald, utilisez la commande journalctl.

      Lorsqu’utilisée seule, chaque entrée de journal qui se trouve dans le système s’affichera dans un pager (généralement less) pour que vous puissiez y naviguer. Les entrées les plus anciennes seront les premières :

      journalctl
      
      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
      Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules
      
      . . .
      

      Vous aurez probablement des pages et des pages de données à consulter, ce qui peut représenter des dizaines ou des centaines de milliers de lignes si systemd est installé sur votre système depuis longtemps. Cela montre combien de données sont disponibles dans la base de données du journal.

      Le format sera familier pour ceux qui sont habitués à la journalisation standard des syslog. Cependant, les données collectées proviennent d’un nombre plus important de sources que ne le permettent les implémentations syslog traditionnelles. Cela inclut les journaux des premiers processus de démarrage, le noyau, l’initrd et l’erreur standard d’application. Tous ces éléments sont disponibles dans le journal.

      Vous remarquerez peut-être que toutes les heures affichées sont à l’heure locale. Maintenant que nous notre heure locale est configurée sur notre système, elle est disponible pour chaque entrée du journal. Tous les journaux sont affichés en utilisant cette nouvelle information.

      Si vous souhaitez afficher les heures en UTC, vous pouvez utiliser la balise --utc.

      journalctl --utc
      

      Filtrage des journaux par heure

      Même s’il est très pratique d’avoir accès à une série aussi grande de données, il peut s’avérer difficile, voire impossible, d’inspecter et de traiter mentalement une telle quantité de données. Par conséquent, ses options de filtrage font partie des fonctionnalités les plus importantes de journalctl.

      Affichage des journaux du démarrage en cours

      L’option la plus basique que vous utiliserez éventuellement quotidiennement est la balise -b. Elle affichera toutes les entrées qui ont été recueillies depuis le dernier démarrage.

      journalctl -b
      

      Vous pourrez ainsi identifier et gérer plus facilement les informations qui correspondent à votre environnement actuel.

      Dans les cas où vous n’utilisez pas cette fonctionnalité et affichez plusieurs jours de démarrages, vous verrez que journalctl a inséré une ligne qui ressemble à ce qui suit à chaque défaillance du système :

      . . .
      
      -- Reboot --
      
      . . .
      

      Vous pouvez utiliser cela pour vous aider à séparer logiquement les informations en sessions de démarrage.

      Démarrages précédents

      Bien que, de manière générale, vous souhaitez afficher les informations du démarrage en cours, il arrivera parfois que les démarrages passés vous soient également utiles. Le journal peut enregistrer des informations de nombreux démarrages précédents, de sorte que journalctl puisse être créé pour afficher les informations facilement.

      Certaines distributions permettent de sauvegarder les informations des démarrages précédents par défaut, d’autres désactivent cette fonctionnalité. Pour activer les informations de démarrage persistantes, vous pouvez soit créer le répertoire pour stocker le journal en saisissant ce qui suit :

      • sudo mkdir -p /var/log/journal

      Ou vous pouvez modifier le fichier de configuration du journal :

      • sudo nano /etc/systemd/journald.conf

      Sous la section [Journal], configurez l’option Storage= sur « persistent » pour activer la journalisation persistante :

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Lorsque la sauvegarde des démarrages précédents est activée sur votre serveur, journalctl intègre quelques commandes pour vous aider à travailler avec des démarrages comme unité de division. Pour voir les démarrages dont journald a connaissance, utilisez l’option --list-boots avec journalctl :

      journalctl --list-boots
      
      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
      -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
       0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
      

      Vous verrez s’afficher une ligne pour chaque démarrage. La première colonne représente la valeur offset du démarrage que vous pouvez utiliser pour facilement référencer le démarrage avec journalctl. Si vous avez besoin d’une référence absolue, l’ID de démarrage se trouve dans la deuxième colonne. Vous pouvez déterminer l’heure à laquelle la session de démarrage renvoie en utilisant les deux spécifications chronologiques listées vers la fin.

      Pour afficher les informations de ces démarrages, vous pouvez utiliser des informations provenant de la première ou de la deuxième colonne.

      Par exemple, pour consulter le journal du démarrage précédent, utilisez le pointeur relatif -1 avec la balise -b :

      journalctl -b -1
      

      Vous pouvez également utiliser l’ID de démarrage pour rappeler les données d’un démarrage :

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Fenêtres d’heures

      Bien que la consultation des entrées du journal par démarrage soit très utile, il se peut que vous souhaitiez demander des fenêtres d’heures qui ne s’alignent pas correctement sur les démarrages du système. Cela peut être particulièrement pratique lorsque vous travaillez avec des serveurs de longue durée avec un temps de disponibilité significatif.

      Vous pouvez filtrer par des périodes de temps arbitraires en utilisant les options --since et --until, qui limitent respectivement les entrées affichées à celles qui suivent ou précèdent l’heure donnée.

      Les valeurs de l’heure peuvent se présenter sous différents formats. Pour les valeurs de temps absolus, vous devez utiliser le format suivant :

      YYYY-MM-DD HH:MM:SS
      

      Par exemple, nous pouvons voir toutes les entrées depuis le 10 janvier 2015 à 17 h 15 en saisissant ce qui suit :

      journalctl --since "2015-01-10 17:15:00"
      

      Si les composants du format ci-dessus sont supprimés, certaines valeurs par défaut seront appliquées. Par exemple, si la date est omise, le système supposera qu’il s’agit de la date du jour. Si le composant de l’heure est manquant, « 00:00 » (minuit) sera remplacé. Le champ des secondes peut également être laissé à la valeur par défaut de « 00 » :

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"
      

      Le journal comprend également certaines valeurs relatives, nommées raccourcis. Par exemple, vous pouvez utiliser les mots « yesterday », « today », « tomorrow » ou « now ». Vous pouvez indiquer des heures relatives en préfixant la valeur numérotée de « – » ou « + » ou en utilisant des mots comme « ago » dans une construction de phrases.

      Pour obtenir les données de la veille, vous pourriez taper :

      journalctl --since yesterday
      

      Si vous recevez des rapports indiquant une interruption de service qui commence à 9 h 00 et s’est achevée il y a une heure, vous pourriez taper :

      journalctl --since 09:00 --until "1 hour ago"
      

      Comme vous pouvez le voir, il est relativement facile de définir des fenêtres flexibles de temps pour filtrer les entrées que vous souhaitez voir.

      Filtrer par intérêt des messages

      Nous avons précédemment appris certaines des façons qui vous permettent de filtrer les données du journal en utilisant des contraintes de temps. Au cours de cette section, nous allons discuter de la façon de filtrer vos données en fonction du service ou du composant qui vous intéresse. Le journal systemd intègre différents moyens de le faire.

      Par unité

      La façon probablement la plus pratique de filtrer vos données est de le faire par l’unité qui vous intéresse. Nous pouvons utiliser l’option -u pour filtrer nos données de cette façon.

      Par exemple, pour consulter tous les journaux d’une unité Nginx sur notre système, nous pouvons taper :

      journalctl -u nginx.service
      

      Généralement, vous voudrez probablement filtrer vos données par heure afin d’afficher les lignes qui vous intéressent. Par exemple, pour vérifier comment le service fonctionne aujourd’hui, vous pouvez taper :

      journalctl -u nginx.service --since today
      

      Ce type de concentration peut s’avérer extrêmement utile si vous souhaiter profiter de la capacité du journal à imbriquer les enregistrements de différentes unités. Par exemple, si votre processus Nginx est connecté à une unité PHP-FPM pour traiter le contenu dynamique, vous pouvez fusionner les entrées des deux par ordre chronologique en spécifiant les deux unités :

      journalctl -u nginx.service -u php-fpm.service --since today
      

      Cela peut grandement faciliter la détection des interactions entre les différents programmes et les systèmes de débogages au lieu de processus individuels.

      Par processus, utilisateur ou ID de groupe

      Afin de fonctionner correctement, certains services génèrent tout un panel de processus enfants. Si vous avez mis en évidence le PID exact du processus qui vous intéresse, vous pouvez également filtrer vos données par cette valeur.

      Pour ce faire, nous pouvons appliquer notre filtre en renseignant le champ _PID. Par exemple, si le PID qui nous intéresse est 8088, nous pourrions taper :

      journalctl _PID=8088
      

      À d’autres moments, vous voudrez afficher toutes les entrées enregistrées par un utilisateur ou un groupe spécifique. Vous pouvez le faire avec les filtres _UID ou _GID. Par exemple, si votre serveur web fonctionne sous l’utilisateur www-data, vous pouvez trouver l’ID de l’utilisateur en tapant ce qui suit :

      id -u www-data
      
      33
      

      Ensuite, vous pouvez utiliser l’ID qui a été renvoyé pour filtrer les résultats du journal :

      journalctl _UID=33 --since today
      

      Le journal systemd intègre de nombreux champs qui peuvent être utilisés pour le filtrage. Certaines d’entre eux sont passés à partir du processus en cours d’enregistrement et d’autres appliqués par journald en utilisant les informations qu’il recueille à partir du système au moment de la journalisation.

      Le résultat principal indique que le champ _PID est de ce dernier type. Le journal enregistre et indexe automatiquement le PID du processus en cours de journalisation qui permet un filtrage ultérieur. Pour en savoir plus sur tous les champs disponibles des journaux, saisissez :

      man systemd.journal-fields
      

      Nous allons traiter de certains de ces éléments dans ce guide. Cependant, pour le moment, nous allons étudier une option plus utile liée au filtrage de ces champs. Vous pouvez utiliser l’option -F pour afficher toutes les valeurs disponibles pour un champ donné du journal.

      Par exemple, pour consulter pour quels groupes d’ID le journal systemd dispose d’entrées, vous pouvez saisir :

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Cela affichera toutes les valeurs que le journal a stockées pour le champ de l’ID du groupe. Cela peut vous aider à construire vos filtres.

      Par chemin de composants

      Nous pouvons également filtrer nos données en renseignant un emplacement de chemin.

      Si le chemin mène à un exécutable, journalctl affichera toutes les entrées qui impliquent l’exécutable en question. Par exemple, pour trouver les entrées qui impliquent l’exécutable bash, vous pouvez taper :

      journalctl /usr/bin/bash
      

      Généralement, si une unité est disponible pour l’exécutable, cette méthode est plus propre et donne de meilleures informations (entrées des processus enfants associés, etc). Cependant, il arrivera parfois que cela ne soit pas possible.

      Afficher les messages du noyau

      Les messages du noyau, ceux qui se trouvent généralement dans la sortie dmesg peuvent également être récupérés dans le journal.

      Pour afficher uniquement ces messages, nous pouvons ajouter les balises -k ou --dmesg à notre commande :

      journalctl -k
      

      Par défaut, cela affichera les messages du noyau du démarrage actuel. Vous pouvez spécifier un démarrage alternatif en utilisant les balises usuelles de sélection de démarrage dont nous avons précédemment parlé. Par exemple, pour obtenir les messages des cinq derniers démarrages, vous pourriez taper :

      journalctl -k -b -5
      

      Par priorité

      L’un des filtres auxquels s’intéressent souvent les administrateurs de système est la priorité des messages. Bien qu’il soit souvent utile de consigner les informations à un niveau très verbeux, pour digérer les informations disponibles, les journaux de faible priorité peuvent être déroutants et confus.

      Vous pouvez utiliser journalctl pour afficher uniquement les messages d’une priorité spécifiée ou au-dessus en utilisant l’option -p. Cela vous permet de filtrer les messages de priorité inférieure.

      Par exemple, pour afficher uniquement les entrées enregistrées au niveau des erreurs ou au-dessus, vous pouvez taper :

      journalctl -p err -b
      

      Cela vous montrera tous les messages indiquant une erreur, un état critique, un avertissement ou une urgence. Le journal implémente les niveaux de messages syslog standard. Vous pouvez utiliser soit le nom de la priorité, soit la valeur numérique correspondante. En partant de la plus haute à la plus basse, les priorités sont les suivantes :

      • 0 : emerg
      • 1 : alert
      • 2 : crit
      • 3 : err
      • 4 : warning
      • 5 : notice
      • 6 : info
      • 7 : debug

      Vous pouvez utiliser les numéros ou noms ci-dessus de manière interchangeable avec l’option -p. En sélectionnant une priorité, vous afficherez les messages marqués au niveau indiqué et aux niveaux supérieurs.

      Modification de l’affichage du journal

      Précédemment, nous vous avons montré comment utiliser le filtrage pour sélectionner des données. Il existe cependant d’autres façons de modifier la sortie. Nous pouvons ajuster l’affichage journalctl en fonction de divers besoins.

      Tronquer ou étendre le résultat

      Nous pouvons ajuster la façon dont journalctl affiche les données en l’instruisant de réduire ou d’étendre la sortie.

      Par défaut, journalctl affichera l’intégralité du résultat dans un pager, ce qui permet aux entrées de se diriger vers la droite de l’écran. Pour accéder à cette information, appuyez sur la touche de flèche droite.

      Si vous souhaitez tronquer le résultat, en insérant une ellipse à l’endroit où les informations ont été supprimées, vous pouvez utiliser l’option --no-full :

      journalctl --no-full
      
      . . .
      
      Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
      Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
      Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
      

      Vous pouvez également aller dans la direction inverse et demander à journalctl d’afficher toutes les informations dont il dispose, qu’il inclut des caractères non imprimables ou pas. Nous pouvons le faire avec la balise -a :

      journalctl -a
      

      Sortie sur Standard

      Par défaut, journalctl affiche la sortie dans un pager pour faciliter la consommation des données. Cependant, si vous prévoyez de traiter les données avec des outils de manipulation de texte, vous voudrez probablement pouvoir produire une sortie standard sur la sortie.

      Vous pouvez le faire avec l’option --no-pager :

      journalctl --no-pager
      

      Vous pouvez immédiatement acheminer votre résultat dans un utilitaire de traitement ou le rediriger vers un fichier sur le disque, en fonction de vos besoins.

      Formats de sortie

      Si vous traitez des entrées de journaux, comme mentionné ci-dessus, il vous sera probablement plus facile d’analyser les données si elles sont dans format plus digeste. Heureusement, le journal peut s’afficher sous divers formats selon les besoins. Vous pouvez le faire en utilisant l’option -o et un spécificateur de format.

      Par exemple, vous pouvez générer les entrées du journal dans JSON en tapant :

      journalctl -b -u nginx -o json
      
      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
      
      . . .
      

      Très utile pour l’analyse avec les utilitaires. Vous pourriez utiliser le format json-pretty pour obtenir une meilleure maîtrise sur la structure des données avant de les passer au consommateur JSON :

      journalctl -b -u nginx -o json-pretty
      
      {
          "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
          "__REALTIME_TIMESTAMP" : "1422990364739502",
          "__MONOTONIC_TIMESTAMP" : "27200938",
          "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
          "PRIORITY" : "6",
          "_UID" : "0",
          "_GID" : "0",
          "_CAP_EFFECTIVE" : "3fffffffff",
          "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
          "_HOSTNAME" : "desktop",
          "SYSLOG_FACILITY" : "3",
          "CODE_FILE" : "src/core/unit.c",
          "CODE_LINE" : "1402",
          "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
          "SYSLOG_IDENTIFIER" : "systemd",
          "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
          "_TRANSPORT" : "journal",
          "_PID" : "1",
          "_COMM" : "systemd",
          "_EXE" : "/usr/lib/systemd/systemd",
          "_CMDLINE" : "/usr/lib/systemd/systemd",
          "_SYSTEMD_CGROUP" : "/",
          "UNIT" : "nginx.service",
          "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
          "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
      }
      
      . . .
      

      Les formats d’affichage disponibles sont les suivants :

      • cat : affiche uniquement le champ du message en lui-même.
      • export : un format binaire adapté au transfert ou à la sauvegarde de données.
      • json : JSON standard avec une entrée par ligne.
      • json-pretty : JSON formaté pour une meilleure lisibilité par l’homme
      • json-sse : résultat formaté sous JSON enveloppé pour que l’événement add server-sen soit compatible
      • short : la sortie de style syslog par défaut
      • short-iso :le format par défaut a été augmenté pour afficher les horodatages d’horloge murale ISO 8601
      • short-monotonic : le format par défaut avec des horodatages monotones.
      • short-precise : le format par défaut avec précision à la microseconde près
      • verbose : affiche chaque champ de journal disponible pour l’entrée, y compris ceux généralement cachés en interne.

      Ces options vous permettent d’afficher les entrées du journal dans le format le plus adapté à vos besoins actuels.

      Surveillance active des processus

      La commande journalctl imite le nombre d’administrateurs qui utilisent tail pour la surveillance d’une activité active ou récente. Cette fonctionnalité est intégrée dans journalctl et vous permet d’accéder à ces fonctionnalités sans avoir à vous diriger vers un autre outil.

      Affichage des journaux récents

      Pour afficher une quantité d’enregistrements définie, vous pouvez utiliser l’option -n, qui fonctionne exactement comme tail -n.

      Par défaut, les 10 entrées les plus récentes s’afficheront :

      journalctl -n
      

      Vous pouvez spécifier le nombre d’entrées que vous souhaitez consulter en ajoutant un numéro après le -n :

      journalctl -n 20
      

      Suivi des journaux

      Pour suivre activement les journaux à mesure de leur écriture, vous pouvez utiliser la balise -f. Encore une fois, cela fonctionne comme vous pouvez vous y attendre si vous déjà utilisé tail -f:

      journalctl -f
      

      Maintenance des journaux

      Vous devez éventuellement vous demander combien coûte le stockage de toutes ces données que nous avons vues jusqu’à présent. En outre, vous pourriez vouloir nettoyer certains journaux anciens et libérer de l’espace.

      Trouver l’utilisation actuelle du disque

      Vous pouvez trouver la quantité d’espace que le journal occupe actuellement sur le disque en utilisant la balise --disk-usage :

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Suppression des anciens journaux

      Si vous souhaitez réduire votre journal, vous disposez de deux façons différentes de le faire (disponibles avec les versions 218 et ultérieures de systemd).

      Si vous utilisez l’option --vacuum-size, vous pouvez réduire votre journal en indiquant une taille. Les anciennes entrées seront supprimées jusqu’à que l’espace de journal total occupé sur le disque atteigne la taille demandée :

      sudo journalctl --vacuum-size=1G
      

      Il existe une autre façon de réduire le journal, qui consiste à fournir une heure de calcul avec l’option --vacuum-time. Le système supprime toutes les entrées au-delà de cette heure. Vous pourrez ainsi conserver les entrées qui ont été créées après une heure spécifique.

      Par exemple, pour conserver les entrées de l’année dernière, vous pouvez taper :

      sudo journalctl --vacuum-time=1years
      

      Limitation de l’expansion du journal

      Vous pouvez configurer votre serveur de manière à ce qu’il place des limites sur la quantité d’espace que le journal peut prendre. Pour cela, vous devez éditer le fichier /etc/systemd/journald.conf.

      Vous pouvez utiliser les éléments suivants pour limiter l’expansion du journal :

      • SystemMaxUse= : Spécifie l’espace disque maximal qui peut être utilisé par le journal dans un stockage persistant.
      • SystemKeepFree= : Spécifie la quantité d’espace libre que le journal doit laisser lors de l’ajout d’entrées du journal au stockage persistant.
      • SystemMaxFileSize= : contrôle la taille que les fichiers journaux individuels peuvent atteindre dans le stockage persistant avant la rotation.
      • RuntimeMaxUse= : Spécifie l’espace disque maximal qui peut être utilisé dans le stockage volatile (dans le système de fichiers /run).
      • RuntimeKeepFree= : Spécifie la quantité d’espace à mettre de côté pour d’autres utilisations lors de l’écriture des données sur un stockage volatile (dans le système de fichiers /run).
      • RuntimeMaxFileSize= : Spécifie la quantité d’espace qu’un fichier de journal individuel peut prendre en charge dans un stockage volatile (dans le système de fichiers /run) avant la rotation.

      En configurant ces valeurs, vous pouvez contrôler la façon dont journald consomme et conserve l’espace sur votre serveur. Gardez à l’esprit que SystemMaxFileSize et RuntimeMaxFileSize cibleront les fichiers archivés pour atteindre les limites indiquées. Ceci est important à retenir lors de l’interprétation du nombre de fichiers après une opération de nettoyage.

      Conclusion

      Comme vous pouvez le voir, le journal systemd est très utile pour collecter et gérer les données de votre système et de l’application. Une grande partie de la flexibilité provient des métadonnées complètes automatiquement enregistrées et de la nature centralisée du journal. La commande journalctl permet de profiter des fonctionnalités avancées du journal et de faire une analyse et un débogage relationnel des différents composants de l’application.



      Source link

      Comment centraliser les journaux avec Journald sur Ubuntu 20.04


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Les journaux système sont un élément extrêmement important de la gestion des systèmes Linux. Ils fournissent un aperçu inestimable du fonctionnement des systèmes et de leur utilisation car, en plus des erreurs, ils enregistrent des informations opérationnelles telles que les événements de sécurité. La configuration standard des systèmes Linux consiste à stocker leurs journaux localement sur le même système que celui où ils ont été créés. Cela fonctionne pour les systèmes autonomes, mais devient rapidement un problème lorsque le nombre de systèmes augmente. La solution pour gérer tous ces journaux est de créer un serveur de journalisation centralisé où chaque hôte Linux envoie ses journaux, en temps réel, à un serveur de gestion de journaux dédié.

      Une solution de journalisation centralisée offre plusieurs avantages par rapport au stockage des journaux sur chaque hôte :

      • Cela réduit la quantité d’espace disque nécessaire sur chaque hôte pour stocker les fichiers journaux.
      • Les journaux peuvent être conservés plus longtemps, car le serveur de journaux dédié peut être configuré avec une plus grande capacité de stockage.
      • Il est possible d’effectuer une analyse avancée des journaux qui nécessite des journaux provenant de plusieurs systèmes et également plus de ressources de calcul que celles qui peuvent être disponibles sur les hôtes.
      • Les administrateurs de systèmes peuvent accéder aux journaux de tous leurs systèmes auxquels ils ne peuvent pas se connecter directement pour des raisons de sécurité.

      Dans ce guide, vous allez configurer un composant de la suite d’outils systemd pour relayer les messages de journal des systèmes clients vers un serveur de collecte de journaux centralisé. Vous allez configurer le serveur et le client pour qu’ils utilisent des certificats TLS afin de crypter les messages du journal lorsqu’ils sont transmis sur des réseaux non sécurisés tels qu’Internet, et également pour qu’ils s’authentifient mutuellement.

      Conditions préalables

      Avant de commencer ce guide, vous aurez besoin des éléments suivants :

      • Deux serveurs Ubuntu 20.04.
      • Un utilisateur non root avec des privilèges sudo sur les deux serveurs.  Suivez le guide Configuration initiale du serveur avec Ubuntu 20.04 pour savoir comment procéder. Vous devez également configurer le pare-feu UFW sur les deux serveurs comme expliqué dans le guide.
      • Deux noms d’hôtes qui pointent vers vos serveurs. Un nom d’hôte pour le système client qui génère les journaux et un autre pour le serveur de collecte des journaux. Apprenez comment faire pointer les noms d’hôtes vers DigitalOcean Droplets en consultant la documentation Domaines et DNS.

      Ce guide utilisera les deux exemples de noms d’hôtes suivants :

      • client.your_domain : Le système client qui génère les journaux.
      • server.your_domain : Le serveur de collecte des journaux.

      Connectez-vous au client et au serveur dans des terminaux séparés via SSH en tant qu’utilisateur non root sudo pour commencer ce tutoriel.

      Note : tout au long du tutoriel, les blocs de commande sont étiquetés avec le nom du serveur (client ou server) sur lequel la commande doit être exécutée.

      Étape 1 — Installation de systemd-journal-remote

      Au cours de cette étape, vous installerez le paquet systemd-journal-remote sur le client et le serveur. Ce paquet contient les composants que le client et le serveur utilisent pour relayer les messages du journal.

      Tout d’abord, sur le client et le serveur, lancez une mise à jour du système pour vous assurer que la base de données de paquets et le système sont à jour :

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      Ensuite, installez le paquet systemd-journal-remote :

      Client and Server

      • sudo apt install systemd-journal-remote

      Sur le serveur, activez et lancez les deux composants systemd dont il a besoin pour recevoir les messages de journal avec la commande suivante :

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      L’option --now de la première commande permet de démarrer les services immédiatement. Vous ne l’avez pas utilisé dans la deuxième commande, car ce service ne démarrera pas tant qu’il ne disposera pas de certificats TLS, que vous créerez à l’étape suivante.

      Sur le client, activez le composant que systemd utilise pour envoyer les messages de journal au serveur :

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Ensuite, sur le serveur, ouvrez les ports 19532 et 80 dans le pare-feu UFW. Cela permettra au serveur de recevoir les messages de journal du client. Le port 80 est le port que certbot utilisera pour générer le certificat TLS. Les commandes suivantes permettent d’ouvrir ces ports :

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      Sur le client, il suffit d’ouvrir le port 80 avec cette commande :

      Client

      Vous avez maintenant installé les composants nécessaires et terminé la configuration du système de base sur le client et le serveur. Avant de pouvoir configurer ces composants pour commencer à relayer les messages du journal, vous devez enregistrer les certificats Let’s Encrypt TLS pour le client et le serveur à l’aide de l’utilitaire certbot.

      Étape 2 — Installation de Certbot et enregistrement de certificats

      Let’s Encrypt est une autorité de certification qui délivre des certificats TLS gratuits. Ces certificats permettent aux ordinateurs à la fois de crypter les données qu’ils s’envoient entre eux et de vérifier l’identité de chacun. Ce sont ces certificats qui vous permettent de sécuriser votre navigation sur Internet avec HTTPS. Les mêmes certificats peuvent être utilisés par toute autre application qui souhaite le même niveau de sécurité. La procédure d’enregistrement du certificat est la même, quelle que soit l’utilisation que vous en ferez.

      Au cours de cette étape, vous installerez l’utilitaire certbot et l’utiliserez pour enregistrer les certificats. Il se chargera également de renouveler automatiquement les certificats lorsqu’ils arriveront à expiration. La procédure d’enregistrement est ici la même sur le client et sur le serveur. Il vous suffit de changer le nom d’hôte pour qu’il corresponde à celui de l’hôte sur lequel vous exécutez la commande d’enregistrement.

      Tout d’abord, activez le référentiel universe d’Ubuntu car l’utilitaire certbot réside dans le référentiel universe. Si vous avez déjà activé le dépôt universe, l’exécution de ces commandes ne fera rien à votre système et vous pourrez les exécuter en toute sécurité :

      Client and Server

      • sudo apt install software-properties-common
      • sudo add-apt-repository universe
      • sudo apt update

      Ensuite, installez certbot sur les deux hôtes :

      Client and Server

      Maintenant que vous avez installé certbot, exécutez la commande suivante pour enregistrer les certificats sur le client et le serveur :

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Les options de cette commande signifient ce qui suit :

      • certonly : enregistrer le certificat et ne faire aucune autre modification dans le système.
      • --standalone : utiliser le serveur web intégré de certbot pour vérifier la demande de certificat.
      • --agree-tos : accepter automatiquement les conditions d’utilisation du service Let’s Encrypt.
      • --email your_email : il s’agit de l’adresse électronique que Let’s Encrypt utilisera pour vous informer de l’expiration du certificat et d’autres informations importantes.
      • -d your_domain : le nom d’hôte pour lequel le certificat sera enregistré. Il doit correspondre au système dans lequel vous l’exécutez.

      Lorsque vous exécutez cette commande, il vous sera demandé si vous souhaitez partager l’adresse électronique avec Let’s Encrypt afin qu’ils puissent vous envoyer des bulletins d’actualités et d’autres informations sur leur travail. Cette opération est facultative. Si vous ne communiquez pas votre adresse électronique, l’enregistrement du certificat se déroulera quand même normalement.

      Lorsque le processus d’enregistrement du certificat sera terminé, il placera le certificat et les fichiers clés dans /etc/letsencrypt/live/your_domain/your_domain est le nom d’hôte pour lequel vous avez enregistré le certificat.

      Enfin, vous devez télécharger une copie de l’AC de Let’s Encrypt et des certificats intermédiaires, puis les placer dans le même fichier. journald utilisera ce fichier pour vérifier l’authenticité des certificats sur le client et le serveur lorsqu’ils communiquent entre eux.

      La commande suivante permet de télécharger les deux certificats sur le site web Let’s Encrypt et de les placer dans un seul fichier appelé letsencrypt-combined-certs.pem dans le répertoire personnel de votre utilisateur.

      Exécutez cette commande sur le client et le serveur pour télécharger les certificats et créer le fichier combiné :

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Ensuite, déplacez ce fichier dans le répertoire Let’s Encrypt contenant les certificats et les clés :

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Vous avez maintenant enregistré les certificats et les clés. Dans l’étape suivante, vous configurerez le serveur de collecte de journaux pour qu’il commence à écouter et à stocker les messages des journaux du client.

      Étape 3 — Configuration du serveur

      Au cours de cette étape, vous configurerez le serveur pour qu’il utilise les fichiers de certificats et de clés que vous avez générés à la dernière étape afin qu’il puisse commencer à accepter les messages de journal du client.

      systemd-journal-remote est le composant qui écoute les messages de journal. Ouvrez son fichier de configuration à l’adresse /etc/systemd/journal-remote.conf avec un éditeur de texte pour commencer à le configurer sur le serveur :

      • sudo nano /etc/systemd/journal-remote.conf

      Ensuite, décommentez toutes les lignes sous la section [Remote] et définissez les chemins d’accès aux fichiers TLS que vous venez de créer :

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Voici les options que vous avez utilisées ici :

      • Seal=false : signer les données du journal dans le journal. Activez cette option si vous avez besoin d’une sécurité maximale ; sinon, vous pouvez la laisser comme false.
      • SplitMode=host : les journaux des clients distants seront répartis par hôte dans /var/log/journal/remote. Si vous préférez que tous les journaux soient ajoutés dans un seul fichier, réglez celui-ci sur SplitMode=false.
      • ServerKeyFile : le fichier de clé privée du serveur.
      • ServerCertificateFile: le fichier de certificat du serveur.
      • TrustedCertificateFile: le fichier contenant les certificats AC Let’s Encrypt.

      Maintenant, vous devez modifier les autorisations sur les répertoires de Let’s Encrypt qui contiennent les certificats et la clé afin que le systemd-journal-remote puisse les lire et les utiliser.

      Tout d’abord, modifiez les autorisations afin que le certificat et la clé privée soient lisibles :

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ensuite, changez la propriété du groupe de la clé privée pour celle du groupe de systemd-journal-remote :

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Vous pouvez maintenant lancer systemd-journal-remote :

      • sudo systemctl start systemd-journal-remote.service

      Votre serveur de collecte de journaux est maintenant en cours d’exécution et prêt à commencer à accepter les messages de journaux d’un client. Dans l’étape suivante, vous configurerez le client pour qu’il transmette les journaux à votre serveur de collecte.

      Étape 4 — Configuration du client

      Au cours de cette étape, vous configurerez le composant qui relaie les messages du journal au serveur de collecte des journaux. Ce composant s’appelle systemd-journal-upload.

      La configuration par défaut de systemd-journal-upload fait qu’il a recours à un utilisateur temporaire qui n’existe que pendant le déroulement du processus. Il est donc plus compliqué d’autoriser systemd-journal-upload à lire les certificats et les clés TLS. Pour résoudre ce problème, vous créerez un nouvel utilisateur système portant le même nom que l’utilisateur temporaire qui sera utilisé à sa place.

      Tout d’abord, créez le nouvel utilisateur appelé systemd-journal-upload sur le client avec la commande adduser suivante :

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Ces options de commande sont :

      • --system : créer le nouvel utilisateur en tant qu’utilisateur système. Elle donne à l’utilisateur un numéro UID (User Identifier) inférieur à 1000. Les UID de plus de 1 000 sont généralement attribués à des comptes utilisateurs avec lesquels un humain se connectera.
      • --home /run/systemd : définir /run/systemd comme le répertoire d’origine de cet utilisateur.
      • --no-create-home : ne pas créer le répertoire d’origine, car il existe déjà.
      • --disabled-login : l’utilisateur ne peut pas se connecter au serveur (via SSH, par exemple).
      • --group : créer un groupe portant le même nom que l’utilisateur.

      Ensuite, définissez les autorisations et la propriété des fichiers de certificat Let’s Encrypt :

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Maintenant, modifiez la configuration pour systemd-journal-upload, qui se trouve dans /etc/systemd/journal-upload.conf. Ouvrez ce fichier avec un éditeur de texte :

      • sudo nano /etc/systemd/journal-upload.conf

      Modifiez ce fichier de manière à ce qu’il ressemble à ce qui suit :

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Enfin, redémarrez le service systemd-journal-upload afin qu’il utilise la nouvelle configuration :

      • sudo systemctl restart systemd-journal-upload.service

      Votre client est maintenant configuré, en cours d’exécution et envoie ses messages au serveur de collecte de journaux. Dans l’étape suivante, vous vérifierez que les journaux sont correctement envoyés et enregistrés.

      Étape 5 — Test du client et du serveur

      Au cours de cette étape, vous vérifierez que le client relaie les messages de journaux au serveur et que le serveur les stocke correctement.

      Le serveur de collecte des journaux stocke les journaux des clients dans le répertoire /var/log/journal/remote/. Lorsque vous avez redémarré le client à la fin de la dernière étape, il a commencé à envoyer des messages de journaux ; il y a donc maintenant un fichier journal dans /var/log/journal/remote/. Le fichier sera nommé d’après le nom d’hôte que vous avez utilisé pour le certificat TLS.

      Utilisez la commande ls pour vérifier que le fichier journal du client est présent sur le serveur :

      Server

      • sudo ls -la /var/log/journal/remote/

      Cela permet d’imprimer le contenu du répertoire contenant le fichier journal :

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      Ensuite, écrivez un message de journal sur le client pour vérifier que le serveur reçoit les messages du client comme prévu. Vous utiliserez l’utilitaire logger pour créer un message de journal personnalisé sur le client. Si tout fonctionne correctement, systemd-journal-upload transmettra ce message au serveur.

      Sur le client, exécutez la commande logger suivante :

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      Le -p syslog.debug de cette commande définit la facilité et la gravité du message. Si vous réglez ce paramètre sur syslog.debug, vous verrez qu’il s’agit d’un message de test. Cette commande enregistre le message ### TEST MESSAGE from client.your_domain ### dans le journal du client, que systemd-journal-upload transfère au serveur.

      Ensuite, lisez le fichier journal du client sur le serveur pour vérifier que les messages du journaux arrivent bien en provenance du client. Ce fichier est un fichier journal binaire, vous ne pourrez donc pas le lire avec des outils comme less. Lisez plutôt le fichier en utilisant journalctl avec l’option --file= qui vous permet de spécifier un fichier journal personnalisé :

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      Le message du journal apparaîtra comme suit :

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Votre serveur de centralisation des journaux recueille maintenant avec succès les journaux de votre système client.

      Conclusion

      Dans cet article, vous avez mis en place un serveur central de collecte de journaux et configuré un client pour qu’il transmette une copie de ses journaux système au serveur. Vous pouvez configurer autant de clients que nécessaire pour relayer les messages au serveur de collecte de journaux en exécutant les étapes de configuration des clients que vous avez réalisées ici.



      Source link

      Comment centraliser les journaux avec Journald sur Debian 10


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Les journaux système sont un élément extrêmement important de la gestion des systèmes Linux. Ils fournissent un aperçu inestimable du fonctionnement des systèmes et de leur utilisation car, en plus des erreurs, ils enregistrent des informations opérationnelles telles que les événements de sécurité. La configuration standard des systèmes Linux consiste à stocker leurs journaux localement sur le même système que celui où ils ont été créés. Cela fonctionne pour les systèmes autonomes, mais devient rapidement un problème lorsque le nombre de systèmes augmente. La solution pour gérer tous ces journaux est de créer un serveur de journalisation centralisé où chaque hôte Linux envoie ses journaux, en temps réel, à un serveur de gestion de journaux dédié.

      Une solution de journalisation centralisée offre plusieurs avantages par rapport au stockage des journaux sur chaque hôte :

      • Cela réduit la quantité d’espace disque nécessaire sur chaque hôte pour stocker les fichiers journaux.
      • Les journaux peuvent être conservés plus longtemps, car le serveur de journaux dédié peut être configuré avec une plus grande capacité de stockage.
      • Il est possible d’effectuer une analyse avancée des journaux qui nécessite des journaux provenant de plusieurs systèmes et également plus de ressources de calcul que celles qui peuvent être disponibles sur les hôtes.
      • Les administrateurs de systèmes peuvent accéder aux journaux de tous leurs systèmes auxquels ils ne peuvent pas se connecter directement pour des raisons de sécurité.

      Dans ce guide, vous allez configurer un composant de la suite d’outils systemd pour relayer les messages de journal des systèmes clients vers un serveur de collecte de journaux centralisé. Vous allez configurer le serveur et le client pour qu’ils utilisent des certificats TLS afin de crypter les messages du journal lorsqu’ils sont transmis sur des réseaux non sécurisés tels qu’Internet, et également pour qu’ils s’authentifient mutuellement.

      Conditions préalables

      Avant de commencer ce guide, vous aurez besoin des éléments suivants :

      • Deux serveurs Debian 10.
      • Un utilisateur non root avec des privilèges sudo sur les deux serveurs.  Suivez le guide Configuration initiale du serveur avec Debian 10 pour savoir comment procéder. Vous devez également configurer le pare-feu UFW sur les deux serveurs comme expliqué dans le guide.
      • Deux noms d’hôtes qui pointent vers vos serveurs. Un nom d’hôte pour le système client qui génère les journaux et un autre pour le serveur de collecte des journaux. Apprenez comment faire pointer les noms d’hôtes vers DigitalOcean Droplets en consultant la documentation Domaines et DNS.

      Ce guide utilisera les deux exemples de noms d’hôtes suivants :

      • client.your_domain : Le système client qui génère les journaux.
      • server.your_domain : Le serveur de collecte des journaux.

      Connectez-vous au client et au serveur dans des terminaux séparés via SSH en tant qu’utilisateur non root sudo pour commencer ce tutoriel.

      Note : tout au long du tutoriel, les blocs de commande sont étiquetés avec le nom du serveur (client ou serveur) sur lequel la commande doit être exécutée.

      Étape 1 — Installation de systemd-journal-remote

      Au cours de cette étape, vous installerez le paquet systemd-journal-remote sur le client et le serveur. Ce paquet contient les composants que le client et le serveur utilisent pour relayer les messages du journal.

      Tout d’abord, sur le client et le serveur, lancez une mise à jour du système pour vous assurer que la base de données de paquets et le système sont à jour :

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      Ensuite, installez le paquet systemd-journal-remote :

      Client and Server

      • sudo apt install systemd-journal-remote

      Sur le serveur, activez et lancez les deux composants systemd dont il a besoin pour recevoir les messages de journal avec la commande suivante :

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      L’option --now de la première commande permet de démarrer les services immédiatement. Vous ne l’avez pas utilisé dans la deuxième commande, car ce service ne démarrera pas tant qu’il ne disposera pas de certificats TLS, que vous créerez à l’étape suivante.

      Sur le client, activez le composant que systemd utilise pour envoyer les messages de journal au serveur :

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Ensuite, sur le serveur, ouvrez les ports 19532 et 80 dans le pare-feu UFW. Cela permettra au serveur de recevoir les messages de journal du client. Le port 80 est le port que certbot utilisera pour générer le certificat TLS. Les commandes suivantes permettent d’ouvrir ces ports :

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      Sur le client, il suffit d’ouvrir le port 80 avec cette commande :

      Client

      Vous avez maintenant installé les composants nécessaires et terminé la configuration du système de base sur le client et le serveur. Avant de pouvoir configurer ces composants pour commencer à relayer les messages du journal, vous devez enregistrer les certificats Let’s Encrypt TLS pour le client et le serveur à l’aide de l’utilitaire certbot.

      Étape 2 — Installation de Certbot et enregistrement de certificats

      Let’s Encrypt est une autorité de certification qui délivre des certificats TLS gratuits. Ces certificats permettent aux ordinateurs à la fois de crypter les données qu’ils s’envoient entre eux et de vérifier l’identité de chacun. Ce sont ces certificats qui vous permettent de sécuriser votre navigation sur Internet avec HTTPS. Les mêmes certificats peuvent être utilisés par toute autre application qui souhaite le même niveau de sécurité. La procédure d’enregistrement du certificat est la même, quelle que soit l’utilisation que vous en ferez.

      Au cours de cette étape, vous installerez l’utilitaire certbot et l’utiliserez pour enregistrer les certificats. Il se chargera également de renouveler automatiquement les certificats lorsqu’ils arriveront à expiration. La procédure d’enregistrement est ici la même sur le client et sur le serveur. Il vous suffit de changer le nom d’hôte pour qu’il corresponde à celui de l’hôte sur lequel vous exécutez la commande d’enregistrement.

      Tout d’abord, installez certbot et l’utilitaire curl sur les deux hôtes :

      Client and Server

      • sudo apt install certbot curl

      Maintenant que vous avez installé certbot, exécutez la commande suivante pour enregistrer les certificats sur le client et le serveur :

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Les options de cette commande signifient ce qui suit :

      • certonly : enregistrer le certificat et ne faire aucune autre modification dans le système.
      • --standalone : utiliser le serveur web intégré de certbot pour vérifier la demande de certificat.
      • --agree-tos : accepter automatiquement les conditions d’utilisation du service Let’s Encrypt.
      • --email your-email : il s’agit de l’adresse électronique que Let’s Encrypt utilisera pour vous informer de l’expiration du certificat et d’autres informations importantes.
      • -d your_domain : le nom d’hôte pour lequel le certificat sera enregistré. Il doit correspondre au système dans lequel vous l’exécutez.

      Lorsque vous exécutez cette commande, il vous sera demandé si vous souhaitez partager l’adresse électronique avec Let’s Encrypt afin qu’ils puissent vous envoyer des bulletins d’actualités et d’autres informations sur leur travail. Cette opération est facultative. Si vous ne communiquez pas votre adresse électronique, l’enregistrement du certificat se déroulera quand même normalement.

      Lorsque le processus d’enregistrement du certificat sera terminé, il placera le certificat et les fichiers clés dans /etc/letsencrypt/live/your_domain/your_domain est le nom d’hôte pour lequel vous avez enregistré le certificat.

      Enfin, vous devez télécharger une copie de l’AC Let’s Encrypt et des certificats intermédiaires, puis les placer dans le même fichier. journald utilisera ce fichier pour vérifier l’authenticité des certificats sur le client et le serveur lorsqu’ils communiquent entre eux.

      La commande suivante permet de télécharger les deux certificats sur le site web Let’s Encrypt et de les placer dans un seul fichier appelé letsencrypt-combined-certs.pem dans le répertoire personnel de votre utilisateur.

      Exécutez cette commande sur le client et le serveur pour télécharger les certificats et créer le fichier combiné :

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Ensuite, déplacez ce fichier dans le répertoire Let’s Encrypt contenant les certificats et les clés :

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Vous avez maintenant enregistré les certificats et les clés. Dans l’étape suivante, vous configurerez le serveur de collecte de journaux pour qu’il commence à écouter et à stocker les messages des journaux du client.

      Étape 3 — Configuration du serveur

      Au cours de cette étape, vous configurerez le serveur pour qu’il utilise les fichiers de certificats et de clés que vous avez générés à la dernière étape afin qu’il puisse commencer à accepter les messages de journal du client.

      systemd-journal-remote est le composant qui écoute les messages de journal. Ouvrez son fichier de configuration à l’adresse /etc/systemd/journal-remote.conf avec un éditeur de texte pour commencer à le configurer sur le serveur :

      • sudo nano /etc/systemd/journal-remote.conf

      Ensuite, décommentez toutes les lignes sous la section [Remote] et définissez les chemins d’accès aux fichiers TLS que vous venez de créer :

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Voici les options que vous avez utilisées ici :

      • Seal=false : signer les données du journal dans le journal. Activez cette option si vous avez besoin d’une sécurité maximale ; sinon, vous pouvez la laisser comme false.
      • SplitMode=host : les journaux des clients distants seront répartis par hôte dans /var/log/journal/remote. Si vous préférez que tous les journaux soient ajoutés dans un seul fichier, réglez celui-ci sur SplitMode=false.
      • ServerKeyFile : le fichier de clé privée du serveur.
      • ServerCertificateFile: le fichier de certificat du serveur.
      • TrustedCertificateFile: le fichier contenant les certificats AC Let’s Encrypt.

      Maintenant, vous devez modifier les autorisations sur les répertoires de Let’s Encrypt qui contiennent les certificats et la clé afin que le systemd-journal-remote puisse les lire et les utiliser.

      Tout d’abord, modifiez les autorisations afin que le certificat et la clé privée soient lisibles :

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ensuite, changez la propriété du groupe de la clé privée pour celle du groupe de systemd-journal-remote :

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Vous pouvez maintenant lancer systemd-journal-remote :

      • sudo systemctl start systemd-journal-remote.service

      Votre serveur de collecte de journaux est maintenant en cours d’exécution et prêt à commencer à accepter les messages de journaux d’un client. Dans l’étape suivante, vous configurerez le client pour qu’il transmette les journaux à votre serveur de collecte.

      Étape 4 — Configuration du client

      Au cours de cette étape, vous configurerez le composant qui relaie les messages du journal au serveur de collecte des journaux. Ce composant s’appelle systemd-journal-upload.

      La configuration par défaut de systemd-journal-upload fait qu’il a recours à un utilisateur temporaire qui n’existe que pendant le déroulement du processus. Il est donc plus compliqué d’autoriser systemd-journal-upload à lire les certificats et les clés TLS. Pour résoudre ce problème, vous créerez un nouvel utilisateur système portant le même nom que l’utilisateur temporaire qui sera utilisé à sa place.

      Tout d’abord, créez le nouvel utilisateur appelé systemd-journal-upload sur le client avec la commande adduser suivante :

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Ces options de commande sont :

      • --system : créer le nouvel utilisateur en tant qu’utilisateur système. Elle donne à l’utilisateur un numéro UID (User Identifier) inférieur à 1000. Les UID de plus de 1 000 sont généralement attribués à des comptes utilisateurs avec lesquels un humain se connectera.
      • --home /run/systemd : définir /run/systemd comme le répertoire d’origine de cet utilisateur.
      • --no-create-home : ne pas créer le répertoire d’origine, car il existe déjà.
      • --disabled-login : l’utilisateur ne peut pas se connecter au serveur (via SSH, par exemple).
      • --group : créer un groupe portant le même nom que l’utilisateur.

      Ensuite, définissez les autorisations et la propriété des fichiers de certificat Let’s Encrypt :

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Maintenant, modifiez la configuration pour systemd-journal-upload, qui se trouve dans /etc/systemd/journal-upload.conf. Ouvrez ce fichier avec un éditeur de texte :

      • sudo nano /etc/systemd/journal-upload.conf

      Modifiez ce fichier de manière à ce qu’il ressemble à ce qui suit :

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Enfin, redémarrez le service systemd-journal-upload afin qu’il utilise la nouvelle configuration :

      • sudo systemctl restart systemd-journal-upload.service

      Votre client est maintenant configuré, en cours d’exécution et envoie ses messages au serveur de collecte de journaux. Dans l’étape suivante, vous vérifierez que les journaux sont correctement envoyés et enregistrés.

      Étape 5 — Test du client et du serveur

      Au cours de cette étape, vous vérifierez que le client relaie les messages de journaux au serveur et que le serveur les stocke correctement.

      Le serveur de collecte des journaux stocke les journaux des clients dans le répertoire /var/log/journal/remote/. Lorsque vous avez redémarré le client à la fin de la dernière étape, il a commencé à envoyer des messages de journaux ; il y a donc maintenant un fichier journal dans /var/log/journal/remote/. Le fichier sera nommé d’après le nom d’hôte que vous avez utilisé pour le certificat TLS.

      Utilisez la commande ls pour vérifier que le fichier journal du client est présent sur le serveur :

      Server

      • sudo ls -la /var/log/journal/remote/

      Cela permet d’imprimer le contenu du répertoire contenant le fichier journal :

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      Ensuite, écrivez un message de journal sur le client pour vérifier que le serveur reçoit les messages du client comme prévu. Vous utiliserez l’utilitaire logger pour créer un message de journal personnalisé sur le client. Si tout fonctionne correctement, systemd-journal-upload transmettra ce message au serveur.

      Sur le client, exécutez la commande logger suivante :

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      Le -p syslog.debug de cette commande définit la facilité et la gravité du message. Si vous réglez ce paramètre sur syslog.debug, vous verrez qu’il s’agit d’un message de test. Cette commande enregistre le message ### TEST MESSAGE from client.your_domain ### dans le journal du client, que systemd-journal-upload transfère au serveur.

      Ensuite, lisez le fichier journal du client sur le serveur pour vérifier que les messages du journaux arrivent bien en provenance du client. Ce fichier est un fichier journal binaire, vous ne pourrez donc pas le lire avec des outils comme less. Lisez plutôt le fichier en utilisant journalctl avec l’option --file= qui vous permet de spécifier un fichier journal personnalisé :

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      Le message du journal apparaîtra comme suit :

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Votre serveur de centralisation des journaux recueille maintenant avec succès les journaux de votre système client.

      Conclusion

      Dans cet article, vous avez mis en place un serveur central de collecte de journaux et configuré un client pour qu’il transmette une copie de ses journaux système au serveur. Vous pouvez configurer autant de clients que nécessaire pour relayer les messages au serveur de collecte de journaux en exécutant les étapes de configuration des clients que vous avez réalisées ici.



      Source link