108.2 Leçon 1

Certification :

LPIC-1

Version :

5.0

Thème :

108 Services Systèmes Essentiels

Objectif :

108.2 Journalisation du système

Leçon :

1 sur 2

Introduction

Les journaux (logs) peuvent être le meilleur amis de l’administrateur système. Les journaux sont des fichiers (généralement des fichiers texte) dans lesquels tous les événements du système et du réseau sont enregistrés par ordre chronologique à partir du moment où votre système est démarré. Ainsi, la panoplie d’informations que l’on peut trouver dans les journaux comprend à peu près tous les aspects du système : tentatives d’authentification échouées, erreurs des programmes et des services, hôtes bloqués par le pare-feu, etc. Comme vous pouvez bien l’imaginer, les journaux facilitent considérablement la vie des administrateurs système en ce qui concerne le dépannage, le contrôle des ressources, la détection de comportements anormaux des programmes, et ainsi de suite.

Dans cette leçon, nous allons aborder l’une des applications de journalisation les plus courantes que l’on peut trouver dans les distributions GNU/Linux : rsyslog. Nous verrons les différents types de journaux qui existent, l’endroit où ils sont stockés, les informations qu’ils contiennent et comment celles-ci peuvent être récupérées et filtrées. Nous parlerons également de la manière dont les journaux peuvent être conservés sur des serveurs centralisés à travers des réseaux IP, de la rotation des journaux et de la mémoire tampon circulaire du noyau (kernel ring buffer).

Journalisation du système

Dès que le noyau et les différents processus de votre système commencent à se lancer et à communiquer les uns avec les autres, ils génèrent un grand nombre d’informations sous forme de messages qui sont — pour la plupart — envoyés vers les journaux.

Sans la journalisation, la recherche d’un événement survenu sur un serveur donnerait du fil à retordre aux administrateurs système, d’où l’importance de disposer d’un moyen standardisé et centralisé pour conserver la trace de tout ce qui se passe sur le système. Les journaux sont déterminants et révélateurs en matière de dépannage et de sécurité et constituent des sources de données fiables pour comprendre les statistiques du système et de prévoir les tendances.

En dehors de systemd-journald (dont nous parlerons dans la prochaine leçon), la journalisation a toujours été gérée par trois grands services dédiés : syslog, syslog-ng (syslog new generation) et rsyslog (the rocket-fast system for log processing). rsyslog a apporté d’importantes améliorations (comme le support de RELP) et constitue aujourd’hui le choix le plus populaire. Chacun de ces services collecte des messages provenant d’autres services et programmes et les stocke dans des fichiers de journalisation, typiquement dans /var/log. Cependant, certains services s’occupent de leurs propres journaux (comme par exemple le serveur web Apache HTTPD ou le système d’impression CUPS). De même, le noyau Linux utilise une mémoire tampon circulaire (ring buffer) pour stocker ses messages de journalisation.

Note	`RELP` (Reliable Event Logging Protocol) signifie protocole de journalisation fiable des événements et étend la fonctionnalité du protocole syslog pour assurer une transmission fiable des messages.

Étant donné que rsyslog est devenu l’outil de journalisation standard de facto dans toutes les grandes distributions, nous nous concentrerons sur lui pour cette leçon. rsyslog est basé sur un modèle client-serveur. Le client et le serveur peuvent tourner sur le même hôte ou sur des machines différentes. Les messages sont envoyés et reçus dans un format particulier et peuvent être conservés sur des serveurs rsyslog centralisés à travers des réseaux IP. Le démon de rsyslog — rsyslogd — travaille avec klogd (qui gère les messages du noyau). Dans les sections ci-dessous, nous aborderons rsyslog et son infrastructure de journalisation.

Note	Un démon est un service qui s’exécute en arrière-plan. Notez le `d` final dans les noms des démons : `klogd` ou `rsyslogd`.

Types de journaux

Les journaux étant des données variables, on les trouve normalement dans /var/log. En gros, on distingue les journaux système et les journaux des services ou des programmes.

Voyons quelques journaux système et les informations qu’ils renferment :

