RAM-e veikianti VPN vykdymo aplinka nieko nesako apie žurnalus

VPN serveris, paleidžiamas iš tik skaitymui skirto atvaizdo ir laikantis savo vykdymo būseną tmpfs, yra realus ir naudingas sprendimas. Jį taip pat lengva apibūdinti kaip be žurnalų, ko sprendimas neįrodo. Saugojimo vieta lemia, kur gyvena kopija; rinkimas ir saugojimas lemia, ar įrašas apskritai egzistuoja, o pakartotinis paleidimas veikia tik pirmąjį. Šių dviejų atskyrimas yra visa apžvalga.

Pradėkite išvardydami kiekvieną procesą, galintį rašyti būseną: demonas, autentifikavimo tarnyba, žurnalas, bet koks stebėjimo agentas ir valdymo priemonės.

Saugojimas ir rinkimas yra skirtingi klausimai

Kiekvienas rašytojas turi savo paskirties vietą ir savo politiką. VPN demonas rašo būsenos failus, autentifikavimo vidinė dalis rašo paskyros įvykius, žurnalas renka tarnybų išvestį, o stebėjimo agentas siunčia metrikas visai kitur. Sprendimas, dėl kurio vienas iš jų dingsta paleidžiant iš naujo, nieko nepasakė apie kitus tris. Sekite kiekvieną rašytoją iki jo paskirties vietos ir pažymėkite, ar ta vieta apskritai yra mašinoje.

Programai būdingi failai, įkelta diagnostika ir išorinės tarnybos reikalauja tokio pat požiūrio. Įprasto vietinio žurnalo nebuvimas neįrodo, kad ryšio ar paskyros įrašų niekur nėra; jis įrodo, kad dar neradote, kur jie eina.

tmpfs nėra garantija

Linux tmpfs nėra fizinis RAM diskas. Branduolio dokumentacija aiškiai nurodo, kad puslapiai gali būti rašomi į swap, kai prijungimas tai leidžia, todėl tmpfs failas gali pasiekti diską net jei programa jo ten niekada nenukopijavo. mount parodo, ar naudojamas swap pagrįstas tmpfs, o kitos atminties failų sistemos elgiasi dar kitaip. Skaitykite faktines prijungimo parinktis, o ne manykite, kad kelias po /run reiškia nepastovumą.

Tada surašykite dalykus, kurie išgyvena pakartotinį paleidimą būdais, kuriuos žmonės pamiršta: nuolatinis viršutinis sluoksnis, prijungta saugykla, hibernacijos atvaizdai, strigčių iškeltys ir visos VM infrastruktūros momentinės kopijos. Kiekvienas jų yra galima paskirties vieta būsenai, kurią laikėte efemeriška. Tas sąrašas yra tai, ką reikia patikrinti, o ne teiginys, kad kiekvienas serveris turi juos visus.

Journald turi dvi paskirties vietas ir persiuntėją

Journald gražiai iliustruoja padalijimą. Nepastovioji saugykla laiko įrašus po /run/log/journal, nuolatinė po /var/log/journal, o automatinis režimas renkasi tarp jų; galiojantis režimas ateina iš veikiančios sistemos, o ne iš atvaizdo aprašymo. Perėjimas prie nepastoviosios neištrina to, kas jau buvo įrašyta nuolat. Persiuntimas taip pat yra atskiras kanalas: net saugojimo nustatymas, kuris vietoje nieko nelaiko, gali perduoti pranešimus kitam tikslui.

Skaitykite galiojantį režimą iš paties žurnalo ar jo konfigūracijos failo, tada atskirai patikrinkite persiuntimo tikslus, nes vienas nustatymas nevaldo kito.

Kas turi išgyventi pakartotinį paleidimą

Būsenos neturinti aplinka palaiko pakartotinį pakeitimą ir jai reikia sąmoningų šaltinių konfigūracijai, autorizacijai ir atkūrimo medžiagai, kurios tarnyba negali sugalvoti. Prarasti vienintelę veikiančią registracijos ar atšaukimo būseną tam, kad vietiniai įrašai išnyktų, yra blogas sandoris ir dažnas. Nuspręskite, kas turi sąmoningai išgyventi, tada patikrinkite, kad išgyvena.

Ta pati logika galioja operaciniams įrašams. Nuspręskite, kokių įvykių saugumui ir tarnybos valdymui iš tikrųjų reikia, su pagrįsta apimtimi ir saugojimu, o likusius sumažinkite iki minimumo. Sumažinimas nėra tas pats, kas išjungti visą diagnostiką.

Palyginkite galiojančią saugojimo ir persiuntimo konfigūraciją su keliais nekenksmingais įvykiais, tada paleiskite iš naujo arba pakeiskite mašiną ir dar kartą patikrinkite, kas liko ir iš kur tarnyba atkūrė savo būseną.