Un runtime VPN în RAM nu spune nimic despre jurnale

Un server VPN pornit dintr-o imagine doar-citire și care își ține starea de execuție în tmpfs este un design real și util. Este și ușor de descris ca fiind fără jurnale, ceea ce designul nu demonstrează. Locația de stocare determină unde trăiește o copie; colectarea și păstrarea determină dacă există un record, iar o repornire afectează doar prima. Separarea celor două este întreaga analiză.

Începeți prin a enumera fiecare proces care poate scrie stare: demonul, serviciul de autentificare, jurnalul, orice agent de monitorizare și instrumentele de administrare.

Stocarea și colectarea sunt întrebări diferite

Fiecare scriitor are propria destinație și propria politică. Demonul VPN scrie fișiere de stare, backendul de autentificare scrie evenimente de cont, jurnalul colectează ieșirea serviciilor, iar un agent de monitorizare trimite metrici cu totul altundeva. Un design care face unul dintre acestea să dispară la repornire nu a spus nimic despre celelalte trei. Urmați fiecare scriitor până la destinație și notați dacă acea destinație este măcar pe mașină.

Fișierele specifice aplicației, diagnosticele încărcate și serviciile externe au nevoie de același tratament. Absența unui jurnal local cunoscut nu dovedește că înregistrările de conexiune sau de cont nu există nicăieri; dovedește că încă nu ați găsit unde ajung.

tmpfs nu este o garanție

Linux tmpfs nu este un disc RAM fizic. Documentația kernelului spune explicit că paginile pot fi scrise în swap atunci când montarea permite acest lucru, așa că un fișier tmpfs poate ajunge pe un disc fără ca aplicația să îl copieze vreodată acolo. mount arată dacă este în joc un tmpfs susținut de swap, iar alte sisteme de fișiere din memorie se comportă din nou altfel. Citiți opțiunile reale de montare în loc să presupuneți că o cale sub /run înseamnă volatilitate.

Apoi inventariați lucrurile care supraviețuiesc unei reporniri în moduri pe care oamenii le uită: un strat superior persistent, stocare atașată, imagini de hibernare, dump-uri de blocare și instantanee de infrastructură ale întregii VM. Fiecare este o destinație candidată pentru stare pe care o credeați efemeră. Lista este ceva de verificat, nu o afirmație că fiecare gazdă le are pe toate.

Journald are două destinații și un redirector

Journald ilustrează bine împărțirea. Stocarea volatilă ține intrările sub /run/log/journal, cea persistentă sub /var/log/journal, iar modul automat alege între ele; modul în vigoare vine de la sistemul care rulează, nu de la descrierea imaginii. Trecerea la volatil nu șterge ce a fost deja scris persistent. Redirecționarea este și ea un canal separat: chiar și o setare de stocare care nu păstrează nimic local poate preda mesaje altui țintă.

Citiți modul efectiv chiar din jurnal sau din fișierul său de configurare, apoi verificați separat țintele de redirecționare, pentru că o setare nu o controlează pe cealaltă.

Ce trebuie să supraviețuiască unei reporniri

Un runtime fără stare susține înlocuirea repetabilă și are nevoie de surse deliberate pentru configurație, autorizare și materialul de recuperare pe care serviciul nu îl poate inventa. Pierderea singurei stări de înregistrare sau revocare funcționale pentru ca scrierile locale să dispară este o afacere proastă, și frecventă. Decideți ce trebuie să supraviețuiască intenționat, apoi verificați că o face.

Același raționament se aplică înregistrărilor operaționale. Decideți ce evenimente cer cu adevărat securitatea și administrarea serviciului, cu o sferă și o păstrare justificate, și minimizați restul. Minimizarea nu este același lucru cu dezactivarea fiecărui diagnostic.

Comparați configurația efectivă de stocare și redirecționare cu câteva evenimente inofensive, apoi reporniți sau înlocuiți mașina și verificați din nou ce a rămas și de unde serviciul și-a recuperat starea.