Erreur : Frontmatter invalide

Chemin: /home/itametis/university/user/pages/02.articles/01.informatique/09.system/04.logrotate/001_rotation_des_logs_avec_logrotate/_article.fr.md

Failed to read /home/itametis/university/user/pages/02.articles/01.informatique/09.system/04.logrotate/001_rotation_des_logs_avec_logrotate/_article.fr.md: A YAML file cannot contain tabs as indentation at line 4 (near " - Logrotate").

---
title: 'Gérer la rotation du fichier auth.log sous GNU/Linux'
taxonomy:
    category:
        -  Logrotate
    tag:
        - devops
        - cours
        - tuto
        - tutoriel
        - log
        - logs
        - linux
        - logrotate
        - rotation
        - sécurité
        - journal
        - journaux
        - auth.log
        - system
date: '15-12-2017 00:00'
metadata:
    author:  'Gaulthier LALLEMAND'
    image: /images/logos/linux.png
---

###### Prérequis : notions de base en shell.

----
## Usage
Le système recense les accès (ou tentatives d'accès) à une machine dans un fichier journal.

Sur un système Debian (ou assimilé), ce fichier est `/var/log/auth.log` . Sur Redhat ou CentOS il change de nom pour `/var/log/secure` . Mais peu import, le principe reste le même quelle que soit la distribution. Pour la suite, je vais considérer un **système Debian** et un fichier **/var/log/auth.log** .

*Logrotate* sert à gérer la rotation et l'archivage des fichiers journaux (les logs). Pour le fichier *auth.log*, le résultat (par défaut) est le suivant :

```console
-rw-r----- 1 root adm /var/log/auth.log
-rw-r----- 1 root adm /var/log/auth.log.1
-rw-r----- 1 root adm /var/log/auth.log.2.gz
-rw-r----- 1 root adm /var/log/auth.log.3.gz
-rw-r----- 1 root adm /var/log/auth.log.4.gz

Objectif

Je souhaite monitorer les accès à ma machine à l'aide l'un logiciel tiers, dont la source d'information est cette série de fichiers auth.log.

Problèmes

• En plus de la semaine courante, je n'ai accès qu'à quatre semaines d'historique de connexions. J'aimerais disposer d'une durée beaucoup plus significative afin de pouvoir extraire des tendances, déterminer les pics de charge, savoir qui se connecte, depuis où...
• J'aimerais que les fichiers auth.log.X les plus anciens ne soient pas compressés, afin d'être utilisables en l'état par le logiciel de traitement des logs.
• J'aimerais que les paramètres de gestion de mon fichier auth.log soient clairement identifiables et séparés des autres.
• Les droits sur ces fichiers sont trop restrictifs. Je veux que mon logiciel tiers puisse lire les logs.

Solution

1) Isoler la configuration de auth.log

La configuration du fichier auth.log est groupée avec celle des autres logs du système, dans le fichier /etc/logrotate.d/rsyslog (exemple). Ce fichier est divisé en deux parties:

• La première partie (lignes 3 à 14) concerne le fichier /var/log/syslog , et le bloc entre accolades contient les paramètres gérant ce fichier.
• La deuxième partie (lignes 16 à 39) concerne un groupe de fichiers, incluant celui qui m'intéresse (ligne 22).

Si je modifie les paramètres du bloc entre accolades (lignes 28 à 39), je vais également modifier les paramètres pour tous les autres fichiers de la liste. Pour éviter ça, deux possibilités s'offrent à moi :

• Je peux créer un nouveau bloc en déplaçant le chemin du fichier cible à la fin du fichier rsyslog, tout en le faisant suivre d'une copie du bloc de ses paramètres (voir le résultat). La configuration du fichier auth.log est alors distincte des autres, et les modifications l'affectant ne touchent pas les autres fichiers.
• Mais je peux aussi bien créer un nouveau fichier (dont le nom n'a pas d'importance) situé dans /etc/logrotate.d destiné à ne recevoir que la configuration pour mon fichier spécifique (voir le résultat). Cette fois, les paramètres régissant la rotation du fichier auth.log sont clairement séparés des autres.

Note : Il existe une configuration par défaut de logrotate, valable quel que soit le fichier de log surveillé, disponible dans le fichier /etc/logrotate.conf (voir). Les paramètres spécifiés dans les fichiers de configuration prennent le dessus sur ceux par défaut. Ainsi, la configuration minimale requise pour gérer un fichier de log n'est autre qu'un fichier contenant le chemin vers un fichier de log à surveiller suivi d'accolades ouvrante et fermante (exemple).

2) Empêcher la compression des logs archivés

Pour cela, il suffit de supprimer les instructions compress et delaycompress.

J'en profite pour supprimer également l'instruction sharedscripts qui est inutile ici. Elle sert à indiquer que la commande située entre postrotate et endscript se lance une seule fois pour l'ensemble des fichiers de logs surveillés, à chaque rotation. Or ici il n'y a qu'un seul fichier surveillé, /var/log/auth.log.

Ce qui nous donne la configuration suivante:

/var/log/auth.log
{
    rotate 4
    weekly
    missingok
    notifempty
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

3) Choisir la fréquence de rotation des logs

Je dois choisir à quelle fréquence le fichier auth.log sera archivé et renouvelé. Quatre valeurs sont disponibles: daily, weekly, monthly et yearly. Pour mes besoins, je remplace weekly par daily dans ma configuration, étant donné le grand nombre de connexions sur la machine.

J'obtiens donc :

/var/log/auth.log
{
    rotate 4
    daily
    missingok
    notifempty
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

4) Choisir le nombre de rotations à effectuer

C'est tout simplement le chiffre figurant juste après l'instruction rotate. Pour mon besoin, je vais mettre 730. Ce qui signifie concrètement que logrotate ne commencera à supprimer les fichiers de log qu'à partir de la 731ème rotation. Comme j'ai choisi une rotation journalière (commande daily), j'aurai donc au maximum 730 jours de logs en plus du jour courant.

Vous devez faire votre calcul selon vos besoins, et décider en conséquence de la fréquence et du nombre des rotations.

J'obtiens donc :

/var/log/auth.log
{
    rotate 730
    daily
    missingok
    notifempty
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

5) Modifier les droits sur les fichiers de logs

Pour que mon logiciel tiers puisse lire les logs, je dois modifier les permissions de ces fichiers. Le comportement par défaut de logrotate consiste à créer un nouveau fichier de log vide, ayant les mêmes droits, le même propriétaire et le même groupe que le fichier de log d'origine.

Pour forcer logrotate à changer les permissions des nouveaux fichiers créés, j'ajoute l'instruction create avec ces options :

create [mode] [owner] [group]

Pour ma situation, je vais conserver les caractéristiques d'origine, et ajouter le droit en lecture pour le groupe other.

Ce qui donne la configuration finale :

/var/log/auth.log
{
    rotate 730
    daily
    create 644 root adm
    missingok
    notifempty
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

Et voilà !

Il n'y a rien à relancer. Logrotate prendra en compte cette configuration à son prochain lancement.