RAM-gebaseerde VPN-looptyd sê niks oor logboeke

'n VPN-bediener wat van 'n leesalleen-beeld begin en sy looptydtoestand op tmpfs hou, is 'n werklike en nuttige ontwerp. Dit is ook maklik om as geen logboeke te beskryf, wat die ontwerp nie bewys nie. Die bergingsplek bepaal waar 'n kopie woon; versameling en bewaring bepaal of 'n rekord hoegenaamd bestaan, en 'n herbegin raak net die eerste. Om dié twee uitmekaar te hou, is die hele oorsig.

Begin deur elke proses te lys wat toestand kan skryf: die daemon, die verifikasiediens, die joernaal, enige moniteringsagent en die bestuursgereedskap.

Berging en versameling is verskillende vrae

Elke skrywer het sy eie bestemming en sy eie beleid. Die VPN-daemon skryf statuslêers, die verifikasie-agterkant skryf rekeninggebeure, die joernaal versamel diensuitset, en 'n moniteringsagent stuur maatstawwe heeltemal elders heen. 'n Ontwerp wat een daarvan by herbegin laat verdwyn, het niks oor die ander drie gesê nie. Volg elke skrywer na sy bestemming en let op of daardie bestemming hoegenaamd op die masjien is.

Programspesifieke lêers, opgelaaide diagnostiek en eksterne dienste het dieselfde behandeling nodig. Die afwesigheid van 'n bekende plaaslike logboek bewys nie dat verbinding- of rekeningrekords nêrens bestaan nie; dit bewys dat jy nog nie gevind het waar hulle heen gaan nie.

tmpfs is nie 'n waarborg nie

Linux tmpfs is nie 'n fisiese RAM-skyf nie. Die kern se dokumentasie is duidelik dat bladsye na swap geskryf kan word wanneer die montering dit toelaat, so 'n tmpfs-lêer kan 'n skyf bereik sonder dat die program dit ooit daarheen kopieer. mount wys of 'n swap-gedraagde tmpfs in spel is, en ander geheue-lêerstelsels gedra hulle weer anders. Lees die werklike monteringsopsies eerder as om te aanvaar dat 'n pad onder /run vlugtigheid impliseer.

Maak dan 'n inventaris van die dinge wat 'n herbegin op maniere oorleef wat mense vergeet: 'n aanhoudende oorleg, aangehegte berging, hibernasiebeelde, ineenstortingsdumps en infrastruktuur-momentopnames van die hele VM. Elkeen is 'n kandidaatbestemming vir toestand wat jy as kortstondig beskou het. Daardie lys is iets om na te gaan, nie 'n bewering dat elke gasheer almal daarvan het nie.

Journald het twee bestemmings en 'n aanstuurder

Journald illustreer die verdeling netjies. Vlugtige berging hou inskrywings onder /run/log/journal, aanhoudende berging onder /var/log/journal, en die outomatiese modus kies tussen hulle; die modus wat geld, kom van die lopende stelsel eerder as uit die beeld se beskrywing. Oorskakeling na vlugtig verwyder nie wat reeds aanhoudend geskryf is nie. Aansturing is ook 'n aparte kanaal: selfs 'n bergingsinstelling wat plaaslik niks hou nie, kan boodskappe aan 'n ander teiken oorhandig.

Lees die effektiewe modus uit die joernaal self of sy konfigurasielêer, en kontroleer dan die aanstuurteikens afsonderlik, want een instelling beheer nie die ander nie.

Wat 'n herbegin moet oorleef

'n Toestandlose looptyd ondersteun herhaalbare vervanging, en dit het doelbewuste bronne nodig vir die konfigurasie, magtiging en herstel materiaal wat die diens nie kan uitdink nie. Om die enigste werkende inskrywing- of herroepingstoestand te verloor om plaaslike skrywes te laat verdwyn, is 'n slegte ruil, en 'n algemene een. Besluit doelbewus wat moet oorleef, en verifieer dan dat dit gebeur.

Dieselfde redenasie geld vir operasionele rekords. Besluit watter gebeurtenisse sekuriteit en diensbestuur werklik vereis, met 'n geregverdigde omvang en bewaring, en minimaliseer die res. Minimalisering is nie dieselfde as om elke diagnostiek af te skakel nie.

Vergelyk die effektiewe berging- en aanstuurkonfigurasie met 'n paar onskadelike gebeurtenisse, herbegin of vervang dan die masjien en kyk weer wat oorgebly het en waar die diens sy toestand herstel het.