Voici un guide pratique pour l'installation de Logger, utilitaire de journalisation fonctionnant sous Linux, qui permet de prendre le contrôle des fichiers de journalisation. On est facilement submergé par les journaux système et la plupart du temps on préfère ne pas s'en occuper. Beaucoup d'utilisateurs ne savent tout bonnement pas quoi en faire ou comment les maintenir. La maintenance des journaux peut faire peur, en particulier si le planning de maintenance concerne également des applications de serveur Web ou de messagerie. Mon but ici est de fournir une méthodologie simple applicable par tout utilisateur de Linux.

Les programmes classiques tels que syslogd et klogd sont, pour le moins, vieux et dépassés pour la plupart des actuelles configurations système requises. Dans des cas extrêmes, ils peuvent être carrément dangereux. J'ai écrit Logger pour aborder ces problèmes et d'autres encore.

Commençons par décrire ces programmes classiques et ce qu'ils font exactement. Klogd, le démon de journalisation du noyau, est responsable de la collecte de tous les messages provenant du noyau et de leur transmission à syslogd, le démon de journalisation du système. Une question vient alors immédiatement à l'esprit : pourquoi deux processus différents ?

C'est une bonne question en effet. Le mode de pensée actuel est qu'il est plus simple et plus précis d'avoir un programme dédié à la journalisation des messages du noyau. C'est loin d'être absurde mais en même temps ça ne tient pas debout puisque klogd transmet simplement les messages à syslogd. Pour moi, ça revient à doubler le travail et le gaspillage de ressources. Ceci étant dit, jetons un coup d'œil à syslogd.

Comme mentionné précédemment, c'est le démon de journalisation du système. Il est responsable de la journalisation de tous les messages provenant de programmes tels que >bind, wuftp, proftp, ident, telnet, ainsi que de presque tous les pilotes gérant les espaces disque utilisateur, de beaucoup d'outils antispam, etc. La liste des programmes pour lequel syslogd intervient est très variée.

Avec un programme si important, on pourrait poser la question suivante : pourquoi réinventer la roue ou toucher à quelque chose qui n'est pas cassé ? Pour faire simple et bref, on répondra qu'il y a beaucoup de programmes actuels qui peuvent dégrader (sys|k)logd et qu'on ne peut accepter la moindre diminution de la performance du système. On peut vous donner deux très bonnes raisons de remplacer ces vénérables programmes : des fichiers limités à deux gigaoctets et l'envoi des journaux en texte brut.

Je fais tourner un petit serveur avec sept domaines. Chaque domaine a son propre serveur Web, e-mail, FTP et nom de domaine ainsi que son noyau de base et ses journaux système. Cela fait six journaux par machine avec un total de quarante-deux journaux différents que j'ai à maintenir quotidiennement. Je n'ai pas inclus le proxy, le cache, les journaux d'analyse du courrier électronique, et autre pour simplifier, mais ceux-ci sont caractéristiques de n'importe quel serveur normal. Avec tous ces journaux à traiter, où pourrais-je trouver le temps pour effectuer mes autres tâches administratives telles que répondre aux courriels ?

Il y a un autre problème que je n'ai pas encore abordé : les surcharges d'écriture dans les journaux peuvent pourrir même les serveurs les plus hauts de gamme, pouvant causer des tas de problèmes allant du sérieux ralentissement à l'arrêt total du serveur. Des journalisations disproportionnées peuvent aussi entrainer une surchauffe des disques durs et une usure plus rapide. J'ai moi-même vécu cela. Mon disque de journalisation tournait à la température incroyable de 52° avant que je n'utilise Logger. Maintenant, il est à la température confortable de 35° et je n'ai plus du tout de plantages serveurs causés par surchauffe. Les ordinateurs portables et fixes sont également touchés, mais à moindre mesure.

C'est la raison pour laquelle j'ai écrit Logger : pour prendre le contrôle de ce bazar et pour éviter à mon matériel ces pourrissages et ces problèmes de surchauffe. Donc, tout ça étant dit, passons à l'installation de Logger.

