Un runtime VPN in RAM non dice nulla sui log

Un server VPN avviato da un'immagine di sola lettura con il suo stato di esecuzione su tmpfs è un progetto reale e utile. È anche facile descriverlo come privo di log, cosa che il progetto non dimostra. La posizione di archiviazione determina dove vive una copia; la raccolta e la conservazione determinano se un record esiste, e un riavvio influisce solo sulla prima. Separare le due cose è tutta la revisione.

Iniziate elencando ogni processo che può scrivere stato: il demone, il servizio di autenticazione, il journal, qualsiasi agente di monitoraggio e gli strumenti di gestione.

Archiviazione e raccolta sono domande diverse

Ogni scrittore ha la propria destinazione e la propria politica. Il demone VPN scrive file di stato, il backend di autenticazione scrive eventi dell'account, il journal raccoglie l'output dei servizi e un agente di monitoraggio spedisce le metriche altrove, del tutto. Un progetto che fa sparire uno di questi al riavvio non ha detto nulla sugli altri tre. Seguite ogni scrittore fino alla sua destinazione e annotate se quella destinazione è persino sulla macchina.

I file specifici dell'applicazione, la diagnostica caricata e i servizi esterni richiedono lo stesso trattamento. L'assenza di un log locale familiare non dimostra che i record di connessione o dell'account non esistano da nessuna parte; dimostra che non avete ancora trovato dove finiscono.

tmpfs non è una garanzia

Linux tmpfs non è un disco RAM fisico. La documentazione del kernel è esplicita sul fatto che le pagine possono essere scritte nello swap quando il montaggio lo consente, quindi un file tmpfs può raggiungere un disco senza che l'applicazione lo abbia mai copiato lì. mount mostra se è in gioco un tmpfs supportato dallo swap, e gli altri filesystem in memoria si comportano in modo ancora diverso. Leggete le opzioni di montaggio reali invece di supporre che un percorso sotto /run implichi volatilità.

Poi inventariate le cose che sopravvivono a un riavvio in modi che la gente dimentica: un livello superiore persistente, archiviazione collegata, immagini di ibernazione, dump di crash e snapshot dell'infrastruttura dell'intera VM. Ognuna è una destinazione candidata per uno stato che credevate effimero. Quell'elenco è qualcosa da controllare, non l'affermazione che ogni host le abbia tutte.

Journald ha due destinazioni e un inoltratore

Journald illustra bene la separazione. L'archiviazione volatile tiene le voci sotto /run/log/journal, quella persistente sotto /var/log/journal, e la modalità automatica sceglie tra le due; la modalità in vigore proviene dal sistema in esecuzione, non dalla descrizione dell'immagine. Passare a volatile non cancella ciò che è già stato scritto in modo persistente. Anche l'inoltro è un canale separato: persino un'impostazione di archiviazione che non tiene nulla localmente può consegnare messaggi a un altro bersaglio.

Leggete la modalità effettiva dal journal stesso o dal suo file di configurazione, poi verificate separatamente le destinazioni di inoltro, perché un'impostazione non controlla l'altra.

Cosa deve sopravvivere a un riavvio

Un runtime senza stato supporta la sostituzione ripetibile, e richiede fonti deliberate per la configurazione, l'autorizzazione e il materiale di recupero che il servizio non può inventare. Perdere l'unico stato di registrazione o revoca funzionante per far sparire le scritture locali è un cattivo scambio, e comune. Decidete cosa deve sopravvivere di proposito, poi verificate che lo faccia.

Lo stesso ragionamento vale per i record operativi. Decidete quali eventi sicurezza e gestione del servizio richiedono davvero, con un ambito e una conservazione giustificati, e minimizzate il resto. Minimizzare non è la stessa cosa di disattivare ogni diagnostica.

Confrontate la configurazione effettiva di archiviazione e inoltro con alcuni eventi innocui, poi riavviate o sostituite la macchina e verificate di nuovo cosa è rimasto e da dove il servizio ha recuperato il suo stato.