/var/log/auth.log: Activités liées aux processus d’authentification : utilisateurs connectés, informations sudo, tâches cron, tentatives de connexion échouées, etc.
/var/log/syslog: Un fichier centralisé pour pratiquement tous les journaux récupérés par rsyslogd. Étant donné qu’il contient énormément d’informations, les journaux sont répartis sur d’autres fichiers en fonction de la configuration fournie dans /etc/rsyslog.conf.
/var/log/debug: Informations de débogage des programmes.
/var/log/kern.log: Messages du noyau.
/var/log/messages: Messages informatifs qui ne sont pas liés au noyau mais à d’autres services. C’est également la destination par défaut des journaux des clients distants dans le cas de l’implémentation d’un serveur de journaux centralisé.
/var/log/daemon.log: Informations relatives aux démons ou aux services qui tournent en arrière-plan.
/var/log/mail.log: Informations relatives au serveur de messagerie comme Postfix.
/var/log/Xorg.0.log: Informations relatives à la carte graphique.
/var/run/utmp et /var/log/wtmp: Connexions réussies.
/var/log/btmp: Tentatives de connexion échouées comme les attaques en force brute via SSH.
/var/log/faillog: Tentatives d’authentification échouées.
/var/log/lastlog: Date et heure des dernières connexions des utilisateurs.

Voyons maintenant quelques exemples de journaux de services :

/var/log/cups/: Répertoire des journaux du système d’impression CUPS (Common Unix Printing System). Il contient généralement les fichiers de journalisation par défaut suivants : error_log, page_log et access_log.
/var/log/apache2/ ou /var/log/httpd: Répertoire des journaux du serveur web Apache. Il contient généralement les fichiers de journalisation par défaut suivants : access.log, error_log et other_vhosts_access.log.
/var/log/mysql: Répertoire des journaux du système de gestion de bases de données relationnelles MySQL. Il contient généralement les fichiers de journalisation par défaut suivants : error_log, mysql.log et mysql-slow.log.
/var/log/samba/: Répertoire pour les journaux du protocole Server Message Block (SMB). Il contient généralement les fichiers de journalisation par défaut suivants : log., log.nmbd et log.smbd.

Note

Le nom exact et le contenu des fichiers de journalisation peuvent varier d’une distribution Linux à une autre. Il existe également des journaux spécifiques à certaines distributions, comme /var/log/dpkg.log (contenant les informations relatives aux paquets dpkg) dans Debian GNU/Linux et ses dérivées.

Lire les fichier de journalisation

Pour lire les fichiers de journalisation, assurez-vous d’abord d’être le root ou d’avoir les droits de lecture sur le fichier. Vous pouvez utiliser divers outils comme :

less ou more

Commandes permettent de visualiser et de faire défiler page par page :

root@debian:~# less /var/log/auth.log
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:49:46 debian sshd[905]: Accepted password for carol from 192.168.1.65 port 44296 ssh2
Sep 12 18:49:46 debian sshd[905]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Sep 12 18:49:46 debian systemd-logind[331]: New session 2 of user carol.
Sep 12 18:49:46 debian systemd: pam_unix(systemd-user:session): session opened for user carol by (uid=0)
(...)

zless ou zmore

La même chose que less et more, mais utilisés avec les journaux compressés avec gzip (une fonction commune de logrotate) :

