En VPN-runtime i RAM säger ingenting om loggar

En VPN-server som startar från en skrivskyddad avbild och håller sitt körtidstillstånd på tmpfs är en verklig och användbar design. Det är också lätt att beskriva den som utan loggar, vilket designen inte fastställer. Lagringsplatsen avgör var en kopia bor; insamling och bevarande avgör om en post alls finns, och en omstart påverkar bara det första. Att hålla de två isär är hela granskningen.

Börja med att lista varje process som kan skriva tillstånd: daemonen, autentiseringstjänsten, journalen, eventuella övervakningsagenter och administrationsverktygen.

Lagring och insamling är olika frågor

Varje skrivare har sin egen destination och sin egen policy. VPN-daemonen skriver statusfiler, autentiseringsbackendet skriver kontohändelser, journalen samlar tjänsteutdata, och en övervakningsagent skickar mätvärden någon helt annanstans. En design som får en av dessa att försvinna vid omstart har inte sagt något om de andra tre. Följ varje skrivare till sin destination och notera om destinationen ens finns på maskinen.

Applikationsspecifika filer, uppladdad diagnostik och externa tjänster behöver samma behandling. Avsaknaden av en känd lokal logg bevisar inte att anslutnings- eller kontoposter inte finns någonstans; den bevisar att du ännu inte har hittat vart de tar vägen.

tmpfs är ingen garanti

Linux tmpfs är inte en fysisk RAM-disk. Kärndokumentationen säger uttryckligen att sidor kan skrivas till swap när monteringen tillåter det, så en tmpfs-fil kan nå en disk utan att applikationen någonsin kopierar den dit. mount visar om en swap-stödd tmpfs är i spel, och andra minnesfilsystem beter sig återigen annorlunda. Läs de faktiska monteringsalternativen i stället för att anta att en sökväg under /run innebär flyktighet.

Inventera sedan de saker som överlever en omstart på sätt som människor glömmer: ett beständigt överlager, ansluten lagring, vilolägesavbilder, kraschdumpar och infrastruktursnapshots av hela VM:en. Var och en är en möjlig destination för tillstånd du trodde var efemärt. Listan är något att kontrollera, inte ett påstående att varje värd har dem alla.

Journald har två destinationer och en vidarebefordrare

Journald illustrerar delningen snyggt. Flyktig lagring håller poster under /run/log/journal, beständig lagring under /var/log/journal, och automatiskt läge väljer mellan dem; läget som gäller kommer från det körande systemet och inte från avbildens beskrivning. Att byta till flyktigt raderar inte det som redan skrivits beständigt. Vidarebefordran är också en egen kanal: även en lagringsinställning som inte håller något lokalt kan lämna över meddelanden till ett annat mål.

Läs det effektiva läget från journalen själv eller dess konfigurationsfil och kontrollera sedan vidarebefordringsmålen separat, eftersom en inställning inte styr den andra.

Vad som måste överleva en omstart

En tillståndslös runtime stöder upprepad utbytbarkeit och behöver medvetna källor för konfigurationen, auktoriseringen och återställningsmaterialet som tjänsten inte kan hitta på. Att förlora det enda fungerande registrerings- eller återkallandetillståndet för att lokala skrivningar ska försvinna är en dålig affär, och en vanlig. Bestäm vad som medvetet ska överleva och verifiera sedan att det gör det.

Samma resonemang gäller för driftsposter. Bestäm vilka händelser säkerhet och tjänstehantering verkligen kräver, med motiverat omfång och bevarande, och minimera resten. Minimering är inte samma sak som att stänga av all diagnostik.

Jämför den effektiva lagrings- och vidarebefordringskonfigurationen med några ofarliga händelser, starta eller byt sedan ut maskinen och kontrollera igen vad som återstod och var tjänsten återställde sitt tillstånd.