Izvajalno okolje VPN v RAM ne pove nič o dnevnikih

Strežnik VPN, zagnan iz slike samo za branje in s stanjem delovanja v tmpfs, je resnična in uporabna zasnova. Prav tako ga je lahko opisati kot brez dnevnikov, česar zasnova ne dokazuje. Mesto shranjevanja določa, kje živi kopija; zbiranje in hramba določata, ali zapis sploh obstaja, ponovni zagon pa vpliva le na prvo. Ločevanje teh dveh stvari je celoten pregled.

Začnite s seznamom vseh procesov, ki lahko pišejo stanje: demon, storitev preverjanja pristnosti, dnevnik, vsak nadzorni agent in orodja za upravljanje.

Shranjevanje in zbiranje sta različni vprašanji

Vsak pisec ima svoj cilj in svojo politiko. Demon VPN piše statusne datoteke, zaledje za preverjanje pristnosti piše dogodke računa, dnevnik zbira izhod storitev, nadzorni agent pa pošilja meritve povsem drugam. Zasnova, ki ob ponovnem zagonu povzroči, da ena od teh stvari izgine, ni povedala nič o drugih treh. Sledite vsakemu piscu do njegovega cilja in zabeležite, ali je ta cilj sploh na stroju.

Datoteke, značilne za aplikacijo, naložena diagnostika in zunanje storitve potrebujejo enako obravnavo. Odsotnost znanega lokalnega dnevnika ne dokazuje, da zapisi o povezavah ali računih ne obstajajo nikjer; dokazuje, da še niste našli, kam gredo.

tmpfs ni garancija

Linux tmpfs ni fizični disk RAM. Dokumentacija jedra izrecno navaja, da se strani lahko zapišejo v swap, ko to priklop dovoljuje, zato lahko datoteka tmpfs doseže disk, ne da bi jo aplikacija kdaj tja kopirala. mount pokaže, ali je v igri tmpfs s podporo swap, druge pomnilniške datotečne sisteme pa se obnašajo spet drugače. Berite dejanske možnosti priklopa, namesto da bi domnevali, da pot pod /run pomeni hlapljivost.

Nato popišite stvari, ki preživijo ponovni zagon na načine, ki jih ljudje pozabijo: trajna zgornja plast, priklopljena shramba, slike hibernacije, izpisi sesutij in infrastrukturni posnetki celotnega VM. Vsaka je možni cilj za stanje, ki ste ga imeli za efemerno. Ta seznam je nekaj za preveriti, ne trditev, da jih ima vsak gostitelj vse.

Journald ima dva cilja in posredovalnik

Journald lepo ponazori delitev. Hlapljiva shramba hrani vnose pod /run/log/journal, trajna pod /var/log/journal, samodejni način pa izbira med njima; veljavni način pride iz delujočega sistema, ne iz opisa slike. Preklop na hlapljivo ne izbriše tistega, kar je že bilo trajno zapisano. Posredovanje je tudi ločen kanal: tudi nastavitev shrambe, ki lokalno nič ne hrani, lahko sporočila izroči drugemu cilju.

Preberite veljavni način iz samega dnevnika ali njegove konfiguracijske datoteke, nato ločeno preverite cilje posredovanja, ker ena nastavitev ne upravlja druge.

Kaj mora preživeti ponovni zagon

Okolje brez stanja podpira ponovljivo zamenjavo in potrebuje zavestne vire za konfiguracijo, avtorizacijo in gradivo za obnovitev, ki si ga storitev ne more izmisliti. Izgubiti edino delujoče stanje vpisa ali preklica, da bi lokalni zapisi izginili, je slaba menjava in pogosta. Odločite se, kaj mora namerno preživeti, nato preverite, da preživi.

Enaka logika velja za operativne zapise. Odločite se, katere dogodke varnost in upravljanje storitev resnično potrebujeta, z utemeljenim obsegom in hrambo, ostalo pa zmanjšajte na minimum. Zmanjševanje ni isto kot izklop vse diagnostike.

Primerjajte veljavno konfiguracijo shrambe in posredovanja z nekaj neškodljivimi dogodki, nato znova zaženite ali zamenjajte stroj in znova preverite, kaj je ostalo in od kod je storitev obnovila svoje stanje.