root@debian:~# zless /var/log/auth.log.3.gz
Aug 19 20:05:57 debian sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/sbin/shutdown -h now
Aug 19 20:05:57 debian sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Aug 19 20:05:57 debian lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event2 (Power Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event3 (Sleep Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event4 (Video Bus)
Aug 19 23:50:49 debian systemd-logind[333]: New seat seat0.
Aug 19 23:50:49 debian sshd[409]: Server listening on 0.0.0.0 port 22.
(...)

tail

Affiche les dernières lignes d’un fichier (10 lignes par défaut). La puissance de tail réside — en grande partie — dans l’option -f qui affiche dynamiquement les nouvelles lignes au fur et à mesure qu’elles sont ajoutées :

root@suse-server:~# tail -f /var/log/messages
2019-09-14T13:57:28.962780+02:00 suse-server sudo: pam_unix(sudo:session): session closed for user root
2019-09-14T13:57:38.038298+02:00 suse-server sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/messages
2019-09-14T13:57:38.039927+02:00 suse-server sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
2019-09-14T14:07:22+02:00 debian carol: appending new message from client to remote server...

head

Affiche les premières lignes d’un fichier (10 lignes par défaut) :

root@suse-server:~# head -5 /var/log/mail
2019-06-29T11:47:59.219806+02:00 suse-server postfix/postfix-script[1732]: the Postfix mail system is not running
2019-06-29T11:48:01.355361+02:00 suse-server postfix/postfix-script[1925]: starting the Postfix mail system
2019-06-29T11:48:01.391128+02:00 suse-server postfix/master[1930]: daemon started -- version 3.3.1, configuration /etc/postfix
2019-06-29T11:55:39.247462+02:00 suse-server postfix/postfix-script[3364]: stopping the Postfix mail system
2019-06-29T11:55:39.249375+02:00 suse-server postfix/master[1930]: terminating on signal 15

grep

Outil de filtrage qui permet de rechercher des chaînes de caractères données :

root@debian:~# grep "dhclient" /var/log/syslog
Sep 13 11:58:48 debian dhclient[448]: DHCPREQUEST of 192.168.1.4 on enp0s3 to 192.168.1.1 port 67
Sep 13 11:58:49 debian dhclient[448]: DHCPACK of 192.168.1.4 from 192.168.1.1
Sep 13 11:58:49 debian dhclient[448]: bound to 192.168.1.4 -- renewal in 1368 seconds.
(...)

Comme vous l’aurez remarqué, le résultat s’affiche dans le format suivant :

Horodatage
Nom d’hôte à l’origine du message
Nom du programme/service qui a généré le message
Le PID du programme qui a généré le message
Description de l’action qui a eu lieu

Dans certains cas de figure, les fichiers de journalisation ne sont pas du texte, mais des fichiers binaires et — par conséquent — il vous faut utiliser des commandes spécifiques pour les analyser :

/var/log/wtmp

Utilisez who (ou w):

root@debian:~# who
root    pts/0        2020-09-14 13:05 (192.168.1.75)
root    pts/1        2020-09-14 13:43 (192.168.1.75)

/var/log/btmp

Utilisez utmpdump ou last -f:

root@debian:~# utmpdump /var/log/btmp
Utmp dump of /var/log/btmp
[6] [01287] [    ] [dave     ] [ssh:notty   ] [192.168.1.75        ] [192.168.1.75   ] [2019-09-07T19:33:32,000000+0000]

/var/log/faillog

Utilisez faillog:

root@debian:~# faillog -a | less
Login       Failures Maximum Latest                   On

root            0        0   01/01/70 01:00:00 +0100
daemon          0        0   01/01/70 01:00:00 +0100
bin             0        0   01/01/70 01:00:00 +0100
sys             0        0   01/01/70 01:00:00 +0100
sync            0        0   01/01/70 01:00:00 +0100
games           0        0   01/01/70 01:00:00 +0100
man             0        0   01/01/70 01:00:00 +0100
lp              0        0   01/01/70 01:00:00 +0100
mail            0        0   01/01/70 01:00:00 +0100
(...)

/var/log/lastlog

Utilisez lastlog:

root@debian:~# lastlog | less
Username         Port     From             Latest
root                                       Never logged in
daemon                                     Never logged in
bin                                        Never logged in
sys                                        Never logged in
(...)
sync                                       Never logged in
avahi                                      Never logged in
colord                                     Never logged in
saned                                      Never logged in
hplip                                      Never logged in
carol            pts/1    192.168.1.75     Sat Sep 14 13:43:06 +0200 2019
dave             pts/3    192.168.1.75     Mon Sep  2 14:22:08 +0200 2019

Note	Il existe également des outils graphiques pour lire les fichiers de journalisation, par exemple : `gnome-logs` et `KSystemLog`.

Comment les messages deviennent des journaux

Voici comment un message est écrit dans un fichier de journalisation :

Les applications, les services et le noyau écrivent leurs messages dans des fichiers spéciaux (sockets et mémoires tampons) comme /dev/log ou /dev/kmsg.
rsyslogd récupère les informations depuis les sockets ou les mémoires tampons.
En fonction des règles trouvées dans /etc/rsyslog.conf et/ou les fichiers dans /etc/ryslog.d/, rsyslogd déplace les informations vers les fichiers de journalisation correspondants (que l’on trouve généralement dans /var/log).

Note	Un socket est un fichier spécial qui permet de transférer des informations entre différents processus. Pour afficher la liste de tous les sockets de votre système, vous pouvez utiliser la commande `systemctl list-sockets --all`.

Ressources, priorités et actions

Le fichier de configuration de rsyslog est /etc/rsylog.conf (dans certaines distributions, vous trouverez également des fichiers de configuration dans /etc/rsyslog.d/). En général, il est organisé en trois sections : MODULES, GLOBAL DIRECTIVES et RULES. Jetons-y un œil et examinons le fichier rsyslog.conf de notre hôte Debian GNU/Linux 10 (buster) - vous pouvez utiliser sudo less /etc/rsyslog.conf pour le faire.

MODULES inclut le support des modules pour la journalisation, le traitement des messages et la réception UDP/TCP des journaux :

#################
#### MODULES ####
#################

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

GLOBAL DIRECTIVES nous permet de configurer un certain nombre de choses comme les permissions des fichiers et des répertoires de journalisation :

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

RULES est l’endroit où les ressources, les priorités et les actions entrent en jeu. Les paramètres de cette section indiquent au démon de journalisation de filtrer les messages en fonction de certaines règles et de les enregistrer ou de les envoyer là où c’est nécessaire. Pour comprendre ces règles, nous devons d’abord expliquer les concepts de ressources et de priorités propres à rsyslog. Chaque message de journalisation est doté d’un numéro de ressource et d’un mot-clé associés au sous-système interne de Linux qui génère le message :

Numéro Mot clé Description

0

kern

Messages du noyau Linux

1

user

Messages au niveau utilisateur

2

mail

Système de messagerie

3

daemon

Démons du système

4

auth, authpriv

Messages relatifs à la sécurité et à l’autorisation

5

syslog

Messages syslogd

6

lpr

Sous-système d’impression

7

news

Sous-système de news en réseau

8

uucp

Sous-système UUCP (Unix-to-Unix Copy Protocol)

9

cron

Démon de l’horloge

10

auth, authpriv

Messages relatifs à la sécurité et à l’autorisation

11

ftp

Démon FTP (File Transfer Protocol)

12

ntp

Démon NTP (Network Time Protocol)

13

security

Audit du journal

14

console

Alerte du journal

15

cron

Démon de l’horloge

16 - 23

local0 à local7

Utilisation locale 0 - 7

Par ailleurs, chaque message est associé à un niveau de priorité :

Numéro Sévérité Mot clé Description

0

Urgence

emerg, panic

Système inutilisable

1

Alerte

alert

Action immédiate requise

2

Critique

crit

Conditions critiques

3

Erreur

err, error

Conditions d’erreur

4

Avertissement

warn, warning

Conditions d’avertissement

5

Avis

notice

État normal mais significatif

6

Information

info

Messages à titre d’information

7

Débogage

debug

Messages de débogage

Voici un extrait de rsyslog.conf de notre système Debian GNU/Linux 10 (buster) avec quelques exemples de règles :

###############
#### RULES ####
###############

# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

#
# Some "catch-all" log files.
#
*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none          -/var/log/messages

Le format des règles est défini comme ceci : <ressource>.<priorité> <action>

Le sélecteur <ressource>.<priorité> filtre les messages à faire correspondre. Les niveaux de priorité sont hiérarchiquement inclusifs, ce qui signifie que rsyslog va faire correspondre les messages du niveau de priorité spécifié et plus. L’élément <action> indique l’action à entreprendre (où envoyer le message). Voici quelques exemples pour plus de clarté :

auth,authpriv.*                 /var/log/auth.log

Peu importe leur priorité (*), tous les messages provenant des ressources auth ou authpriv seront envoyés vers /var/log/auth.log.

*.*;auth,authpriv.none          -/var/log/syslog

Tous les messages — indépendamment de leur priorité (*) — de toutes les ressources (*) — sans tenir compte de ceux de auth ou authpriv (d’où le suffixe .none) — seront envoyés vers /var/log/syslog (le signe moins (-) avant le chemin évite les écritures excessives sur le disque). Notez le point-virgule (;) pour séparer le sélecteur et la virgule (,) pour concaténer deux ressources dans la même règle (auth,authpriv).

mail.err                        /var/log/mail.err

Les messages de la ressource mail avec un niveau de priorité error ou plus (critical, alert ou emergency) seront envoyés vers /var/log/mail.err.

*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug

Les messages en provenance de toutes les ressources avec la priorité debug et aucune autre (=) seront envoyés vers /var/log/debug — à l’exception de tous les messages en provenance des ressources auth, authpriv, news et mail (notez la syntaxe : ;\).

Entrées manuelles dans les journaux du système : `logger`

La commande logger est pratique pour les scripts shell ou pour les tests. logger enverra tout message reçu vers /var/log/syslog (ou vers /var/log/messages si l’enregistrement se fait sur un serveur central distant, comme nous allons le voir plus loin dans cette leçon) :

carol@debian:~$ logger this comment goes into "/var/log/syslog"

Pour afficher la dernière ligne dans /var/log/syslog, utilisez la commande tail avec l’option -1 :

root@debian:~# tail -1 /var/log/syslog
Sep 17 17:55:33 debian carol: this comment goes into /var/log/syslog

`rsyslog` comme serveur de journalisation centralisé

Pour expliquer ce sujet, nous allons ajouter un nouvel hôte à notre configuration. La voici :

Rôle Nom d’hôte OS Adresse IP

Serveur de journalisation centralisé

suse-server

openSUSE Leap 15.1

192.168.1.6

Client

debian

Debian GNU/Linux 10 (buster)

192.168.1.4

Commençons par configurer le serveur. Tout d’abord, nous allons nous assurer que rsyslog fonctionne :

root@suse-server:~# systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-17 18:45:58 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 832 (rsyslogd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─832 /usr/sbin/rsyslogd -n -iNONE

openSUSE comprend un fichier de configuration dédié à la journalisation à distance : /etc/rsyslog.d/remote.conf. Nous allons activer la réception des messages depuis les clients (hôtes distants) via TCP. Pour ce faire, nous devons décommenter les lignes qui chargent le module et qui démarrent le serveur TCP sur le port 514 :

# ######### Receiving Messages from Remote Hosts ##########
# TCP Syslog Server:
# provides TCP syslog reception and GSS-API (if compiled to support it)
$ModLoad imtcp.so  # load module
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
$InputTCPServerRun 514  # Starts a TCP server on selected port

# UDP Syslog Server:
#$ModLoad imudp.so  # provides UDP syslog reception
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
#$UDPServerRun 514  # start a UDP syslog server at standard port 514

Une fois que c’est fait, nous devons redémarrer le service rsyslog et vérifier que le serveur écoute sur le port 514 :

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# netstat -nltp | grep 514
[sudo] password for root:
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      2263/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      2263/rsyslogd

Ensuite, nous devons ouvrir les ports dans le pare-feu et recharger la configuration :

root@suse-server:~# firewall-cmd --permanent --add-port 514/tcp
success
root@suse-server:~# firewall-cmd --reload
success

Note	Avec l’avènement d’openSUSE Leap 15.0, `firewalld` a remplacé complètement le classique `SuSEFirewall2`.

Modèles et conditions de filtrage

Par défaut, les journaux du client sont envoyés vers le fichier /var/log/messages du serveur — avec ceux du serveur lui-même. Or, nous allons créer un modèle et une condition de filtrage pour que les journaux de nos clients soient stockés dans des répertoires séparés qui leur sont propres. Pour ce faire, nous allons ajouter ce qui suit à /etc/rsyslog.conf (ou /etc/rsyslog.d/remote.conf) :

$template RemoteLogs,"/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log"
if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
& stop

Modèle

Le modèle correspond à la première ligne et vous permet de spécifier un format pour les noms de journaux en utilisant la génération dynamique de noms de fichiers. Un modèle est constitué de :

Directive du modèle ($template)
Nom du modèle (RemoteLogs)
Texte du modèle ("/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log")
Options (optionnelles)

Notre modèle s’appelle RemoteLogs et son texte consiste en un chemin dans /var/log. Tous les journaux de notre hôte distant iront dans le répertoire remotehosts, où un sous-répertoire sera créé en fonction du nom d’hôte de la machine (%HOSTNAME%). Chaque nom de fichier dans ce répertoire sera composé de la date (%$NOW%), de la sévérité (ou priorité) du message au format texte (%syslogseverity-text%) et du suffixe .log. Les mots entre les signes de pourcentage sont des propriétés et vous permettent d’accéder au contenu du message (date, priorité, etc.). Un message syslog a un certain nombre de propriétés bien définies qui peuvent être utilisées dans les modèles. Ces propriétés sont accessibles — et peuvent être modifiées — par ce que l’on appelle le remplaçant de propriétés qui consiste à les écrire entre des signes de pourcentages.

Condition de filtrage

Les deux lignes restantes correspondent à la condition de filtrage et à l’action associée :

Filtre basé sur une expression (if $FROMHOST-IP=='192.168.1.4')
Action (then ?RemoteLogs, & stop)

La première ligne vérifie l’adresse IP de l’hôte distant qui envoie le journal et — si elle est égale à celle de notre client Debian — elle applique le modèle RemoteLogs. La dernière ligne (& stop) assure que les messages ne sont pas envoyés simultanément à /var/log/messages (mais seulement vers les fichiers du répertoire /var/log/remotehosts).

Note	Pour en savoir plus sur les modèles, les propriétés et les règles, vous pouvez consulter la page de manuel de `rsyslog.conf`.

Avec la configuration mise à jour, nous allons redémarrer rsyslog et vérifier qu’il n’y a pas encore de répertoire remotehosts dans /var/log :

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# ls /var/log/
acpid             chrony     localmessages   pbl.log          Xorg.0.log
alternatives.log  cups       mail            pk_backend_zypp  Xorg.0.log.old
apparmor          firebird   mail.err        samba            YaST2
audit             firewall   mail.info       snapper.log      zypp
boot.log          firewalld  mail.warn       tallylog         zypper.log
boot.msg          krb5       messages        tuned
boot.omsg         lastlog    mysql           warn
btmp              lightdm    NetworkManager  wtmp

Le serveur est maintenant configuré. À présent, nous allons configurer le client.

Là aussi, nous devons nous assurer que rsyslog est installé et fonctionne :

root@debian:~# sudo systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset:
   Active: active (running) since Thu 2019-09-17 18:47:54 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 351 (rsyslogd)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─351 /usr/sbin/rsyslogd -n

Dans notre environnement de test, nous avons intégré la résolution de noms sur le client en ajoutant la ligne 192.168.1.6 suse-server à /etc/hosts. Ainsi, nous pouvons nous référer au serveur soit par son nom (suse-server) soit par son adresse IP (192.168.1.6).

Notre client Debian n’a pas de fichier remote.conf dans /etc/rsyslog.d/, nous appliquerons donc nos configurations dans /etc/rsyslog.conf. Nous écrirons la ligne suivante à la fin du fichier :

*.* @@suse-server:514

Enfin, nous redémarrons rsyslog.

root@debian:~# systemctl restart rsyslog

Maintenant, revenons à notre machine suse-server et vérifions l’existence de remotehosts dans /var/log :

root@suse-server:~# ls /var/log/remotehosts/debian/
2019-09-17.info.log  2019-09-17.notice.log

Nous avons déjà deux logs dans /var/log/remotehosts comme décrit dans notre modèle. Pour terminer cette partie, nous lançons tail -f 2019-09-17.notice.log sur suse-server pendant que nous envoyons manuellement un journal depuis notre client Debian pour confirmer que les messages sont ajoutés au fichier de journalisation comme prévu (l’option -t fournit une balise pour notre message) :

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)

carol@debian:~$ logger -t DEBIAN-CLIENT Hi from 192.168.1.4

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)
2019-09-17T21:04:21+02:00 debian DEBIAN-CLIENT: Hi from 192.168.1.4

