Imaginez ce que serait la vie si un service critique s’était effondré il y a quelques minutes, et que vous étiez appelé pour sauver la journée. Vous tentez de redémarrer le service, et il ne veut tout simplement pas donner. Il n’y a pas de messages d’erreur, mais surtout, aucune trace de ce qu’il faisait avant de décider de mourir. Cent et une causes traversent votre esprit, et vous réalisez qu’il n’y a aucun moyen de savoir dans quelle direction aller. Peut-être pourriez-vous redémarrer le serveur tout simplement. Juste peut-être.
Ce scénario est l’un des nombreux dans lesquels la journalisation peut venir à votre secours. Habituellement, un logiciel en cours d’exécution conserve un enregistrement des activités importantes liées à son fonctionnement pour la postérité dans un fichier. Tout peut être conservé dans un fichier journal, car il aide les développeurs et les administrateurs système à savoir ce qui s’est passé avec un logiciel particulier après coup. Les fichiers journaux sont également utilisés par les personnes chargées de la sécurité pour contrôler l’accès à certaines ressources. Dans le domaine des réseaux ou de la messagerie, les fichiers journaux enregistrent l’heure à laquelle les messages ont été envoyés ou reçus pour une consultation ultérieure.
Les fichiers journaux, par définition, ne cessent d’augmenter en taille en fonction de la fréquence et de la verbosité avec lesquelles ils sont mis à jour. Pour servir leur objectif, ils sont normalement ouverts en mode append et contiennent des horodatages pour aider au dépannage et à la médecine légale. Toutefois, cela pose un problème, car la taille importante des fichiers rend le travail sur les fichiers journaux fastidieux, tant pour le système que pour l’examinateur humain. Les journaux font l’objet d’une rotation pour que les fichiers journaux restent tenables. En d’autres termes, un nouveau fichier est ouvert tandis que l’ancien est fermé et conservé ou supprimé selon les préférences du concepteur. Cela empêche les journaux de remplir des partitions entières et de mettre les systèmes à genoux. Vous avez peut-être remarqué la rotation des journaux à l’œuvre sur un système voisin. Regardez les dates sur les fichiers boot.log.
Dans ce cas, lorsqu’une condition spécifique est remplie, le fichier actuel est renommé en ajoutant une date pour l’identifier et le suivre, et un nouveau fichier avec le nom original est ouvert, prêt à recevoir les messages de journal entrants.
La journalisation sous Linux (rsyslogd)
Comme vous pouvez vous y attendre, la journalisation dans les systèmes Linux, comme le serveur CentOS 7 que j’utilise pour l’illustration, repose sur un démon pour faciliter la journalisation. Rsyslogd est le nom de l’ancien service fiable et il est open-source. En fait, il n’est pas si vieux. Il s’agit d’une version améliorée du démon original syslog, et il possède la capacité de traiter et de transmettre rapidement les journaux à n’importe quel endroit d’un réseau IP. En dehors de syslog et rsyslog, il existe syslog-ng, qui est encore un autre démon de traitement des journaux. Le gestionnaire de logs par défaut dépend de la distro que l’on choisit. Rsyslog est présent par défaut dans de nombreuses distros basées sur Red Hat. Exécutez la commande suivante pour vérifier sa présence et sa version sur votre système :
rsyslogd -v
Comme c’est un démon, vous pouvez vérifier qu’il est actif en employant systemd comme suit :
systemctl status rsyslogd
Si, pour une raison quelconque, il n’est pas en cours d’exécution, vous pouvez le démarrer via systemd.
Logrotate
Logrotate est un utilitaire Linux dont la fonction principale est de – attendez la suite – faire tourner les journaux. S’il n’est pas installé dans le cadre de l’installation par défaut du système d’exploitation, il peut être installé simplement en exécutant :
yum install logrotateLe fichier binaire peut être situé à /bin/logrotate.
En installant logrotate, un nouveau fichier de configuration est placé dans le répertoire /etc/ pour contrôler le comportement général de l’utilitaire lors de son exécution. De plus, un dossier est créé pour les fichiers de configuration des snap-in spécifiques aux services pour les demandes de rotation des journaux sur mesure. Nous y reviendrons un peu plus tard.
Travail cron quotidien
Un cron travail est exécuté quotidiennement qui démarre l’utilitaire. Ceci est réalisé en plaçant un appel à l’utilitaire dans le dossier standard cron pour les travaux quotidiens. Bien que les spécificités de l’appel sortent du cadre de cet article, il suffit de dire que l’appel est juste un script Bash qui exécute le binaire logrotate, indiquant au système quoi faire en cas d’erreur.
L’emplacement standard du fichier journal
Les journaux sur un système Linux peuvent être placés partout où les permissions le permettent. Cependant, en raison du fait que leur taille et leur contenu changent continuellement, par définition, la hiérarchie du système de fichiers prescrit qu’ils soient conservés dans le répertoire /var/log/.
La capture d’écran ci-dessous est un aperçu du contenu de mon répertoire /var/log.
Fichiers de configuration et exemples
/etc/logrotate.conf
Le premier fichier à noter en ce qui concerne le fonctionnement de logrotate est logrotate.conf. Ce fichier de configuration contient les directives relatives à la rotation par défaut des fichiers journaux. S’il n’y a pas d’ensemble spécifique de directives, l’utilitaire agit en fonction des directives de ce fichier.
Vous trouverez ci-dessous un exemple du contenu du fichier de configuration.
Passons en revue quelques-unes des directives pour avoir une idée de la flexibilité de logrotate. Gracieusement, l’auteur de l’utilitaire a mis suffisamment de commentaires pour permettre à un néophyte de se lancer. Vous pouvez également consulter la page man pour une plongée plus profonde. Les directives weeklydateextcompresscreate, et rotate 4 indiquent que les fichiers journaux doivent être tournés chaque semaine, que la date de rotation doit être utilisée comme suffixe d’identification des fichiers tournés, que les fichiers tournés doivent être compressés, qu’un nouveau fichier doit être créé pour recevoir les journaux entrants et qu’il ne faut pas conserver plus de quatre journaux. En d’autres termes, le cinquième journal le plus récent doit être supprimé. Notez également que sur mon système, en raison de la présence de la directive # avant la directive compress, la compression est désactivée par défaut.
Aussi, il existe une directive pour inclure un dossier particulier : /etc/logrotate.d. Ce dossier est utilisé pour les demandes de rotation des journaux spécifiques au paquet. Les paquets conçus pour tirer parti de logrotate déposent des fichiers de configuration dans ce répertoire. Cette modularité est conforme à l’esprit Linux et améliore l’extensibilité de l’utilitaire. Les fichiers de configuration contiennent des directives similaires et des fichiers journaux personnalisés, le cas échéant. Vous pouvez également créer votre propre fichier de configuration pour gérer n’importe quel fichier journal de votre choix. Il suffit de donner un nom au fichier, d’ajouter le fichier journal à traiter et de le placer dans ce répertoire. Enfin, il existe des directives pour les fichiers journaux sans paquetage propriétaire, comme wtmp et d’autres fichiers journaux système. La page man est remplie de plus de directives, et pour les utilisateurs qui ont des besoins de rotation plus spécifiques, je vous conseille fortement d’y jeter un œil.
/etc/logrotate.d
Heureusement, j’ai considérablement parlé du répertoire /etc/logrotate.d, alors sans plus tarder, laissez-moi vous montrer le contenu de ce répertoire pour ramener les idées partagées précédemment à la maison.
Et juste pour faire bonne mesure, jetons un coup d’œil au fichier de configuration Samba.
Vous pouvez repérer à quel point il est similaire à logrotate.conf ? Avant de tirer les rideaux sur cette pièce, passons en revue certaines des directives de ce fichier :
/var/log/samba/* – Le fichier journal à faire tourner. Dans ce cas, il s’agit de chaque fichier journal dans le répertoire des journaux Samba.
notifempty – Directive indiquant que le fichier ne doit pas être tourné s’il est vide.
olddir /var/log/samba/old – Emplacement pour stocker les anciens journaux tournés.
missingok – Empêche logrotate de lancer une erreur si le fichier journal est manquant.
copytruncate – Ne fermez pas le fichier journal. Faites une copie, qui sera le fichier tourné et renommé, puis tronquez le fichier journal à une taille nulle
Vous pouvez deviner ce que fait la directive sharedscripts ? Pas besoin de deviner – consultez la page man.
Enveloppez-vous