L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’un don dans le cadre du programme Write for DOnations.
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 :
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.
Avant de commencer ce guide, vous aurez besoin des éléments suivants :
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.
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 :
- sudo apt update
- sudo apt upgrade
Ensuite, installez le paquet systemd-journal-remote
:
- 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 :
- 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 :
- 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 :
- 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 :
- sudo ufw allow in 80/tcp
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
.
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 :
- 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 :
- 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/
où 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é :
- 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 :
- 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.
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 :
[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.
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 :
[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.
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 :
- sudo ls -la /var/log/journal/remote/
Cela permet d’imprimer le contenu du répertoire contenant le fichier journal :
Outputtotal 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 :
- 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é :
- 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.
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.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.