Un entorn d'execució VPN a la RAM no diu res sobre els registres

Un servidor VPN engegat des d'una imatge de només lectura amb el seu estat d'execució a tmpfs és un disseny real i útil. També és fàcil de descriure com a sense registres, cosa que el disseny no demostra. La ubicació d'emmagatzematge determina on viu una còpia; la recollida i la retenció determinen si un registre existeix, i un reinici només afecta la primera. Separar les dues coses és tota la revisió.

Comenceu enumerant cada procés que pot escriure estat: el dimoni, el servei d'autenticació, el registre del sistema, qualsevol agent de monitoratge i les eines de gestió.

Emmagatzematge i recollida són qüestions diferents

Cada escriptor té el seu destí i la seva política. El dimoni VPN escriu fitxers d'estat, el backend d'autenticació escriu esdeveniments del compte, el registre recull la sortida dels serveis i un agent de monitoratge envia les mètriques a un lloc completament diferent. Un disseny que fa desaparèixer un d'aquests en reiniciar no ha dit res dels altres tres. Seguiu cada escriptor fins al seu destí i noteu si aquest destí és al maquinari.

Els fitxers específics de l'aplicació, els diagnòstics pujats i els serveis externs necessiten el mateix tracte. L'absència d'un registre local conegut no demostra que no existeixin enlloc registres de connexions o comptes; demostra que encara no heu trobat on van.

tmpfs no és una garantia

Linux tmpfs no és un disc RAM físic. La documentació del nucli és explícita que les pàgines es poden escriure al swap quan el muntatge ho permet, així que un fitxer tmpfs pot arribar a un disc sense que l'aplicació mai l'hi copiï. mount mostra si hi ha un tmpfs recolzat en swap en joc, i altres sistemes de fitxers en memòria es comporten encara d'una altra manera. Llegiu les opcions reals de muntatge en lloc d'assumir que una ruta sota /run implica volatilitat.

Després feu inventari de les coses que sobreviuen a un reinici de maneres que la gent oblida: una capa superior persistent, emmagatzematge connectat, imatges d'hibernació, abocaments de fallades i instantànies d'infraestructura de tota la VM. Cadascuna és un destí candidat per a estat que creíeu efímer. Aquesta llista és una cosa a comprovar, no una afirmació que cada amfitrió les tingui totes.

Journald té dos destins i un reenviador

Journald il·lustra bé la divisió. L'emmagatzematge volàtil guarda les entrades a /run/log/journal, el persistent a /var/log/journal, i el mode automàtic tria entre tots dos; el mode vigent prové del sistema en execució, no de la descripció de la imatge. Canviar a volàtil no esborra el que ja s'havia escrit de manera persistent. El reenviament també és un canal a part: fins i tot una configuració d'emmagatzematge que no guarda res localment pot lliurar missatges a una altra destinació.

Llegiu el mode efectiu del mateix registre o del seu fitxer de configuració, i després comproveu les destinacions de reenviament per separat, perquè un paràmetre no controla l'altre.

Què ha de sobreviure a un reinici

Un entorn sense estat admet la substitució repetible, i necessita fonts deliberades per a la configuració, l'autorització i el material de recuperació que el servei no pot inventar. Perdre l'únic estat d'enrotllament o revocació que funciona per fer desaparèixer les escriptures locals és un mal intercanvi, i habitual. Decidiu què ha de sobreviure a propòsit i després verifiqueu que ho fa.

El mateix raonament s'aplica als registres operatius. Decidiu quins esdeveniments requereixen realment la seguretat i la gestió del servei, amb un abast i una retenció justificats, i minimitzeu la resta. Minimitzar no és el mateix que desactivar tots els diagnòstics.

Compareu la configuració efectiva d'emmagatzematge i reenviament amb uns quants esdeveniments innocus, reinicieu o substituïu la màquina i torneu a comprovar què hi quedava i d'on va recuperar l'estat el servei.