GuiGui's Show

TL;DR : un serveur rsyslog sur Debian 5 qui ne consigne pas des pans entiers des journaux qu'il reçoit et qui kernel panic de temps en temps. Plusieurs hypothèses possibles. Aucune totalement convaincante. Solution : le remplacer par un serveur rsyslog Debian 11 fraîchement installé.

On avait un serveur syslog. Implémentation rsyslog sur Debian 5. Réception des journaux sur le protocole UDP. Les journaux étaient écrits dans un partage NFS sur notre NAS.

Quand j'en suis devenu l'un des administrateurs, ce serveur était peu utilisé : réception de flux syslog depuis nos deux contrôleurs Wi-Fi Aruba + depuis nos deux routeurs (journal NAT) + depuis notre VPN Cisco ASA. Avant, il recevait également des flux syslog en provenance de nos switchs (quel intérêt ? mon organisation a jamais mis en place de l'AAA) et de nos serveurs Debian 5/6/7 (journal de l'agent Puppet).

On peut donc supposer que ce service fonctionnait convenablement. Notamment parce que mon organisation a déjà eu à répondre à des réquisitions judiciaires (via le journal NAT), à des demandes semblables de la direction, et on relayait à nos utilisateurs les signalements extérieurs concernant leurs pratiques P2P.

Pourtant, depuis que je le connais, ce serveur de journalisation est capricieux. Parfois, il kernel panic. Parfois, il cesse de journaliser. On a donc des trous dans nos journaux (suffisants pour retirer toute pertinence à une recherche). Une recherche dans les journaux (avec grep) était si interminable qu'on les faisait depuis une autre machine qui montait le point de montage NFS. Tellement lent qu'on avait également déplacé les scripts de rangement / tri des journaux sur une autre machine.

Évidemment, on trouvait rien d'évident dans les journaux de la machine. Concernant la perte de bouts de journaux, il suffisait de redémarrer rsyslog et ça repartait temporairement. Évidemment, tcpdump montrait la réception des paquets rsyslog. Évidemment, aucune lenteur de notre NAS à signaler, monter le même partage NFS depuis une autre machine Debian 8 fonctionnait impec.

Afin de valider le bon fonctionnement d'un nouvel équipement qui doit envoyer ses journaux à notre serveur de journalisation, j'ai mis en place un deuxième rsyslog. Debian 5, lui aussi, mais tout propre (hors template). Les problèmes se sont immédiatement manifestés. Il ne s'agit donc pas de crasse accumulée avec le temps, d'erreurs humaines empilées au fil des années, etc.

On peut supposer que notre template Debian 5 contient une conf' vaseuse. Ou que la configuration matérielle de la machine virtuelle n'est pas OK (vu son âge, elle a été migrée d'hyperviseur en hyperviseur). Ou que la version de rsyslog peine à gérer notre faible volumétrie de flux rsyslog (j'y crois pas vu les usages antérieurs sus-mentionnés). Ou que la pile réseau de la machine n'est pas calibrée pour nos flux syslog (paramètres sysctl) ? Ou que l'implémentation NFS dans le noyau Linux est moins résiliente que celle d'aujourd'hui (on a des serveurs web Debian 4 donc peu crédible…). Ou que nos options de montage NFS sont vaseuses (on en a aucune, peut-être faudrait-il bidouiller rsize/wsize afin de forcer Linux à écrire plus ou moins souvent ?).

On a déjà eu des problèmes chelous avec de vieilles machines. Genre celui-ci, avec le suicide de la machine à la clé.

Au final, j'ai préféré monter un serveur rsyslog Debian 11. Ça permet de flinguer une machine Debian 5 qui, par définition, ne devrait plus être en prod' depuis fort longtemps (absence de support éditeur, absence de sécurité, difficultés de cohabitation avec le monde moderne, etc.). L'effort à fournir était négligeable car j'ai déjà écrit un module Puppet pour configurer rsyslog selon notre sauce interne. Le plus long aura été de convertir notre configuration à la nouvelle syntaxe de rsyslog, et de forcer la main au chef ("pas la priorité, blablabla").

Il fonctionne impec depuis plusieurs mois. Parfois, chercher une réponse n'est pas la solution la plus pertinente.

Au final, je ne saurai pas ce qui s'est passé… Les ninjas de l'informatique ne savent pas tout…