Cours Ubuntu 26.04 / Configurer la conservation du journal et la rotation des fichiers de log

Sur Ubuntu, configurez séparément la conservation du journal systemd et la rotation des journaux ordinaires écrits dans des fichiers. Identifiez d’abord les collecteurs et préservez les enregistrements nécessaires avant de réduire une limite : rétablir la configuration ne récupère pas les anciens journaux déjà supprimés.

Identifier les collecteurs et l’emplacement des données

systemctl status systemd-journald rsyslog --no-pager
sudo journalctl --disk-usage
sudo journalctl --list-boots
ls /var/log

systemd-journald collecte des événements structurés, notamment les sorties standard des services. rsyslog peut aussi écrire des fichiers texte selon sa configuration. Sans rsyslog installé ou actif, l’absence de /var/log/syslog ne signifie pas automatiquement que le système ne journalise rien.

Pour chaque application, relevez sa configuration de service et de sortie : journal, fichier propre, ou plusieurs destinations. Les fichiers binaires du journal ne doivent pas être traités comme des fichiers texte par logrotate ni effacés manuellement pendant leur utilisation.

Selon la configuration de systemd-journald, /run/log/journal est volatil et /var/log/journal permet un stockage persistant. Vérifiez le mode effectif et les anciens démarrages réellement disponibles ; la simple présence d’un répertoire ne suffit pas à valider la durée de conservation.

Vérifier la génération et les filtres de recherche

Créez un repère sans données sensibles et recherchez-le immédiatement :

logger -t ubuntu-course-log 'retention-lab-marker'
sudo journalctl -t ubuntu-course-log --since '5 minutes ago' --no-pager
sudo journalctl -b -p warning --no-pager

Le marqueur doit apparaître avec le tag demandé dans la première recherche. La deuxième recherche applique une priorité warning ou plus grave pendant ce démarrage ; elle ne vise pas le même ensemble d’événements et peut exclure le marqueur d’information.

Utilisez les filtres de démarrage, d’heure, d’unité et de priorité pour rapprocher une panne de ses événements. Un résultat vide peut venir de l’accès aux données, du collecteur, de l’horloge ou du filtre choisi. Ne donnez pas à tous les utilisateurs un accès élargi aux journaux pour contourner une simple difficulté de lecture.

Choisir une politique sans la confondre avec une garantie d’archivage

Les valeurs suivantes sont un exemple pour une petite VM dédiée. Elles ne représentent pas une durée à appliquer uniformément aux serveurs. Choisissez volume, durée, accès et sauvegarde selon les besoins des données à conserver.

[Journal]
Storage=persistent
SystemMaxUse=200M
RuntimeMaxUse=50M
MaxRetentionSec=7day

SystemMaxUse concerne l’espace des journaux persistants, RuntimeMaxUse le stockage volatil, et MaxRetentionSec l’ancienneté maximale configurée. Ces limites ne garantissent pas la présence de sept jours complets si la limite de taille, le manque d’espace ou un défaut de collecte intervient plus tôt.

La configuration journald.conf tient aussi compte des fichiers actifs et archivés ainsi que de la rotation. Ne présentez pas 200M comme un plafond instantané exact à l’octet près. Storage=persistent peut temporairement se replier sur /run si le stockage disque n’est pas inscriptible.

Avant l’application, conservez les journaux nécessaires dans un emplacement indépendant et protégé, puis vérifiez leur lecture. Une copie du seul fichier de configuration ne contient pas l’historique. Pour un export de journal, définissez explicitement les unités et dates nécessaires avec les options de journalctl, puis validez le format retenu et sa réutilisation. Évitez un export intégral public de données internes.

Créer un drop-in neuf et relire l’ordre des réglages

Le bloc suivant sauvegarde la configuration locale et refuse d’écraser le fragment d’exercice existant. Il vise le journal par défaut ; des espaces de noms de journal peuvent avoir leurs propres fichiers. N’utilisez pas ces limites sur un serveur dont les données nécessaires ne sont pas déjà préservées.

(
set -eu
lab_conf=/etc/systemd/journald.conf.d/60-lab-retention.conf
if sudo test -e "$lab_conf" || sudo test -L "$lab_conf"; then
    printf 'Fichier existant : examinez-le avant de poursuivre.\n' >&2
    exit 1
fi
backup_dir=$(sudo mktemp -d /root/journal-before-lab.XXXXXX)
if sudo test -f /etc/systemd/journald.conf; then
    sudo cp -a /etc/systemd/journald.conf "$backup_dir/"
fi
if sudo test -d /etc/systemd/journald.conf.d; then
    sudo cp -a /etc/systemd/journald.conf.d "$backup_dir/"
fi
sudo mkdir -p /etc/systemd/journald.conf.d
sudo sh -c 'set -C; cat > "$1"' sh "$lab_conf" <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=200M
RuntimeMaxUse=50M
MaxRetentionSec=7day
EOF
sudo systemd-analyze cat-config systemd/journald.conf
printf 'Sauvegarde des réglages locaux : %s\n' "$backup_dir"
)

Relisez les fichiers affichés, les quatre valeurs et les fragments chargés ensuite. cat-config présente les fichiers et leur ordre, mais ne certifie pas que chaque option est valide ni que le démon l’a déjà appliquée. D’autres sources peuvent exister sous /run ou /usr : préservez-les et notez les réglages antérieurs qui en résultent.

