Roter en VPN-watchdog-logg uten å brekke skriveren

En VPN-helsesjekk som legger til én linje i minuttet lager stille en annen plikt: å bestemme hvordan disse linjene forlater disken. Å reparere tunnelen gjør ingenting for den plikten, og å gi filen nytt navn omdirigerer ikke en prosess som fortsatt holder den gamle deskriptoren. Svar først på spørsmålet om mottakeren, og tilpass deretter rotasjonen til hvordan skriveren åpner den.

Velg mottakeren før rotasjonspolicyen

En systemd-enhet som allerede sender utdataene sine til journalen, holder oppbevaringen på ett sted. journald håndhever grenser som SystemMaxUse og MaxRetentionSec , så en watchdog som logger der, arver en grense uten ekstra arbeid. Å legge til en andre ubegrenset fil ved siden av dobler vedlikeholdet uten gevinst.

En dedikert fil fortjener plassen sin når noe annet leser den: en parser, en revisjonseksport eller en side som forventer en stabil sti. Når den avgjørelsen er tatt, trenger filen en eier, en modus og en rotasjonspolicy skrevet ned sammen, fordi de tre bare er riktige som et sett. En sti som hvem som helst kan opprette, er også en sti som hvem som helst kan erstatte, så mappetillatelsene hører i samme notat. Skriv alt dette ved siden av sjekken, og neste endring starter fra de samme fakta.

Skriv blokken slik at den passer til skriveren

Start med en skriver som åpner stien ved hvert kall, legger til en linje og avslutter. Det mønsteret overlever rotasjon uten noen form for samarbeid fra prosessen, fordi neste kjøring åpner filen som for øyeblikket ligger på den stien. Blokken nedenfor beholder en ukes versjoner og gjenoppretter filen med den eieren og modusen skriveren trenger:

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

logrotate-håndboken definerer antallet som antall beholdte roterte versjoner, ikke som en garanti for sju dagers historikk, og nøkkelordet daily vurderes når jobben kjører i stedet for å fungere som sin egen planlegger. På de fleste distribusjoner eier en systemd-timer eller en cron-oppføring allerede det kallet, så sjekk hvilken som finnes før du legger til en andre. Å matche eierskapet betyr mer enn oppbevaringsantallet. Å kopiere en modus kun for root over på en fil som skrives av en tjenestekonto, stopper loggingen ved neste rotasjon, og feilen vises timer senere som et utdatert tidsstempel i stedet for som en feil. Bekreft skriverens bruker før du kopierer en blokk fra et annet sted.

En skriver som aldri åpner på nytt, trenger en annen løsning

En langvarig prosess som holder en åpen deskriptor, fortsetter å skrive til den omdøpte inoden. Plass frigjøres ikke, og den synlige filen slutter å vokse, noe som ser ut som en ødelagt rotasjon til du sjekker inoden. Enten lær prosessen å åpne på nytt, eller la rotasjonen kopiere og avkorte i stedet for å gi nytt navn.

Veien med å åpne på nytt er den reneste der programvaren støtter det: send det dokumenterte signalet eller kjør den dokumenterte kommandoen, og la prosessen åpne den nye filen selv. Alternativet er copytruncate , som kopierer innholdet til det roterte navnet og deretter avkorter originalen på stedet, slik at deskriptoren forblir gyldig, men skrivinger som faller mellom kopien og avkortningen, går tapt.

For enheter som startes av systemd, pek StandardOutput mot journalen eller mot en fil og la enheten eie livssyklusen. En shell-løkke som legger til via tee -a uten størrelsesgrense, er oppsettet som fyller en partisjon under et avbrudd, fordi en mislykket sjekk ofte logger langt mer enn en sunn.

Test rotasjonen uten å vente på timeren

Feilsøkingsmodus rapporterer hva som ville skje og rører ingenting, noe som gjør den til den trygge første kjøringen etter en endring. Tving frem en ekte rotasjon når du er fornøyd, og bekreft deretter at neste logglinje lander i den nye filen i stedet for den omdøpte:

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

Les utdataene i den rekkefølgen. Feilsøkingskjøringen skal navngi filen og handlingene den har tenkt; en tvunget kjøring skal produsere det roterte navnet du forventet; tail skal vise en fersk oppføring etter at skriveren kjører igjen. En voksende df-verdi med en krympende synlig fil betyr deskriptorproblemet beskrevet ovenfor.

Gjenta den tvungne kjøringen to ganger for å se hvordan oppbevaringen oppfører seg når versjoner allerede finnes. Sletting av den eldste filen er det forventede resultatet, og en manglende sletting betyr vanligvis at antallet eller jokertegnet i det roterte navnet ikke samsvarer med det logrotate opprettet.

Behold en tilbakerulling og en skriftlig registrering

Lagre den forrige blokken før redigering, og noter hvilken planlegger som kjører den, fordi en tilbakerulling som gjenoppretter filen men ikke timeren, gjengir halve det opprinnelige problemet. Roter én gang for hånd etter gjenopprettingen, og bekreft deretter at skriverens konto kan skrive på loggstien. Hvis tjenesten kjører under systemd, last enheten på nytt etter enhver endring i omdirigeringen av utdataene, siden den kjørende prosessen fortsetter å skrive til det gamle målet. Les de neste logglinjene selv i stedet for å stole på at enheten kom rent tilbake.

Noter modus, eier, oppbevaringsantall og det forventede diskbudsjettet ved siden av selve sjekken. Når sjekken senere endres fra et engangsskript til en daemon, må rotasjonspolicyen endres med den, og det notatet forteller neste person hvilken antakelse som brast.

Til slutt, hold loggavgjørelsen atskilt fra gjenopprettingsavgjørelsen. En mislykket sjekk bør følge forbindelsens egen gjenopprettingspolicy, ikke en regel skjult inne i logrotate, og ingen loggoppsett bør være grunnen til at en fungerende tunnel startes på nytt.