Mécanisme de rotation des journaux

Les fichiers de journalisation font l’objet d’une rotation régulière, pour deux raisons principalement :

Empêcher les anciens fichiers de journalisation d’utiliser plus d’espace disque que nécessaire.
Les journaux doivent garder une taille raisonnable pour faciliter leur consultation.

L’outil en charge de la rotation (ou du cyclage) des journaux est logrotate et son rôle comprend des actions comme le renommage des fichiers de journalisation, leur archivage et/ou leur compression, leur envoi par émail à l’administrateur du système et finalement leur suppression au fur et à mesure qu’ils vieillissent. Il existe plusieurs conventions pour nommer ces fichiers de journalisation pivotés (en ajoutant un suffixe avec la date au nom du fichier, par exemple) ; cependant, l’ajout d’un suffixe avec un nombre entier est la pratique courante :

root@debian:~# ls /var/log/messages*
/var/log/messages  /var/log/messages.1  /var/log/messages.2.gz  /var/log/messages.3.gz  /var/log/messages.4.gz

Voyons maintenant ce qui va se passer lors de la prochaine rotation des journaux :

messages.4.gz sera supprimé et perdu.
Le contenu de messages.3.gz sera déplacé vers messages.4.gz.
Le contenu de messages.2.gz sera déplacé vers messages.3.gz.
Le contenu de messages.1 sera déplacé vers messages.2.gz.
Le contenu de messages sera déplacé vers messages.1 et messages sera vide et prêt à enregistrer de nouvelles entrées du journal.

