Aujourd’hui nous allons étudier la façon dont linux gère la journalisation par défaut et comment créer des règles personnalisées pour nos logs issues du reverse proxy traefik.

Si vous avez déjà analysé les logs d’une machine linux, vous êtes vous demandés pourquoi la journalisation syslog, wtmp ou autres btmp ne remonte pas à la date d’installation de la machine?

Bien sûr, probablement pour une histoire de stockage, mais qui a configuré cela? Et surtout, comment?

C’est ce que nous allons voir ici.

Syslog

Nous appuierons nos propos en prenant les logs syslog comme exemple.

Allons les voir:

root@test:/ ls -lh /var/log/syslog*
-rw-r----- 1 root adm  98M mai   10 11:13 /var/log/syslog
-rw-r----- 1 root adm 209M mai   10 00:00 /var/log/syslog.1
-rw-r----- 1 root adm 2,1M mai    9 00:00 /var/log/syslog.2.gz
-rw-r----- 1 root adm 2,2M mai    8 00:00 /var/log/syslog.3.gz
-rw-r----- 1 root adm 2,3M mai    7 00:00 /var/log/syslog.4.gz
-rw-r----- 1 root adm 2,2M mai    6 00:00 /var/log/syslog.5.gz
-rw-r----- 1 root adm 2,2M mai    5 00:00 /var/log/syslog.6.gz
-rw-r----- 1 root adm 1,1M mai    4 00:00 /var/log/syslog.7.gz

Qu’avons nous donc ici…

• 8 fichiers syslog*
• Le premier n’a pas de numérotation
• Le second n’a pas d’extension « gz », il n’est pas archivé
• Les 7 autres sont numérotés et son archivés. Notez au passage le ratio de compression assez hallucinant.
• Ces fichiers sont crées tous les jours à 00h00 (4 mai pour le syslog.7, 5 mai pour le syslog.6, etc…)
• Ils appartiennent à l’utilisateur root, et au groupe adm.

Bon, on a à peu près fait le tour. Allons voir comment tout cela est configuré…

Logrotate

Sauf exception, la journalisation sous linux est gérée par l’outil « logrotate« , qui, comme son nom l’indique, va faire « tourner » les logs.

Comme d’habitude, la configuration va se trouver dans /etc/:

root@test:/etc ll logrot*
-rw-r--r-- 1 root root  435 août  22  2018 logrotate.conf

logrotate.d:
-rw-r--r--   1 root root   120 avril 19  2019 alternatives
-rw-r--r--   1 root root   173 sept. 13  2017 apt
-rw-r--r--   1 root root   130 août  29  2018 btmp
-rw-r--r--   1 root root   112 avril 19  2019 dpkg
-rw-r--r--   1 root root    94 déc.   4  2015 ppp
-rw-r--r--   1 root root   501 févr. 26  2019 rsyslog
-rw-r--r--   1 root root   145 févr. 19  2018 wtmp

Nous avons donc un fichier « logrotate.conf » et un répertoire « logrotate.d » qui contient quelques noms connus (apt, btmp, rsyslog, etc…). Remarquez les droits de ces derniers fichiers (-rw-r–r–) qui correspond à 644.

Commençons par jeter un oeil à logrotate.conf qui contient une configuration par défaut:

root@test:/etc cat logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# use date as a suffix of the rotated file
#dateext
# uncomment this if you want your log files compressed
#compress
# packages drop log rotation information into this directory
include /etc/logrotate.d
# system-specific logs may be also be configured here.

Ok, cela nous indique que par défaut:

• Les journaux de logs sont crées toutes les semaines.
• L’on ne garde que 4 rotations (4 semaines donc).
• On crée un nouveau fichier blanc à chaque rotation.
• L’on inclue le contenu du répertoire logrotate.d pour les configurations spécifiques.

Alors allons voir les configurations spécifiques, notamment le fichier « rsyslog » pour notre exemple:

root@Serveur:/etc cat logrotate.d/rsyslog
/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}

Ah, c’est un peu plus complet…

• « /var/log/syslog » est spécifié, on sait de quoi ça parle.
• « rotate 7 » = 7 rotations.
• « daily » = rotation quotidienne.
• « missingok » = on ne s’arrête pas en cas d’erreur.
• « notifempty » = on ne crée rien si le fichier est vide.
• « delaycompress » = on attend une rotation complète pour compresser.
• « compress » = on archive les rotations.
• « postrorate » ** « endscript » = on exécute le script spécifié après chaque rotation.

Bien… Mais est-ce que cela correspond à ce nos syslog* ? On avait pas 8 fichiers?

Et bien si, mais cela s’explique par le fait que notre fichier « syslog » tout court est celui en cours d’écriture, il ne compte donc pas encore dans la rotation.

Ce soir a minuit, la rotation aura lieu, c’est à dire que le fichier le plus ancien (syslog.7.gz) va disparaître, mais le syslog.6.gz va être renommé en syslog.7.gz, le syslog.5.gz va être renommé en syslog.6.gz, et ainsi de suite… Le syslog.1 va être renommé en syslog.2.gz, le syslog en syslog.1 et un nouveau fichier vide nommé syslog va être créé.

Customisation

Ok, tout ça c’est bien, mais on peut le modifier? Encore mieux, on va créer une nouvelle règle…

Si vous vous souvenez, ici ou la, nous avons crée un répertoire ou sont stockés les logs de notre reverse proxy traefik.

Nous avons des access.log, ainsi que des traefik.log. Si on laisse ça comme cela, nous allons vite avoir deux fichiers texte de plusieurs gigas qu’il sera difficile d’exploiter en cas de besoin…

Maintenant que l’on sait comment fonctionne l’outil logrotate, on va créer notre propre règle.

Je vais donc créer un fichier nommé traefik que je vais déposer dans le répertoire /etc/logrotate.d/ et a qui je vais donner les droits 644.

####################################################################
# LOGROTATE SCRIPT TO PUSH IN /etc/logrotate.d/traefik && chmod 644#
####################################################################
# TRAEFIK ACCESSLOG
###################
/mnt/traefik/logs/access.log {
        rotate 52
        weekly
        compress
        delaycompress
        dateext
        notifempty
        missingok
}

###################
# TRAEFIK LOG
###################
/mnt/traefik/logs/traefik.log {
        rotate 4
        weekly
        compress
        delaycompress
        dateext
        notifempty
        missingok
}

Bien, dans ce fichier, je distingue deux configurations différentes en faisant référence aux deux fichiers.

En cas de problème de sécurité, avoir l’antériorité d’accès web est très important. Je décide donc de garder un an d’access.log (52 semaines). Par contre je n’ai pas besoin d’avoir un long historique des logs de l’outil traefik lui même. Si il ne fonctionne plus, je m’en rendrai vite compte. Un mois semble suffisant.

Une fois notre fichier créé avec les bons droits, dans le bon répertoire, il sera pris en compte lors de la prochaine rotation…