VPN-őrkutya naplójának forgatása az író törése nélkül

Egy VPN-állapotellenőrzés, amely percenként egy sort fűz hozzá, csendesen második kötelességet teremt: eldönteni, hogyan hagyják el ezek a sorok a lemezt. Az alagút javítása semmit nem tesz ezért a kötelességért, és a fájl átnevezése nem irányít át egy folyamatot, amely még a régi leírót tartja. Először a cél kérdésére válaszoljon, aztán a forgatást igazítsa ahhoz, ahogy az író megnyitja.

A célt a forgatási szabályzat előtt válassza ki

Egy systemd-egység, amely már a naplóba küldi a kimenetét, egy helyen tartja a megőrzést. A journald korlátokat kényszerít ki, például a SystemMaxUse és a MaxRetentionSec értéket, így az ott naplózó őr extra munka nélkül örököl egy korlátot. Egy második korlátlan fájl mellé helyezése megduplázza a karbantartást haszon nélkül.

Egy külön fájl akkor érdemli meg a helyét, ha valami más olvassa: egy elemző, egy auditálási export vagy egy stabil útvonalat váró oldal. Ha ez a döntés megszületett, a fájlnak tulajdonosra, módra és forgatási szabályzatra van szüksége, amelyeket együtt írnak le, mert a három csak együtt helyes. Egy útvonal, amelyet bárki létrehozhat, olyan útvonal is, amelyet bárki lecserélhet, ezért a könyvtár jogosultságai ugyanabba a feljegyzésbe tartoznak. Írjon le mindent az ellenőrzés mellé, és a következő szerkesztés ugyanazokból a tényekből indul.

Az íróhoz illő blokkot írjon

Olyan íróból induljon ki, amely minden híváskor megnyitja az útvonalat, hozzáfűz egy sort, és kilép. Ez a minta együttműködés nélkül túléli a forgatást, mert a következő futás azt a fájlt nyitja meg, amely éppen azon az útvonalon van. Az alábbi blokk egy hét verziót tart meg, és az író által igényelt tulajdonossal és móddal hozza létre újra a fájlt:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

A logrotate kézikönyve a számot a megtartott forgatott verziók számaként határozza meg, nem garantált hét nap történetként, és a daily kulcsszó a feladat futásakor értékelődik ki, ahelyett hogy saját ütemezőként működne. A legtöbb disztribúcióban egy systemd-időzítő vagy egy cron-bejegyzés már birtokolja ezt a hívást, ezért ellenőrizze, melyik létezik, mielőtt másodikat adna hozzá. A tulajdonjog egyeztetése fontosabb a megőrzési számnál. Egy csak root számára elérhető mód átmásolása egy szolgáltatási fiók által írt fájlra a következő forgatáskor leállítja a naplózást, és a hiba órákkal később elavult időbélyegként jelenik meg, nem hibaként. Erősítse meg az író felhasználóját, mielőtt blokkot másol máshonnan.

Az író, amely soha nem nyit újra, más javítást igényel

Egy hosszú ideig futó folyamat, amely nyitott leírót tart, tovább ír az átnevezett inode-ba. Ahelyett, hogy felszabadulna a hely, a látható fájl növekedése leáll, ami törött forgatásnak tűnik, amíg meg nem vizsgálja az inode-ot. Vagy tanítsa meg a folyamatot újranyitni, vagy a forgatás másoljon és vágjon az átnevezés helyett.

Az újranyitás útja a tisztább ott, ahol a szoftver támogatja: küldje el a dokumentált jelet, vagy futtassa a dokumentált parancsot, és hagyja, hogy a folyamat maga nyissa meg az új fájlt. Az alternatíva a copytruncate , amely a tartalmat a forgatott névre másolja, majd az eredetit a helyén elvágja, így a leíró érvényes marad, de a másolás és a vágás közé eső írások elvesznek.

A systemd által indított egységeknél irányítsa a StandardOutput-et a naplóra vagy egy fájlra, és hagyja, hogy az egység birtokolja az életciklust. Egy olyan shell-hurok, amely mérethatár nélkül fűz hozzá a tee -a segítségével, az az elrendezés, amely kimaradás idején megtölt egy partíciót, mert a meghiúsuló ellenőrzés gyakran sokkal többet naplóz, mint egy egészséges.

Tesztelje a forgatást az időzítő megvárása nélkül

A hibakeresési mód jelenti, mi történne, és semmihez nem nyúl, ami biztonságos első futtatássá teszi egy szerkesztés után. Kényszerítsen valódi forgatást, ha elégedett, majd erősítse meg, hogy a következő naplósor az új fájlba kerül, nem az átnevezettbe:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

Ebben a sorrendben olvassa a kimenetet. A hibakeresési menetnek meg kell neveznie a fájlt és a tervezett műveleteket; a kényszerített futásnak a várt forgatott nevet kell előállítania; a tail-nek friss bejegyzést kell mutatnia, miután az író újra fut. A növekvő df érték és a zsugorodó látható fájl a fent leírt leíróproblémát jelenti.

Ismételje meg a kényszerített futást kétszer, hogy lássa, hogyan viselkedik a megőrzés, amikor már léteznek verziók. A legrégebbi fájl törlése a várt eredmény, és a hiányzó törlés általában azt jelenti, hogy a forgatott névben lévő szám vagy helyettesítő karakter nem egyezik azzal, amit a logrotate létrehozott.

Tartson fenn visszaállítást és írásos feljegyzést

Szerkesztés előtt mentse el az előző blokkot, és jegyezze fel, melyik ütemező futtatja, mert egy olyan visszaállítás, amely a fájlt, de nem az időzítőt állítja helyre, az eredeti probléma felét reprodukálja. Visszaállítás után forgassa el egyszer kézzel, majd erősítse meg, hogy az író fiókja írhat a napló útvonalára. Ha a szolgáltatás systemd alatt fut, a kimenetének átirányításában bekövetkezett minden változás után töltse újra az egységet, mert a futó folyamat tovább ír a régi célra. Olvassa el maga a következő néhány naplósort, ahelyett hogy megbízna abban, hogy az egység tisztán tért vissza.

Jegyezze fel a módot, a tulajdonost, a megőrzési számot és a várható lemezköltségvetést maga az ellenőrzés mellé. Amikor később az ellenőrzés egyszeri szkriptből démonná változik, a forgatási szabályzatnak vele együtt kell változnia, és az a feljegyzés mondja meg a következő embernek, melyik feltevés tört meg.

Végül tartsa a naplózási döntést külön a helyreállítási döntéstől. Egy meghiúsult ellenőrzésnek a kapcsolat saját helyreállítási szabályzatát kell követnie, nem egy logrotate belsejébe rejtett szabályt, és semmilyen naplózási elrendezés nem lehet az oka egy működő alagút újraindításának.