La rotation des journaux tourne réellement (logrotate est planifié)
Vérifie que logrotate n'est pas seulement installé mais réellement planifié : soit logrotate.timer est actif, soit /etc/cron.daily/logrotate est exécutable. Un logrotate.conf parfait derrière une minuterie masquée ne fait tourner aucun journal. Ce contrôle natif pavois de la famille growth-* audite le mécanisme qui borne /var/log, pas l'espace libre dont il dispose aujourd'hui.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Ce que vérifie Pavois
Le contrôle interroge l'état du planificateur à l'exécution, pas un fichier de configuration : systemctl is-active logrotate.timer doit renvoyer active, ou /etc/cron.daily/logrotate doit porter le bit exécutable (l'ancien chemin, piloté par cron, encore utilisé sur certaines images). L'un ou l'autre prouve que la rotation se déclenchera vraiment. Vérifier la seule présence de /etc/logrotate.conf fabriquerait des faux négatifs : le paquet peut être installé, les règles impeccables, et la minuterie désactivée ou masquée.
describe command('systemctl is-active logrotate.timer 2>/dev/null | grep -qx active || test -x /etc/cron.daily/logrotate && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Confirmez la planification, puis son déclenchement réel :
systemctl is-active logrotate.timer
systemctl list-timers logrotate.timer --all
test -x /etc/cron.daily/logrotate && echo cron-path-ok
logrotate --debug /etc/logrotate.conf effectue une simulation et affiche les fichiers qui tourneraient, sans y toucher.
Inspecter et investiguer
Chaque exécution laisse une trace dans journalctl -u logrotate.service, et logrotate horodate son fichier d'état (/var/lib/logrotate/status sur Debian et Ubuntu, /var/lib/logrotate.status sur RHEL) : chaque journal géré y porte la date de sa dernière rotation. Un fichier d'état dont les horodatages datent de plusieurs semaines signe une rotation qui ne tourne plus, visible bien avant que le disque ne se remplisse.
Remédiation
Pavois exécute l'étape logrotate-scheduled : si une unité logrotate.timer existe, elle est activée et démarrée immédiatement (systemctl enable --now logrotate.timer) ; sinon, sur les images pilotées par cron, /etc/cron.daily/logrotate reçoit le bit exécutable. L'étape est gardée par un not_if qui reteste les deux chemins, si bien qu'un hôte déjà planifié n'est pas touché et que confkit harden apply reste idempotent.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | systemctl list-unit-files logrotate.timer --no-legend 2>/dev/null | grep -q . && systemctl enable --now logrotate.timer 2>/dev/null; test -f /etc/cron.daily/logrotate && chmod +x /etc/cron.daily/logrotate; true |
|---|---|
| name | logrotate-scheduled |
| not_if | systemctl is-active logrotate.timer 2>/dev/null | grep -qx active || test -x /etc/cron.daily/logrotate |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque opérationnel quasi nul : on réactive un planificateur livré actif par défaut sur toutes les distributions supportées. La seule conséquence à anticiper est que les journaux vont désormais réellement tourner : tout outil qui garde un descripteur ouvert sur un journal, ou qui le suit par chemin, doit gérer la rotation (copytruncate, ou un signal postrotate vers le démon). À mettre en balance avec le mode de défaillance qui a fait naître cette famille : un hôte durci par pavois qui s'éteignait six secondes après chaque démarrage parce qu'un système de fichiers de journaux qu'il avait lui-même découpé atteignait 100 %, tous contrôles au vert.