Si la création ou la lecture échoue, arrêtez avant le redémarrage. Un fragment créé sur disque mais non appliqué peut encore prendre effet plus tard : corrigez-le ou retirez uniquement ce nouvel ajout après examen.

Appliquer et vérifier la persistance sans effacer les fichiers du journal

Après la revue et la sauvegarde des données à conserver, appliquez pendant la fenêtre prévue :

(
set -eu
sudo systemctl restart systemd-journald.service
sudo journalctl --flush
sudo journalctl --disk-usage
logger -t ubuntu-course-log 'after-retention-change'
sudo journalctl -t ubuntu-course-log --since '5 minutes ago' --no-pager
sudo journalctl -u systemd-journald.service --since '5 minutes ago' --no-pager
)

Examinez les erreurs de configuration, d’accès au disque et de collecte. --flush demande le transfert du stockage volatil vers le persistant lorsque ses conditions sont réunies. Une baisse ou une stabilité de disk-usage ne suffit pas à établir que tous les événements nécessaires sont conservés.

La documentation de journald recommande restart plutôt qu’un stop puis start séparés pour préserver les connexions de flux des services. N’effacez pas les fichiers binaires pour forcer la politique. Après un redémarrage planifié de la VM, contrôlez --list-boots et recherchez le marqueur du démarrage précédent pour vérifier la persistance attendue.

Pour restaurer la combinaison de réglages antérieure, vérifiez que le fragment est toujours exactement celui de cet exercice, puis retirez uniquement cet ajout :

(
set -eu
sudo rm -- /etc/systemd/journald.conf.d/60-lab-retention.conf
sudo systemctl restart systemd-journald.service
sudo journalctl --flush
sudo systemd-analyze cat-config systemd/journald.conf
)

Relisez ensuite les journaux du service et les valeurs retenues. L’état du stockage créé peut persister après le retrait d’une option ; par exemple, la présence de /var/log/journal compte pour un ancien mode auto. Restaurer les réglages ne recrée pas les enregistrements supprimés et ne remet pas automatiquement le stockage à un état antérieur.

Faire tourner un fichier d’essai avec un état logrotate indépendant

La rotation d’un fichier ordinaire change ou archive le fichier dans lequel l’application écrit. Préparez logrotate et gzip sur la VM, puis utilisez ce bloc Bash avec votre compte habituel. Il crée un nouveau dossier privé, un journal synthétique et son propre fichier d’état, sans lire la configuration globale logrotate :

(
set -eu
umask 077
work=$(mktemp -d "$HOME/logrotate-lab.XXXXXX")
for i in {1..200}; do printf 'lab line %04d\n' "$i"; done > "$work/app.log"
cat > "$work/logrotate.conf" <<EOF
"$work/app.log" {
    size 1k
    rotate 2
    compress
    missingok
    notifempty
    create 0600
}
EOF
logrotate -d -s "$work/state" "$work/logrotate.conf"
logrotate -s "$work/state" "$work/logrotate.conf"
ls -l "$work"
gzip -cd "$work/app.log.1.gz"
printf 'Dossier du laboratoire : %s\n' "$work"
)

Le mode debug -d montre le plan sans modifier les journaux ni le fichier d’état. La deuxième commande exécute la rotation de ce seul fichier dépassant 1k. Le résultat attendu est un nouvel app.log vide et une archive app.log.1.gz contenant les 200 lignes, lisibles avec gzip. Conservez le chemin affiché ; la variable du sous-shell ne reste pas disponible ensuite.

rotate 2 signifie au plus deux archives de rotation, pas deux jours. Le critère size est évalué lorsque logrotate s’exécute : ce n’est pas une surveillance continue qui tourne le fichier dès le franchissement du seuil. Pour un vrai service, vérifiez aussi la minuterie ou la tâche planifiée réellement utilisée sur la machine.

Le manuel logrotate d’Ubuntu détaille ces règles. Un programme peut garder son ancien descripteur de fichier ouvert après rotation ; prévoyez sa méthode documentée de réouverture, éventuellement dans postrotate. copytruncate peut perdre des lignes pendant la copie et la troncature : ce n’est pas un remplacement universel à appliquer pour éviter cette analyse.

Contrôler le résultat et les limites de la conservation

Pour une politique réelle, vérifiez séparément génération, recherche, lisibilité des archives, droits de consultation, consommation et comportement après redémarrage. Une application qui répond n’établit pas qu’elle produit toujours des traces, et un journal présent n’établit pas que sa rotation fonctionne.

Gardez les fichiers du laboratoire tant que vous relisez le résultat ; si vous les nettoyez ensuite, confirmez le répertoire créé et retirez uniquement ses fichiers d’essai. Ne réutilisez pas le fichier d’état système pour rejouer cet exercice.

Consignez les limites retenues, les sources de configuration, l’emplacement des archives indépendantes, les lecteurs autorisés et le contrôle d’échec. Une réduction de conservation doit rester compatible avec les besoins réels de vos enregistrements ; le retour d’un paramètre à sa valeur initiale ne tient pas lieu de restauration des données.