Vem äger OpenVPN-loggarna: daemonen, rsyslog eller logrotate?

Loggrotation går sönder på ett förutsägbart sätt: tre komponenter tror var och en att de äger filen, och resultatet är en roterad logg som fortsätter växa medan den nya blir tom. Daemonen håller en deskriptor, logrotate byter namn på sökvägen och rsyslog skriver någon helt annanstans. Välj en skrivare och en rotator innan du lägger ännu en regel på högen. Checklistan nedan följer den ordningen eftersom varje senare steg beror på den.

Bestäm vem som skriver filen

Två konstruktioner är legitima. I den första skriver VPN-processen själv en fil via sitt eget log- eller log-append-alternativ. I den andra skickar den poster till systemloggen och rsyslog eller journald avgör var de hamnar.

De är alternativ, inte lager. En värd som aktiverar båda slutar med två filer som inte stämmer överens, och den du läser är ofta den föråldrade. Välj sökvägen med avsikt och ta sedan bort den andra skrivaren.

Läs den effektiva tjänstekonfigurationen innan du ändrar något, inklusive drop-ins som kan åsidosätta unit-filen. En direktiv i profilen du redigerade är inte bevis för att det är den som den körande processen laddade. Jämför unit med processens argument och sedan med de filer den faktiskt öppnade.

Namnge daemonen så att filtret kan vara smalt

På syslog-vägen ger du daemonen en egen identitet och filtrerar på den. En regel som matchar programnamnet för den här VPN-instansen håller dess poster utanför en delad fil vars bevarandepolicy tillhör något annat.

Smala regler gör också nästa fråga besvarbar: vilken tjänst producerade den här raden? Ett filter som matchar allt med ordet VPN i sig samlar gärna upp trafiken från en andra tunnel och gör båda otydliga. Matcha den exakta identifierare som unit skickar till loggen.

Stäng regeln efter åtgärden så att posterna inte också faller igenom till standardmålet. Dubblerade rader i två filer ser ut som ett loggningsfel och är egentligen ett saknat stopp. Den enda utelämningen fördubblar också bevarandepolicyns diskkostnad.

Rotera utan att tappa deskriptorn

När daemonen skriver filen byter logrotate namn på sökvägen, men processen behåller sin öppna deskriptor. Nya poster fortsätter in i den omdöpta filen tills något tvingar processen att öppna den ursprungliga sökvägen igen; därför kan en rotation se ut att fungera medan den nya filen förblir tom.

Lösningen är en postrotate-åtgärd som utlöser tjänstens dokumenterade omladdnings- eller omstartsbeteende. Att skicka en signal till loggen är en helt annan åtgärd och gör ingenting för en daemon som håller sin egen fil.

Där återöppning är omöjlig är copytruncate reservplanen: kopiera filen och korta sedan av den på plats. Det håller deskriptorn giltig till priset av att allt som skrivs mellan kopian och avkortningen går förlorat, så det är en byteshandel och inte en lösning. Under last kan den luckan sluka precis det fel du försöker fånga.

Välj en av de två per fil och skriv ned valet, eftersom att blanda dem på samma sökväg ger luckor som är mycket svåra att härleda senare. En läsare som hittar båda mönstren i en katalog kan inte säga vilket som är auktoritativt.

Sätt bevarandet utifrån incidentfönstret

Bevarande, komprimering och maximal storlek bör följa av hur långt tillbaka du faktiskt undersöker. Ett fönster på sju dagar med komprimering och ett storlekstak är en rimlig utgångspunkt för många utrullningar; en siffra kopierad från en handledning är det inte.

Håll policyn på ett ställe. Om logrotate roterar filen och rsyslog också roterar den, vinner den andra rotationen och den förstas namnschema överlever som röra. Välj ägaren, stäng av den andra rotationen och anteckna beslutet bredvid policyn.

Dokumentationen för rsyslog täcker dess routing- och åtgärdsmodell, medan dokumentationen för OpenVPN-tjänsten förblir auktoritativ för daemonens egna loggningsalternativ. Ingen av dem bestämmer din bevarandepolicy åt dig.

Testa en rotation och en ny händelse

Tvinga fram en enda rotation och generera sedan en ny händelse, till exempel en misslyckad autentisering. Bekräfta att den nya posten visas i den nya filen och att den gamla filen slutade växa.

Kontrollera också rättigheterna på den nya filen, eftersom en rotation som återskapar den med en annan ägare bryter skrivaren vid nästa skrivning och ger en lucka som ser ut som en krasch. Jämför ägare och läge med tjänstekontot innan du går. Bekräfta sedan att det komprimerade arkivet är läsbart, eftersom ett arkiv ingen kan öppna inte är bevarande. En snabb läsning av den nyaste posten i den gamla filen bevisar både komprimeringen och rättigheterna.

Avsluta med att anteckna ägaren för varje steg: vilken komponent som skriver, vilken som roterar och var bevarandepolicyn bor. Den anteckningen gör nästa loggningsincident till en femminuterskontroll i stället för en eftermiddag av gissningar om vilket lager som tappade raden.