Notez comment — selon les directives logrotate que vous verrez bientôt — les trois fichiers logs les plus anciens sont compressés, alors que les deux plus récents ne le sont pas. Par ailleurs, nous conservons les logs des 4 à 5 dernières semaines. Pour lire les messages datant de la semaine dernière, nous consulterons messages.1 (et ainsi de suite).

logrotate est exécuté quotidiennement comme une tâche automatique ou un cronjob à travers le script /etc/cron.daily/logrotate et lit le fichier de configuration /etc/logrotate.conf. Ce fichier inclut quelques options globales et il est bien commenté, chaque option étant introduite par une brève explication de son utilité :

carol@debian:~$ sudo less /etc/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

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

(...)

Comme vous pouvez le voir, les fichiers de configuration dans /etc/logrotate.d pour des paquets spécifiques sont également inclus. Ces fichiers contiennent — pour la plupart — des définitions locales et spécifient les fichiers de journalisation à faire tourner (rappelez-vous que les définitions locales sont prioritaires par rapport aux définitions globales et que les définitions ultérieures ont la priorité sur les précédentes). Ce qui suit est un extrait d’une définition dans /etc/logrotate.d/rsyslog :

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

Comme vous pouvez le voir, chaque directive est séparée de sa valeur par un espace et/ou un signe égal optionnel (=). Les lignes entre postrotate et endscript doivent cependant apparaître sur des lignes séparées. Voici une explication :

