A RAM-ban futó VPN futtatókörnyezet semmit sem mond a naplókról

Az írásvédett lemezképből induló, futásidejű állapotát tmpfsen tartó VPN-kiszolgáló valós és hasznos kialakítás. Könnyű naplók nélküliként leírni is, amit a kialakítás nem bizonyít. A tárolási hely dönti el, hol él egy másolat; a gyűjtés és a megőrzés dönti el, létezik-e egyáltalán rekord, és az újraindítás csak az elsőt érinti. A kettő szétválasztása maga az egész áttekintés.

Kezdje azon folyamatok felsorolásával, amelyek állapotot írhatnak: a démon, a hitelesítési szolgáltatás, a napló, bármely megfigyelő ügynök és a kezelőeszközök.

A tárolás és a gyűjtés különböző kérdések

Minden írónak saját célja és saját szabályzata van. A VPN-démon állapotfájlokat ír, a hitelesítési háttér fiókeseményeket ír, a napló a szolgáltatások kimenetét gyűjti, és egy megfigyelő ügynök a mérőszámokat egészen máshová küldi. Egy kialakítás, amely ezek egyikét eltünteti újraindításkor, semmit sem mondott a másik háromról. Kövesse minden írót a céljáig, és jegyezze fel, hogy az a cél egyáltalán a gépen van-e.

Az alkalmazásspecifikus fájlok, a feltöltött diagnosztika és a külső szolgáltatások ugyanezt a kezelést igénylik. Egy ismert helyi napló hiánya nem bizonyítja, hogy kapcsolati vagy fiókrekordok sehol nem léteznek; azt bizonyítja, hogy még nem találta meg, hová mennek.

A tmpfs nem garancia

A Linux tmpfs nem fizikai RAM-lemez. A kernel dokumentációja egyértelmű: az oldalak swapba írhatók, ha a csatolás engedi, így egy tmpfs-fájl eljuthat a lemezre anélkül, hogy az alkalmazás valaha odamásolná. mount megmutatja, játékban van-e swap-alapú tmpfs, és a többi memóriafájlrendszer megint másképp viselkedik. Olvassa el a tényleges csatolási beállításokat, ahelyett hogy feltételezné, hogy a /run alatti útvonal illékonyságot jelent.

Ezután leltározza fel azokat a dolgokat, amelyek újraindítást túlélnek olyan módokon, amelyeket az emberek elfelejtenek: állandó felső réteg, csatolt tároló, hibernációs lemezképek, összeomlási dumpok és a teljes VM infrastruktúra-pillanatképei. Mindegyik lehetséges célállomás olyan állapot számára, amelyet efemernek hitt. Ez a lista ellenőrizendő, nem pedig az az állítás, hogy minden gazdagépen mindegyik megvan.

A Journald-nak két célja és egy továbbítója van

A Journald szépen szemlélteti a szétválást. Az illékony tároló a bejegyzéseket a /run/log/journal alatt tartja, az állandó a /var/log/journal alatt, és az automatikus mód választ a kettő között; az érvényben lévő mód a futó rendszertől származik, nem a lemezkép leírásától. Az illékonyra váltás nem törli azt, ami már állandóan íródott. A továbbítás is külön csatorna: még egy olyan tárolási beállítás is, amely helyben semmit nem tart, átadhat üzeneteket egy másik célpontnak.

Olvassa ki az érvényes módot magából a naplóból vagy annak konfigurációs fájljából, majd külön ellenőrizze a továbbítási célpontokat, mert az egyik beállítás nem irányítja a másikat.

Mi maradjon életben újraindítás után

Az állapot nélküli futtatókörnyezet támogatja az ismételhető cserét, és szándékos forrásokra van szüksége a konfigurációhoz, a jogosításhoz és a helyreállítási anyaghoz, amelyet a szolgáltatás nem tud kitalálni. Az egyetlen működő regisztrációs vagy visszavonási állapot elvesztése azért, hogy a helyi írások eltűnjenek, rossz üzlet, és gyakori. Döntse el, minek kell szándékosan életben maradnia, majd ellenőrizze, hogy így van.

Ugyanez az érvelés érvényes az üzemeltetési rekordokra. Döntse el, mely eseményeket igényli valóban a biztonság és a szolgáltatáskezelés, indokolt hatókörrel és megőrzéssel, a többit pedig minimalizálja. A minimalizálás nem ugyanaz, mint minden diagnosztika kikapcsolása.

Hasonlítsa össze az érvényes tárolási és továbbítási konfigurációt néhány ártalmatlan eseménnyel, majd indítsa újra vagy cserélje ki a gépet, és ellenőrizze újra, mi maradt meg, és honnan állította helyre az állapotát a szolgáltatás.