En VPN-runtime i RAM sier ingenting om logger

En VPN-server som starter fra et skrivebeskyttet avtrykk og holder kjøretidstilstanden sin på tmpfs, er et reelt og nyttig design. Det er også lett å beskrive som uten logger, noe designet ikke godtgjør. Lagringsstedet avgjør hvor en kopi bor; innsamling og oppbevaring avgjør om en post i det hele tatt finnes, og en omstart påvirker bare det første. Å holde de to fra hverandre er hele gjennomgangen.

Begynn med å liste opp hver prosess som kan skrive tilstand: daemonen, autentiseringstjenesten, journalen, enhver overvåkingsagent og administrasjonsverktøyene.

Lagring og innsamling er forskjellige spørsmål

Hver skriver har sin egen destinasjon og sin egen policy. VPN-daemonen skriver statusfiler, autentiseringsbackenden skriver kontohandlinger, journalen samler tjenesteutdata, og en overvåkingsagent sender målinger helt andre steder. Et design som får én av disse til å forsvinne ved omstart, har ikke sagt noe om de tre andre. Følg hver skriver til destinasjonen og noter om destinasjonen i det hele tatt er på maskinen.

Applikasjonsspesifikke filer, opplastede diagnoser og eksterne tjenester trenger samme behandling. Fraværet av en kjent lokal logg beviser ikke at tilkoblings- eller kontoposter ikke finnes noe sted; det beviser at du ennå ikke har funnet hvor de tar veien.

tmpfs er ikke en garanti

Linux tmpfs er ikke en fysisk RAM-disk. Kernedokumentasjonen er tydelig på at sider kan skrives til swap når monteringen tillater det, så en tmpfs-fil kan nå en disk uten at applikasjonen noen gang kopierer den dit. mount viser om en swap-støttet tmpfs er i spill, og andre minnefilsystemer oppfører seg igjen annerledes. Les de faktiske monteringsvalgene i stedet for å anta at en sti under /run betyr flyktighet.

Deretter inventer tingene som overlever en omstart på måter folk glemmer: et vedvarende overlegg, tilkoblet lagring, dvalemodusbilder, krasj-dumper og infrastruktursnapshots av hele VM-en. Hver av dem er en mulig destinasjon for tilstand du trodde var efemer. Listen er noe som skal sjekkes, ikke en påstand om at hver vert har dem alle.

Journald har to destinasjoner og en videresender

Journald illustrerer delingen pent. Flyktig lagring holder oppføringer under /run/log/journal, vedvarende lagring under /var/log/journal, og automatisk modus velger mellom dem; modusen som gjelder, kommer fra det kjørende systemet og ikke fra beskrivelsen av avtrykket. Bytte til flyktig sletter ikke det som allerede er skrevet vedvarende. Videresending er også en egen kanal: selv en lagringsinnstilling som ikke holder noe lokalt, kan overlevere meldinger til et annet mål.

Les den effektive modusen fra journalen selv eller konfigurasjonsfilen dens, og kontroller deretter videresendingsmålene separat, fordi én innstilling ikke styrer den andre.

Hva som må overleve en omstart

En tilstandsløs kjøretid støtter gjentatt utskifting, og den trenger bevisste kilder til konfigurasjonen, autorisasjonen og gjenopprettingsmaterialet som tjenesten ikke kan finne opp. Å miste den eneste fungerende registrerings- eller tilbakekallingstilstanden for at lokale skrivinger skal forsvinne, er en dårlig handel, og en vanlig. Bestem hva som bevisst skal overleve, og verifiser deretter at det gjør det.

Samme resonnement gjelder for driftsregistreringer. Bestem hvilke hendelser sikkerhet og tjenestestyring virkelig krever, med begrunnet omfang og oppbevaring, og minimer resten. Minimalisering er ikke det samme som å slå av all diagnostikk.

Sammenlign den effektive lagrings- og videresendingskonfigurasjonen med noen få ufarlige hendelser, start eller skift deretter ut maskinen, og kontroller igjen hva som ble igjen og hvor tjenesten gjenopprettet tilstanden sin.