rotate 4: Conserver les journaux des 4 dernières semaines.
weekly: Effectuer une rotation hebdomadaire des fichiers de journalisation.
missingok: Ne pas afficher de message d’erreur si le fichier de journalisation est manquant et passer au suivant.
notifempty: Ne pas faire tourner le fichier de journalisation s’il est vide.
compress: Compresser les fichiers de journalisation avec gzip (par défaut).
delaycompress: Reporte la compression du fichier de journalisation précédent au prochain cycle de rotation (efficace uniquement en combinaison avec compress). C’est utile lorsqu’on ne peut pas demander à un programme de fermer son fichier de journalisation et qu’il peut donc continuer à écrire dans le fichier de journalisation précédent pendant un certain temps.
sharedscripts: Lié aux scripts prerotate et postrotate. Pour éviter qu’un script ne soit exécuté plusieurs fois, lancez les scripts une seule fois, quel que soit le nombre de fichiers de journalisation qui correspondent à un motif donné (par exemple /var/log/mail/*). De plus, si les scripts se terminent avec des erreurs, les actions restantes ne seront pas exécutées pour tous les fichiers de journalisation.
postrotate: Indique le début d’un script postrotate.
invoke-rc.d rsyslog rotate > /dev/null: Utiliser /bin/sh pour lancer invoke-rc.d rsyslog rotate > /dev/null après la rotation des fichiers de journalisation.
endscript: Indique la fin du script postrotate.

Note	Pour la liste complète des directives et des explications, consultez la page de manuel de `logrotate.conf`.

La mémoire tampon circulaire du noyau

Puisque le noyau génère plusieurs messages avant que rsyslogd ne devienne disponible au démarrage, un mécanisme pour enregistrer ces messages devient nécessaire. C’est là que la mémoire tampon circulaire du noyau (kernel ring buffer) entre en jeu. C’est une structure de données de taille fixe et — par conséquent — au fur et à mesure qu’elle se remplit de nouveaux messages, les plus anciens disparaissent.

La commande dmesg affiche la mémoire tampon circulaire du noyau. En raison de la taille du tampon, cette commande est normalement utilisée en combinaison avec l’outil de filtrage de texte grep. Par exemple, pour rechercher les messages relatifs aux périphériques USB :

root@debian:~# dmesg | grep "usb"
[    1.241182] usbcore: registered new interface driver usbfs
[    1.241188] usbcore: registered new interface driver hub
[    1.250968] usbcore: registered new device driver usb
[    1.339754] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.19
[    1.339756] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
(...)

Exercices guidés

Quels outils/commandes utiliseriez-vous dans ces cas de figure :

Objectif et fichier de journalisation Outil

Lire /var/log/syslog.7.gz

Lire /var/log/syslog

Chercher le mot renewal dans /var/log/syslog

Lire /var/log/faillog

Lire /var/log/syslog dynamiquement

Réorganiser les entrées de journal suivantes de manière à ce qu’elles représentent un message de journal valide avec la structure appropriée :
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  La séquence correcte est :
Quelles règles ajouteriez-vous à /etc/rsyslog.conf afin d’accomplir chacune des actions ci-dessous :
- Envoyer tous les messages en provenance de la ressource mail avec un niveau de priorité/sévérité crit (et plus) vers /var/log/mail.crit :
- Envoyer tous les messages en provenance de la ressource mail avec les niveaux de priorité alert et emergency vers /var/log/mail.urgent :
- À l’exception de ceux en provenance des ressources cron et ntp, envoyer tous les messages — indépendamment de leur ressource et de leur niveau de priorité — vers /var/log/allmessages :
- Une fois que tous les paramètres requis sont correctement configurés, envoyer tous les messages de la ressource mail vers un hôte distant dont l’adresse IP est 192.168.1.88 en utilisant TCP et en spécifiant le port par défaut :
- Indépendamment de leur ressource, envoyer tous les messages avec un niveau de priorité warning (uniquement avec la priorité warning`) vers `/var/log/warnings de manière à éviter des écritures excessives sur le disque :

Examinez cette stance de /etc/logrotate.d/samba et expliquez les différentes options :

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Option Signification

weekly

missingok

rotate 7

postrotate

endscript

compress

delaycompress

notifyempty

Exercices d’approfondissement

Dans la section “Modèles et conditions de filtrage” nous avons utilisé un filtre basé sur une expression comme condition de filtrage. Les filtres basés sur les propriétés sont un autre type de filtre propre à rsyslogd. Traduisez notre filtre basé sur une expression en un filtre basé sur une propriété :

Filtre basé sur une expression Filtre basé sur une propriété

if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
omusrmsg est un module intégré à rsyslog qui facilite les notifications aux utilisateurs (il envoie des messages de journalisation dans le terminal des utilisateurs). Écrivez une règle pour envoyer tous les messages d’urgence de toutes les ressources à la fois vers root et vers l’utilisateur normal carol.

Résumé

Voici ce que nous avons appris dans cette leçon :

La journalisation est essentielle pour l’administration système.
rsyslogd est l’outil chargé de garder les journaux propres et bien organisés.
Certains services gèrent leurs propres journaux.
En gros, les journaux peuvent être classés en journaux système et en journaux de services ou de programmes.
Il existe un certain nombre d’outils pratiques pour la lecture des journaux : less, more, zless, zmore, grep, head et tail.
La plupart des journaux sont des fichiers au format texte simple, mais il existe un petit nombre de journaux au format binaire.
Pour ce qui est des journaux, rsyslogd reçoit les informations pertinentes via des fichiers spéciaux (sockets et mémoires tampon) avant de les traiter.
Pour catégoriser les journaux, rsyslogd utilise les règles dans /etc/rsyslog.conf ou /etc/rsyslog.d/*.
Tout utilisateur peut écrire manuellement ses propres messages dans les journaux du système à l’aide de l’outil logger.
rsyslog vous permet de conserver tous les journaux à travers des réseaux IP dans un serveur de journaux centralisé.
Les Modèles sont très utiles pour formater les noms des fichiers de journalisation de manière dynamique.
La rotation des journaux se fait pour deux raisons : empêcher les anciens journaux d’utiliser un espace disque excessif et rendre la consultation des journaux plus facile à gérer.

Réponses aux exercices guidés

Quels outils/commandes utiliseriez-vous dans ces cas de figure :

Objectif et fichier de journalisation Outil

Lire /var/log/syslog.7.gz

zmore ou zless

Lire /var/log/syslog

more ou less

Chercher le mot renewal dans /var/log/syslog

grep

Lire /var/log/faillog

faillog -a

Lire /var/log/syslog dynamiquement

tail -f

Réorganiser les entrées de journal suivantes de manière à ce qu’elles représentent un message de journal valide avec la structure appropriée :
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  La séquence correcte est :
  Sep 13 21:47:56 debian-server sshd[515]: Server listening on 0.0.0.0 port 22
Quelles règles ajouteriez-vous à /etc/rsyslog.conf afin d’accomplir chacune des actions ci-dessous :
- Envoyer tous les messages en provenance de la ressource mail avec un niveau de priorité/sévérité crit (et plus) vers /var/log/mail.crit :
  mail.crit /var/log/mail.crit
- Envoyer tous les messages en provenance de la ressource mail avec les niveaux de priorité alert et emergency vers /var/log/mail.urgent :
  mail.alert /var/log/mail.urgent
- À l’exception de ceux en provenance des ressources cron et ntp, envoyer tous les messages — indépendamment de leur ressource et de leur niveau de priorité — vers /var/log/allmessages :
  *.*;cron.none;ntp.none /var/log/allmessages
- Une fois que tous les paramètres requis sont correctement configurés, envoyer tous les messages de la ressource mail vers un hôte distant dont l’adresse IP est 192.168.1.88 en utilisant TCP et en spécifiant le port par défaut :
  mail.* @@192.168.1.88:514
- Indépendamment de leur ressource, envoyer tous les messages avec un niveau de priorité warning (uniquement avec la priorité warning`) vers `/var/log/warnings de manière à éviter des écritures excessives sur le disque :
  *.=warning -/var/log/warnings

Examinez cette stance de /etc/logrotate.d/samba et expliquez les différentes options :

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Option Signification

weekly

Effectuer une rotation hebdomadaire des fichiers de journalisation.

missingok

Ne pas afficher de message d’erreur si le fichier de journalisation est manquant et passer au suivant.

rotate 7

Conserver les journaux des 7 dernières semaines.