VPN-rultempo en RAM diras nenion pri protokoloj

VPN-servilo lanĉita el nurlegebla bildo kun sia rultempa stato sur tmpfs estas reala kaj utila projekto. Ankaŭ facile estas priskribi ĝin kiel sen protokoloj, kion la projekto ne pruvas. La konserveja loko decidas, kie kopio loĝas; kolektado kaj retenado decidas, ĉu rikordo entute ekzistas, kaj restartigo efikas nur la unuan. Apartigi tiujn du estas la tuta revizio.

Komencu per listigo de ĉiu procezo, kiu povas skribi staton: la demono, la aŭtentiga servo, la ĵurnalo, iu ajn monitora agento kaj la administraj iloj.

Konservado kaj kolektado estas malsamaj demandoj

Ĉiu skribanto havas sian propran celon kaj sian propran politikon. La VPN-demono skribas statdosierojn, la aŭtentiga fono skribas kontajn eventojn, la ĵurnalo kolektas servan eligon, kaj monitora agento sendas metrikojn tute aliloke. Projekto, kiu igas unu el tiuj malaperi ĉe restartigo, diris nenion pri la aliaj tri. Sekvu ĉiun skribanton al sia celo kaj notu, ĉu tiu celo entute estas sur la maŝino.

Aplikspecifaj dosieroj, alŝutitaj diagnozoj kaj eksteraj servoj bezonas la saman traktadon. La manko de konata loka protokolo ne pruvas, ke konektaj aŭ kontaj rikordoj ekzistas nenie; ĝi pruvas, ke vi ankoraŭ ne trovis, kien ili iras.

tmpfs ne estas garantio

Linux tmpfs ne estas fizika RAM-disko. La dokumentaro de la kerno klare diras, ke paĝoj povas esti skribitaj al swap kiam la muntado tion permesas, do tmpfs-dosiero povas atingi diskon sen ke la aplikaĵo iam kopius ĝin tien. mount montras, ĉu swap-subtenata tmpfs estas en ludo, kaj aliaj memordosiersistemoj kondutas ankoraŭ alie. Legu la realajn muntajn elektojn anstataŭ supozi, ke vojo sub /run implicas portempecon.

Poste inventaru la aferojn, kiuj postvivas restartigon laŭ manieroj, kiujn homoj forgesas: daŭra surmetaĵo, alkroĉita konservejo, hibernaciaj bildoj, kraŝaj dumpoj kaj infrastrukturaj momentkopioj de la tuta VM. Ĉiu estas ebla celo por stato, kiun vi kredis efemera. Tiu listo estas io kontrolinda, ne aserto, ke ĉiu gastiganto havas ĉiujn.

Journald havas du celojn kaj plusendilon

Journald ilustras la disigon nete. Portempa konservejo tenas rikordojn sub /run/log/journal, daŭra sub /var/log/journal, kaj la aŭtomata reĝimo elektas inter ili; la validanta reĝimo venas de la kuranta sistemo, ne de la priskribo de la bildo. Ŝanĝo al portempa ne forigas tion, kio jam estis skribita daŭre. Plusendado ankaŭ estas aparta kanalo: eĉ konserveja agordo, kiu tenas nenion loke, povas transdoni mesaĝojn al alia celo.

Legu la efektivan reĝimon el la ĵurnalo mem aŭ el ĝia agorda dosiero, poste kontrolu la plusendajn celojn aparte, ĉar unu agordo ne regas la alian.

Kio devas postvivi restartigon

Senstata rultempo subtenas ripeteblan anstataŭigon, kaj ĝi bezonas intencajn fontojn por la agordo, rajtigo kaj reakira materialo, kiun la servo ne povas elpensi. Perdi la solan funkciantan aliĝan aŭ revokan staton por ke lokaj skriboj malaperu estas malbona interŝanĝo, kaj ofta. Decidu, kio devas postvivi intence, poste kontrolu, ke ĝi faras tion.

La sama rezonado validas por operaciaj rikordoj. Decidu, kiujn eventojn sekureco kaj servadministrado vere bezonas, kun pravigita amplekso kaj retenado, kaj minimumigu la reston. Minimumigi ne samas kiel malŝalti ĉiun diagnozon.

Komparu la efektivan konservejan kaj plusendan agordon kun kelkaj sendanĝeraj eventoj, poste restartigu aŭ anstataŭigu la maŝinon kaj kontrolu denove, kio restis kaj kie la servo reakiris sian staton.