In VPN-runtime yn RAM seit neat oer lochs

In VPN-tsjinner dy't fan in allinnich-lêze byld opstart en syn runtime-steat op tmpfs hâldt, is in echte en brûkbere opbou. It is ek maklik om it as gjin lochs te beskriuwen, wat de opbou net bewiist. De opslachlokaasje bepaalt wêr't in kopy libbet; samling en bewarring bepale oft in record oait bestiet, en in werstart rekket allinnich it earste. Dy twa apart hâlde is de hiele beoardieling.

Begjin mei it listjen fan elk proses dat steat skriuwe kin: de daemon, de autentikaasjetsjinst, it journaal, elk monitoringsagint en de behearstabels.

Opslach en samling binne ferskillende fragen

Elke skriuwer hat syn eigen bestimming en syn eigen belied. De VPN-daemon skriuwt steatbestannen, de autentikaasje-backend skriuwt akkountbarrens, it journaal sammelt tsjinstútfier, en in monitoringsagint stjoert metriken hielendal earne oars hinne. In opbou dy't ien fan dy by werstart ferdwine lit, hat neat oer de oare trije sein. Folgje elke skriuwer nei syn bestimming en notearje oft dy bestimming oait op 'e masine is.

Applikaasjespesifike bestannen, opladen diagnoaze en eksterne tsjinsten hawwe deselde behanneling nedich. It ûntbrekken fan in fertroud lokaal loch bewiist net dat ferbining- of akkountrecords nearne bestean; it bewiist dat jo noch net fûn hawwe wêr't se hinne geane.

tmpfs is gjin garânsje

Linux tmpfs is gjin fysike RAM-skiif. De dokumintaasje fan 'e kernel is dúdlik dat siden nei swap skreaun wurde kinne as de mount dat tastiet, dat in tmpfs-bestân kin in skiif berikke sûnder dat de applikaasje it der ea hinne kopiearret. mount lit sjen oft in swap-stipe tmpfs yn it spul is, en oare ûnthâld-bestânsystemen hâlde har wer oars. Lês de wiere mount-opsjes ynstee fan oan te nimmen dat in paad ûnder /run flechtigens betsjut.

Meitsje dan in ynventarisaasje fan 'e dingen dy't in werstart oerlibje op manieren dy't minsken ferjitte: in permaninte oerliz, oanbuorde opslach, hibernaasjebylden, crash-dumps en ynfrastruktuer-snapshots fan 'e hiele VM. Elk is in kandidaatbestimming foar steat dy't jo efemeryk tochten. Dy list is eat om te kontrolearjen, net in bewearing dat elke host se allegear hat.

Journald hat twa bestimmingen en in trochstjoerder

Journald yllustrearret de splitsing moai. Flechtige opslach hâldt ynskriuwingen ûnder /run/log/journal, permaninte opslach ûnder /var/log/journal, en de automatyske modus kiest tusken dy beiden; de jildende modus komt fan it rinnende systeem, net fan 'e beskriuwing fan it byld. Omskeakelje nei flechtich smyt net fuort wat al permanint skreaun is. Trochstjoeren is ek in apart kanaal: sels in opslachynstelling dy't lokaal neat hâldt, kin berjochten oan in oar doel oerleverje.

Lês de effektive modus út it journaal sels of syn konfiguraasjebestân, kontrolearje dan de trochstjoerdoelen apart, want ien ynstelling bestjoert de oare net.

Wat in werstart oerlibje moat

In steatleaze runtime stipet werhelbere ferfanging, en hy hat bewuste boarnen nedich foar de konfiguraasje, autorisaasje en it herstelmateriaal dat de tsjinst net betinke kin. It ferliezen fan 'e iennichste wurkjende ynskriuwing- of ynlûkingssteat om lokale skriuwen ferdwine te litten is in minne ruil, en in gewoane. Beslis wat bewust oerlibje moat, en ferifiearje dan dat it dat docht.

Deselde redenearring jildt foar operasjonele records. Beslis hokker barrens feiligens en tsjinstbehear wier fereaskje, mei in rjochtfeardige omfang en bewarring, en minimalisearje de rest. Minimalisearjen is net itselde as alle diagnoaze útskeakelje.

Fergelykje de effektive opslach- en trochstjoerkonfiguraasje mei in pear ûnskealike barrens, werstart of ferfang dan de masine en kontrolearje wer wat oerbleaun is en wêr't de tsjinst syn steat weromfûn.