VPN i RAM forteller ingenting om logger

En VPN-tjener som starter fra et skrivebeskyttet avtrykk og holder kjøretidstilstanden på tmpfs, er et virkelig og nyttig design. Det er også enkelt å beskrive som uten logger, noe designet ikke beviser. Lagringsplassen bestemmer hvor en kopi bor; innsamling og oppbevaring bestemmer om en post i det hele tatt finnes, og en omstart berører bare det første. Å skille disse to er hele gjennomgangen.

Start med å liste opp alle prosesser som kan skrive tilstand: daemonen, autentiseringstjenesten, journalen, eventuelle overvåkingsagenter og administrasjonsverktøyene.

Lagring og innsamling er to forskjellige spørsmål

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

Applikasjonsspesifikke filer, opplastet diagnostikk og eksterne tjenester trenger samme behandling. At en kjent lokal logg mangler, beviser ikke at tilkoblings- eller kontooppføringer ikke finnes noe sted; det beviser at du ikke ennå har funnet hvor de tar veien.

tmpfs er ingen garanti

Linux tmpfs er ikke en fysisk RAM-disk. Kerneldokumentasjonen er tydelig på at sider kan skrives til swap når monteringen tillater det, slik at 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 bruk, og andre minnefilsystemer oppfører seg annerledes igjen. Les de faktiske monteringsvalgene i stedet for å anta at en sti under /run betyr flyktighet.

Deretter tar du inventar over tingene som overlever en omstart på måter folk glemmer: et vedvarende overlegg, tilkoblet lagring, dvalemodusbilder, krasjdumper og infrastruktursnapshots av hele VM-en. Hver av dem er en mulig destinasjon for tilstand du trodde var efemær. 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 på en ryddig måte. 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 levere meldinger til et annet mål.

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

Hva som må overleve en omstart

En tilstandsløs runtime 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 faktisk krever, med begrunnet omfang og oppbevaring, og minimer resten. Minimalisering er ikke det samme som å slå av all diagnostikk.

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