À qui appartiennent les journaux OpenVPN : au démon, à rsyslog ou à logrotate ?

La rotation des journaux casse de manière prévisible : trois composants croient chacun posséder le fichier, et le résultat est un journal rotationné qui continue de grossir alors que le nouveau reste vide. Le démon garde un descripteur, logrotate renomme le chemin et rsyslog écrit ailleurs. Choisissez un écrivain et un rotateur avant d'ajouter une règle de plus à la pile. La liste de contrôle ci-dessous suit cet ordre, car chaque étape ultérieure en dépend.

Décidez qui écrit le fichier

Deux conceptions sont légitimes. Dans la première, le processus VPN écrit lui-même un fichier via sa propre option log ou log-append. Dans la seconde, il envoie les enregistrements au journal système et rsyslog ou journald décide où ils atterrissent.

Ce sont des alternatives, pas des couches. Un hôte qui active les deux finit avec deux fichiers qui se contredisent, et celui que vous lisez est souvent le plus ancien. Choisissez le chemin délibérément, puis supprimez l'autre écrivain.

Lisez la configuration effective du service avant de changer quoi que ce soit, y compris les fichiers drop-in qui peuvent remplacer le fichier d'unité. Une directive présente dans le profil que vous avez modifié ne prouve pas qu'elle est celle que le processus en cours a chargée. Comparez l'unité avec les arguments du processus, puis avec les fichiers qu'il a réellement ouverts.

Nommez le démon pour que le filtre soit étroit

Sur le chemin syslog, donnez au démon une identité distincte et filtrez dessus. Une règle qui correspond au nom de programme de cette instance VPN garde ses enregistrements hors d'un fichier partagé dont la politique de rétention appartient à autre chose.

Les règles étroites permettent aussi de répondre à la question suivante : quel service a produit cette ligne ? Un filtre qui correspond à tout ce qui contient le mot VPN collectera volontiers le trafic d'un second tunnel et brouillera les deux. Correspondez à l'identifiant exact que l'unité transmet au journal.

Fermez la règle après l'action pour que les enregistrements ne tombent pas aussi dans la destination par défaut. Des lignes en double dans deux fichiers ressemblent à un bug de journalisation et sont en réalité un arrêt manquant. Cette unique omission double aussi le coût disque de la politique de rétention.

Faites tourner sans perdre le descripteur

Quand le démon écrit le fichier, logrotate renomme le chemin mais le processus garde son descripteur ouvert. Les nouveaux enregistrements continuent dans le fichier renommé jusqu'à ce que quelque chose oblige le processus à rouvrir le chemin d'origine ; c'est pourquoi une rotation peut sembler fonctionner alors que le nouveau fichier reste vide.

La solution est une action postrotate qui déclenche le comportement documenté de rechargement ou de redémarrage du service. Envoyer un signal au journal est une action entièrement différente et ne fait rien pour un démon qui détient son propre fichier.

Là où la réouverture est impossible, copytruncate est le recours : copiez le fichier, puis tronquez-le sur place. Il garde le descripteur valide au prix de la perte de tout ce qui est écrit entre la copie et la troncature, c'est donc un compromis et non une solution. Sous charge, cet écart peut avaler précisément la panne que vous cherchez à capturer.

Choisissez l'une des deux par fichier et consignez le choix, car les mélanger sur le même chemin produit des écarts très difficiles à attribuer ensuite. Un lecteur qui trouve les deux modèles dans un même répertoire ne peut pas dire lequel fait autorité.

Fixez la rétention d'après la fenêtre de l'incident

La rétention, la compression et la taille maximale devraient découler de la profondeur réelle de vos investigations. Une fenêtre de sept jours avec compression et plafond de taille est un point de départ raisonnable pour beaucoup de déploiements ; un nombre copié d'un tutoriel ne l'est pas.

Gardez la politique en un seul endroit. Si logrotate fait tourner le fichier et que rsyslog le fait aussi tourner, la seconde rotation gagne et le schéma de nommage de la première survit comme encombrement. Choisissez le propriétaire, désactivez l'autre rotation et notez cette décision à côté de la politique.

La documentation de rsyslog couvre son modèle de routage et d'actions, tandis que la documentation du service OpenVPN reste la référence pour les options de journalisation du démon lui-même. Aucune des deux ne décide de votre politique de rétention à votre place.

Testez une rotation et un événement neuf

Forcez une rotation unique puis générez un événement neuf, comme une authentification échouée. Confirmez que le nouvel enregistrement apparaît dans le nouveau fichier et que l'ancien a cessé de grossir.

Vérifiez aussi les permissions du nouveau fichier, car une rotation qui le recrée avec un autre propriétaire casse l'écrivain à l'écriture suivante et produit un écart qui ressemble à un plantage. Comparez le propriétaire et le mode avec le compte du service avant de partir. Confirmez ensuite que l'archive compressée est lisible, car une archive que personne ne peut ouvrir n'est pas de la rétention. Une lecture rapide du plus récent enregistrement de l'ancien fichier prouve à la fois la compression et les permissions.

Terminez en consignant le propriétaire de chaque étape : quel composant écrit, lequel fait tourner et où vit la politique de rétention. Cette note transforme le prochain incident de journalisation en vérification de cinq minutes au lieu d'un après-midi à deviner quelle couche a perdu la ligne.