Ein VPN-runtime i RAM seier ingenting om loggar

Ein VPN-tenar som startar frå eit skriveverna avtrykk og held køyretidstilstanden sin på tmpfs, er eit reelt og nyttig design. Det er òg lett å skildre som utan loggar, noko designet ikkje godtgjer. Lagringsstaden avgjer kvar ein kopi bur; innsamling og oppbevaring avgjer om ein post i det heile finst, og ein omstart påverkar berre det første. Å halde dei to frå kvarandre er heile gjennomgangen.

Byrja med å liste opp kvar prosess som kan skrive tilstand: daemonen, autentiseringstenesta, journalen, kvar overvakingsagent og administrasjonsverktøya.

Lagring og innsamling er ulike spørsmål

Kvar skrivar har sin eigen destinasjon og sin eigen policy. VPN-daemonen skriv statusfiler, autentiseringsbackenden skriv kontohandlingar, journalen samlar tenesteutdata, og ein overvakingsagent sender målingar heilt andre stader. Eit design som får éin av desse til å forsvinne ved omstart, har ikkje sagt noko om dei tre andre. Følg kvar skrivar til destinasjonen og noter om destinasjonen i det heile er på maskina.

Applikasjonsspesifikke filer, opplasta diagnose og eksterne tenester treng same handsaming. Fråværet av ein kjend lokal logg beviser ikkje at tilkoplings- eller kontopostar ikkje finst nokon stad; det beviser at du enno ikkje har funne kvar dei tek vegen.

tmpfs er ikkje ei garanti

Linux tmpfs er ikkje ein fysisk RAM-disk. Kernedokumentasjonen er tydeleg på at sider kan skrivast til swap når monteringa tillèt det, så ei tmpfs-fil kan nå ein disk utan at applikasjonen nokon gong kopierer henne dit. mount viser om ein swap-støtta tmpfs er i spel, og andre minnefilsystem oppfører seg igjen annleis. Les dei faktiske monteringsvala i staden for å anta at ein sti under /run tyder flyktighet.

Deretter inventer tinga som overlever ein omstart på måtar folk gløymer: eit vedvarande overlegg, tilkopla lagring, dvalemodusbilete, krasj-dumpar og infrastruktursnapshot av heile VM-en. Kvar av dei er ein mogleg destinasjon for tilstand du trudde var efemer. Lista er noko som skal sjekkast, ikkje ein påstand om at kvar vert har dei alle.

Journald har to destinasjonar og ein videresendar

Journald illustrerer delinga pent. Flyktig lagring held oppføringar under /run/log/journal, vedvarande lagring under /var/log/journal, og automatisk modus vel mellom dei; modusen som gjeld, kjem frå det køyrande systemet og ikkje frå skildringa av avtrykket. Bytte til flyktig slettar ikkje det som allereie er skrive vedvarande. Videresending er òg ein eigen kanal: sjølv ei lagringsinnstilling som ikkje held noko lokalt, kan overlevere meldingar til eit anna mål.

Les den effektive modusen frå journalen sjølv eller konfigurasjonsfila hans, og kontroller deretter videresendingsmåla separat, fordi éi innstilling ikkje styrer den andre.

Kva som må overleve ein omstart

Ein tilstandslaus køyretid støttar gjenteken utskifting, og han treng bevisste kjelder til konfigurasjonen, autorisasjonen og gjenopprettingsmaterialet som tenesta ikkje kan finne opp. Å miste den einaste fungerande registrerings- eller tilbakekallingstilstanden for at lokale skrivingar skal forsvinne, er ein dårleg handel, og ein vanleg. Avgjer kva som bevisst skal overleve, og verifiser deretter at det gjer det.

Same resonnementet gjeld for driftsregistreringar. Avgjer kva hendingar tryggleik og tenestestyring verkeleg krev, med grunngjeve omfang og oppbevaring, og minimaliser resten. Minimalisering er ikkje det same som å slå av all diagnostikk.

Samanlikn den effektive lagrings- og videresendingskonfigurasjonen med nokre få uskadelege hendingar, start eller skift deretter ut maskina, og kontroller igjen kva som vart att og kvar tenesta gjenoppretta tilstanden sin.