VPN у RAM-у не говори ништа о дневницима

VPN сервер који се подиже са слике само за читање и држи радно стање на tmpfs је стваран и користан дизајн. Лако га је описати и као онај без дневника, што дизајн не доказује. Место складиштења одређује где копија живи; прикупљање и чување одређују да ли запис уопште постоји, а поновно покретање дотиче само прво. Раздвојити то двоје јесте цео преглед.

Почните пописом сваког процеса који може да пише стање: демон, сервис за аутентификацију, дневник, било који надзорни агент и алати за управљање.

Складиштење и прикупљање су различита питања

Сваки писац има сопствено одредиште и сопствено правило. VPN демон пише датотеке стања, позадина за аутентификацију пише догађаје рачуна, дневник прикупља излаз сервиса, а надзорни агент шаље метрике сасвим другде. Дизајн који при поновном покретању учини да једно од тога нестане није рекао ништа о остала три. Пратите сваког писца до његовог одредишта и забележите налази ли се то одредиште уопште на машини.

Датотеке својствене апликацији, учитана дијагностика и спољни сервиси траже исти третман. Одсуство познатог локалног дневника не доказује да записи о везама или рачунима не постоје нигде; доказује да још нисте нашли куда иду.

tmpfs није гаранција

Linux tmpfs није физички RAM диск. Документација језгра изричито наводи да се странице могу записати у swap када то монтирање дозвољава, па tmpfs датотека може доћи на диск, а да је апликација никада није тамо копирала. mount показује да ли је у игри tmpfs подржан swap-ом, а други меморијски датотечни системи понашају се опет другачије. Читајте стварне могућности монтирања уместо да претпоставите да путања под /run значи испарљивост.

Затим попишите ствари које преживљавају поновно покретање на начине које људи заборављају: трајни горњи слој, прикључено складиште, слике хибернације, исписи падова и инфраструктурне снимке целог VM-а. Свака је могуће одредиште за стање које сте сматрали пролазним. Тај списак треба проверити, а није тврдња да сваки хост има све наведено.

Journald има два одредишта и прослеђивач

Journald лепо показује ту поделу. Испарљиво складиште држи записе под /run/log/journal, трајно под /var/log/journal, а аутоматски режим бира између њих; режим који је на снази долази из система који ради, а не из описа слике. Прелазак на испарљиво не брише оно што је већ трајно записано. Прослеђивање је такође засебан канал: чак и поставка складиштења која локално не држи ништа може предати поруке другом циљу.

Прочитајте делотворни режим из самог дневника или његове конфигурационе датотеке, затим одвојено проверите циљеве прослеђивања, јер једна поставка не управља другом.

Шта мора да преживи поновно покретање

Окружење без стања подупире поновљиву замену и треба намерне изворе за конфигурацију, овлашћење и материјал за опоравак који услуга не може да измисли. Изгубити једино радно стање уписа или опозива како би локални записи нестали лоша је трговина, и честа. Одлучите шта мора намерно да преживи, затим проверите да преживљава.

Исто размишљање важи за оперативне записе. Одлучите које догађаје безбедност и управљање услугама заиста траже, са образложеним обимом и чувањем, а остало сведете на најмању меру. Свођење на најмању меру није исто што и искључивање сваке дијагностике.

Упоредите делотворну конфигурацију складиштења и прослеђивања са неколико безопасних догађаја, затим поново подигните или замените машину и поново проверите шта је остало и одакле је услуга обновила своје стање.