Le paquet Logger doit être installé sur votre disque dur. On peut le télécharger ici. Je vous recommande de placer l'archive de Logger dans la zone /usr/src par souci de commodité et de sécurité (rappelez-vous, écrire dans ce répertoire demande les permissions root).

L'archive tar Logger doit être décompressée dans un dossier nommé Logger et le chemin doit être changé pour pointer vers ce dossier :

mkdir /usr/src/Logger
mv Logger.tgz /usr/src/Logger
cd /usr/src/Logger
tar xvzf Logger.tgz

Logger doit ensuite être compilé en tapant :

./COMPILE

Si il ne se passe aucune erreur, les fichiers doivent être installés :

mv Logger /sbin
mv LogPipe /usr/local/bin

Nous allons maintenant écrire le fichier de configuration de Logger. C'est simplement un petit fichier texte nommé Logger.conf et il est enregistré dans le répertoire /etc. Le jeu d'instruction est assez simple et facile à utiliser. Voici un fichier Logger.conf de base qui marchera sur n'importe quelle machine (un exemple est inclus dans l'archive tar Logger).

Les lignes 1-3, 5 et 10 sont des commentaires. Toute ligne qui commence par un dièse (#) est un commentaire et est ignorée par Logger. Les lignes vides (4, 6, 9 et 11) sont aussi ignorées. En fait, la première instruction pour Logger est à la ligne 7.

La première instruction rencontrée par Logger est Queue. Voici en détail comment se décompose la ligne 7 :

Avec comme point de départ l'exemple d'au-dessus, nous allons maintenant ajouter un ordinateur portable. Ajoutez les deux lignes suivantes au fichier Logger.conf de l'ordinateur fixe (dans l'exemple ci-dessus) :

Logger devra maintenant être relancé. Les deux lignes du dessus disent à Logger de mettre en place des serveurs TCP sur les ports 3900 et 3901 où les données du système et du noyau seront donc reçues. Il est à noter qu'un nombre indéfini d'ordinateurs peut maintenant utiliser ce serveur de journaux. Veillez à bien configurer vos règles de pare-feu.

Passons maintenant aux configurations de Logger.conf de l'ordinateur portable (rappelez-vous que Logger doit être installé au préalable) :

10.0.100.0 est un exemple utilisé pour identifier les adresses IP de l'ordinateur fixe. Il faut que ce soit effectivement l'adresse IP de l'ordinateur fixe. Remarquez aussi que les ports dans l'exemple de l'ordinateur fixe correspondent en ordre et en séquence à ceux de l'ordinateur portable.

L'exemple ci-dessous est légèrement plus complexe :

Pour cet exemple, le diagramme ci-dessus servira de base pour notre petit réseau en partant du principe que :

Avec la configuration ci-dessus, voici les différents fichiers Logger.conf de chaque machine :

Pour Alpha, Beta et Delta :

Remarquez que Exim n'apparait pas ici et il n'a pas besoin d'apparaitre.

Pour Gamma :

Remarquez qu'Apache n'apparait pas ici et il n'a pas besoin d'apparaitre. Remarquez aussi que les trois journaux Exim sont fusionnés en un seul fichier. Chaque fichier Exim peut être enregistré séparément en appliquant une Queue à chacun d'eux.

Finalement, Omega :

Relancez Logger, Exim et Apache sur chaque machine et tous les journaux seront écrits sur la machine Omega. Un point important à noter : Logger doit être lancé d'abord sur Omega puis ensuite sur les autres machines. Relancez les applications telles qu'Apache et Exim en dernier.

Les exemples ci-dessus ne montrent qu'une petite partie de ce que Logger peut faire. Les applications/serveurs comme Apache, Exim, Sendmail, Postfix, Maildrop, Squid, Snort et autre (y compris n'importe quel programme Linux qui écrit des journaux en plein texte) peuvent profiter de Logger. Il peut être implanté tout aussi bien sur un simple ordinateur seul que dans une grande entreprise à l'organisation complexe pour fusionner tous ses journaux en un point de sécurité unique. La polyvalence et la souplesse de Logger peuvent ouvrir de manière significative les portes vers de nouvelles possibilités et vers une amélioration des performances sur n'importe quel système.