Principal intérêt de logrotate: limiter l'accroissement à l'infini des fichiers logs.

Pour chaque fichier journal logrotate agit en 2 étapes:

1. rotation: archive le fichier de log et supprime les anciennes versions.
2. compression: si définit, compression des fichiers archivés.

Le système gère la planification de l’exécution régulière de logrotate, il suffit d'éditer les fichiers de configuration dans /etc/logrotate.d/ et de ne plus s'en soucier.

Les directives sont groupées entre crochets { } et s'appliquent sur un ou plusieurs fichiers journaux:

/path/to/file-1.log
{
  directive 1
  directive 2
  ...
  directive n
}

/path/to/file-2.log
/path/to/file-3.log
...
/path/to/file-n.log
{
  directive 1
  directive 2
  ...
  directive n
}

logrotate trace ses actions dans le fichiers /var/lib/logrotate/status le fichier texte indique pour chaque entrée le nom du fichier de log et le timestamp de la dernière altération.

Pour lancer manuellement logrotate utiliser l'option -f ou --force avec le fichier de configuration à tester (configuration globale ou dédiée)

logrotate --verbose --force /etc/logrotate.d/nextcloud
logrotate --verbose --force /etc/logrotate.conf

Pour déboguer/vérifier le bon fonctionnement la configuration courante utiliser l'option -d ou --debug:

logrotate -d /etc/logrotate.conf

Par sécurité logrotate interrompt le processus de rotation si les droits d'écritures sur le répertoire contenant les logs ne sont pas limités au groupe root. L'erreur est clairement remontée lors de l’exécution de logrotate avec l'option debug:

error: skipping "/path/to/log/file.log" because parent directory has insecure permissions (It'
s world writable or writable by group which is not "root") Set "su" directive in config file to tell
 logrotate which user/group should be used for rotation.

Si un groupe autre que root a le droit d’écriture sur le dossier contenant le fichier log, il doit être précisé dans la configuration de logrotate via la directive su afin que la rotation puisse s’effectuer.

# Exemple de rotation de fichiers de logs
# contenus dans un dossier ayant pour proprietaire www-data 

/srv/appweb/log/access.log
/srv/appweb/log/error.log
/srv/appweb/log/php_error.log
{
  su www-data www-data
  weekly
  rotate 4
  nocompress
  missingok
  create 0640 www-data www-data
}

logrotate peut être lancé périodiquement par un tout utilisateur non privilégié du système. Pour cela l'utilisateur crée son fichier de configuration et utilise cron pour appeler logrotate avec la périodicité qu'il souhaite:

crontab -e

La commande présente dans le fichier cron sera de la forme:

# Exemple de contenu du crontab de l'utilisateur
15 * * * * /usr/sbin/logrotate /home/username/logrotate.conf --state /home/username/logrotate-state

Lorsque logrotate est exécuté avec l'argument -d les messages ne retournent pas d'anomalies cependant la rotation des logs ne se fait pas.

Ceci peut être du à:

• Des problèmes de droits d'accès lorsque logrotate s’exécute sous un autre compte que root (directive su)
• Si des scripts prerotate existent une erreur d'exécution peut interrompre le processus.

Invoquer la commande logrotate avec le fichier de configuration à tester et l'option -f pour forcer l’exécution d'une rotation et déclencher l'appel des scripts. Les erreurs retournées devront être corrigées.

La rotation des logs de l'hôte virtuel apache s'est bien exécutée mais apache continue à écrire dans le fichier précédent xxx.log.1 au lieu d'utiliser xxx.log

Dans ce cas, utiliser la directive postrotate/endscript pour recharger la configuration apache après rotation:

postrotate
/usr/sbin/apache2ctl -k graceful
endscript

Après rotation, le nouveau fichier ufw.log reste vide. Les événements continuent à être écris dans le fichier archive ufw.x.log

C'est le daemon rsyslogd qui se charge d'écrire les messages dans le fichier /var/log/ufw.log. Dans le fichier de configuration /etc/logrorate.d/ufw, on peut voir que la commande proposée par défaut retourne une erreur quand elle est exécutée manuellement.

invoke-rc.d rsyslog rotate
* Closing open files rsyslogd                                                            [fail]

Cela peut être du au fait que rsyslog géré comme unité par systemd. Les commandes suivantes ont le même effet et ne retourne pas d'erreur:

# cette commande est aussi utilisée par d'autres fichiers de configuration
/usr/lib/rsyslog/rsyslog-rotate
 
# equivalent
systemctl kill -s HUP rsyslog.service

Ci-dessous un exemple de fichier /etc/logrotate.d/ufw modifié:

ufw

/var/log/ufw.log
{
  su root syslog
 
  # Rotation quotidienne
  daily 
 
  # Conserve 30 fichiers (un mois) 
  rotate 30
 
  # Les fichiers archives ne sont pas compressés
  nocompress
 
  # Ne génère pas de message d'erreur si le fichier est manquant
  missingok
 
  # droit d'acces et propriétaire du fichier apres rotation
  create 0644 syslog adm
 
  sharedscripts
  postrotate
    /usr/lib/rsyslog/rsyslog-rotate
  endscript
}

• https://memo-linux.com/logrotate/
• https://doc.ubuntu-fr.org/logrotate
• https://www.croc-informatique.fr/2009/06/rotation-des-logs-avec-logrotate/
• https://chasemp.github.io/2013/07/24/su-directive-logrotate/
• https://www.techrepublic.com/article/manage-linux-log-files-with-logrotate/
• https://linoxide.com/setup-log-rotation-logrotate-ubuntu/
• https://www.digitalocean.com/community/tutorials/how-to-manage-logfiles-with-logrotate-on-ubuntu-20-04