RAM-is töötav VPN-i runtime ei ütle logide kohta midagi

Ainult lugemiseks mõeldud kujutisest käivitatud VPN-server, mille tööolek on tmpfsis, on tõeline ja kasulik lahendus. Seda on ka lihtne kirjeldada kui logideta, mida lahendus ei tõesta. Salvestuskoht määrab, kus koopia elab; kogumine ja säilitamine määravad, kas kirje üldse olemas on, ja taaskäivitus mõjutab ainult esimest. Nende kahe eristamine ongi kogu ülevaatus.

Alustage kõigi olekut kirjutada suutvate protsesside loetlemisest: deemon, autentimisteenus, journal, mis tahes monitoorimisagent ja haldustööriistad.

Salvestamine ja kogumine on erinevad küsimused

Igal kirjutajal on oma sihtkoht ja oma poliitika. VPN-i deemon kirjutab olekufaile, autentimise taust kirjutab konto sündmusi, journal kogub teenuste väljundit ja monitoorimisagent saadab mõõdikud hoopis mujale. Lahendus, mis paneb ühe neist taaskäivitusel kaduma, ei ole öelnud ülejäänud kolme kohta midagi. Jälgige iga kirjutajat selle sihtkohta ja pange kirja, kas see sihtkoht on üldse masinas.

Rakendusepõhised failid, üleslaaditud diagnostika ja välised teenused vajavad sama käsitlust. Tavalise kohaliku logi puudumine ei tõesta, et ühenduste või kontode kirjeid kusagil ei ole; see tõestab, et te pole veel leidnud, kuhu need lähevad.

tmpfs ei ole garantii

Linuxi tmpfs ei ole füüsiline RAM-ketas. Kernelidokumentatsioon ütleb selgelt, et lehekülgi võib swap'i kirjutada, kui mount seda lubab, seega võib tmpfs-fail jõuda kettale ilma, et rakendus oleks seda kunagi sinna kopeerinud. mount näitab, kas mängus on swap'iga toetatud tmpfs, ja teised mälufailisüsteemid käituvad jällegi teisiti. Lugege tegelikke mount-valikuid, selle asemel et eeldada, et tee /run all tähendab lenduvust.

Seejärel loetlege asjad, mis elavad taaskäivituse üle viisil, mille inimesed unustavad: püsiv ülemkiht, külge ühendatud salvestusruum, hibernate-kujutised, krahhidumpid ja kogu VM-i infrastruktuuri hetktõmmised. Igaüks neist on võimalik sihtkoht olekule, mida pidasite efemeerseks. See nimekiri on asi, mida kontrollida, mitte väide, et igal hostil on need kõik olemas.

Journaldil on kaks sihtkohta ja edastaja

Journald illustreerib jaotust kenasti. Lenduv salvestus hoiab kirjeid /run/log/journal all, püsiv /var/log/journal all, ja automaatne režiim valib nende vahel; kehtiv režiim tuleb töötavast süsteemist, mitte kujutise kirjeldusest. Lenduvale lülitumine ei kustuta seda, mis on juba püsivalt kirjutatud. Edastamine on samuti eraldi kanal: isegi salvestusseade, mis kohapeal midagi ei hoia, võib sõnumid teisele sihtmärgile üle anda.

Lugege kehtiv režiim journalist endast või selle konfiguratsioonifailist, seejärel kontrollige edastussihtkohti eraldi, sest üks seade ei juhi teist.

Mis peab taaskäivituse üle elama

Olekuta runtime toetab korratavat asendamist ja vajab teadlikke allikaid konfiguratsiooni, autoriseerimise ja taastematerjali jaoks, mida teenus ise välja mõelda ei saa. Ainus töötav registreerimis- või tühistamisolek kaotada, et kohalikud kirjutused kaoksid, on halb tehing ja tavaline. Otsustage, mis peab meelega alles jääma, ja seejärel kontrollige, et jääb.

Sama loogika kehtib ka töökirjete kohta. Otsustage, milliseid sündmusi turvalisus ja teenusehaldus tõesti vajavad, põhjendatud ulatuse ja säilitamisega, ja minimeerige ülejäänu. Minimeerimine ei ole sama, mis kogu diagnostika väljalülitamine.

Võrrelge kehtivat salvestus- ja edastuskonfiguratsiooni mõne kahjutu sündmusega, seejärel taaskäivitage või asendage masin ja kontrollige uuesti, mis jäi alles ja kust teenus oma oleku taastas.