Un runtime VPN en RAM ne dit rien des journaux

Un serveur VPN démarré depuis une image en lecture seule et dont l'état d'exécution vit sur tmpfs est une conception réelle et utile. Il est aussi facile de la décrire comme sans journaux, ce que la conception n'établit pas. L'emplacement de stockage détermine où vit une copie ; la collecte et la conservation déterminent si un enregistrement existe, et un redémarrage n'affecte que la première. Séparer les deux, c'est toute la revue.

Commencez par lister chaque processus capable d'écrire un état : le démon, le service d'authentification, le journal, tout agent de supervision et les outils de gestion.

Stockage et collecte sont deux questions différentes

Chaque écrivain a sa propre destination et sa propre politique. Le démon VPN écrit des fichiers d'état, le backend d'authentification écrit les événements de compte, le journal collecte la sortie des services, et un agent de supervision expédie les métriques ailleurs, complètement. Une conception qui fait disparaître l'un de ces éléments au redémarrage n'a rien dit des trois autres. Suivez chaque écrivain jusqu'à sa destination et notez si cette destination se trouve seulement sur la machine.

Les fichiers propres à l'application, les diagnostics téléversés et les services externes demandent le même traitement. L'absence d'un journal local familier ne prouve pas que des enregistrements de connexion ou de compte n'existent nulle part ; elle prouve que vous n'avez pas encore trouvé où ils vont.

tmpfs n'est pas une garantie

Linux tmpfs n'est pas un disque RAM physique. La documentation du noyau indique explicitement que des pages peuvent être écrites dans le swap quand le montage l'autorise, si bien qu'un fichier tmpfs peut atteindre un disque sans que l'application l'y copie jamais. mount montre si un tmpfs adossé au swap est en jeu, et les autres systèmes de fichiers en mémoire se comportent encore autrement. Lisez les options de montage réelles au lieu de supposer qu'un chemin sous /run implique la volatilité.

Inventoriez ensuite les choses qui survivent à un redémarrage d'une manière que les gens oublient : une couche supérieure persistante, du stockage attaché, des images d'hibernation, des vidages de plantage et des instantanés d'infrastructure de la VM entière. Chacune est une destination candidate pour un état que vous croyiez éphémère. Cette liste est à vérifier, ce n'est pas l'affirmation que chaque hôte les possède toutes.

Journald a deux destinations et un transféreur

Journald illustre bien la séparation. Le stockage volatil garde les entrées sous /run/log/journal, le stockage persistant sous /var/log/journal, et le mode automatique choisit entre les deux ; le mode en vigueur vient du système en cours d'exécution et non de la description de l'image. Passer en volatil n'efface pas ce qui a déjà été écrit de façon persistante. Le transfert est aussi un canal distinct : même un réglage de stockage qui ne garde rien localement peut remettre des messages à une autre cible.

Lisez le mode effectif dans le journal lui-même ou son fichier de configuration, puis vérifiez séparément les cibles de transfert, car un réglage ne contrôle pas l'autre.

Ce qui doit survivre à un redémarrage

Un runtime sans état permet un remplacement reproductible, et il exige des sources délibérées pour la configuration, l'autorisation et le matériel de récupération que le service ne peut pas inventer. Perdre le seul état d'enrôlement ou de révocation qui fonctionne pour faire disparaître les écritures locales est un mauvais échange, et courant. Décidez de ce qui doit survivre volontairement, puis vérifiez que c'est le cas.

Le même raisonnement s'applique aux enregistrements d'exploitation. Décidez quels événements la sécurité et la gestion du service exigent réellement, avec une portée et une conservation justifiées, et réduisez le reste au minimum. Minimiser n'est pas la même chose que désactiver chaque diagnostic.

Comparez la configuration effective de stockage et de transfert à quelques événements inoffensifs, puis redémarrez ou remplacez la machine et vérifiez à nouveau ce qui est resté et d'où le service a récupéré son état.