Wie besit OpenVPN se logboeke: die daemon, rsyslog of logrotate?

Logrotasie breek op 'n voorspelbare manier: drie komponente meen elkeen dat hy die lêer besit, en die gevolg is 'n geroteerde log wat aanhou groei terwyl die nuwe een leeg bly. Die daemon hou 'n descriptor, logrotate hernoem die pad, en rsyslog skryf heeltemal elders. Kies een skrywer en een roteerder voordat jy nog 'n reël by die stapel voeg. Die kontrolelys hieronder beweeg in daardie orde, want elke latere stap hang daarvan af.

Bepaal wie skryf die lêer

Twee ontwerpe is geldig. In die eerste skryf die VPN-proses self 'n lêer deur sy eie log- of log-append-opsie. In die tweede stuur hy rekords na die stelsellogger en rsyslog of journald besluit waar hulle beland.

Hulle is alternatiewe, nie lae nie. 'n Gasheer wat albei aktiveer, eindig met twee lêers wat van mekaar verskil, en die een wat jy lees is dikwels die verouderde een. Kies die pad doelbewus en verwyder dan die ander skrywer.

Lees die effektiewe dienskonfigurasie voordat jy enigiets verander, insluitend drop-ins wat die eenheidslêer kan oorheers. 'n Direktief in die profiel wat jy geredigeer het, is nie bewys dat dit die een is wat die lopende proses gelaai het nie. Vergelyk die eenheid met die prosesargumente en dan met die lêers wat dit werklik oopgemaak het.

Noem die daemon sodat die filter smal kan wees

Op die syslog-pad gee jy die daemon 'n eie identiteit en filter op hom. 'n Reël wat by die programnaam van hierdie VPN-instansie pas, hou sy rekords uit 'n gedeelde lêer waarvan die bewaarbeleid aan iets anders behoort.

Smal reëls maak ook die volgende vraag beantwoordbaar: watter diens het hierdie reël geproduseer? 'n Filter wat alles met die woord VPN daarin pas, sal gretig 'n tweede tonnel se verkeer insamel en albei vervaag. Pas op die presiese identifiseerder wat die eenheid aan die logger gee.

Sluit die reël ná die aksie, sodat die rekords nie ook na die verstekbestemming deurval nie. Dubbele reëls in twee lêers lyk soos 'n logfout en is eintlik 'n ontbrekende stop. Daardie enkele weglating verdubbel ook die skyfkoste van die bewaarbeleid.

Roteer sonder om die descriptor te verloor

Wanneer die daemon die lêer skryf, hernoem logrotate die pad, maar die proses hou sy oop descriptor. Nuwe rekords gaan voort in die hernoemde lêer totdat iets die proses die oorspronklike pad laat heropen, en daarom kan 'n rotasie werk lyk terwyl die nuwe lêer leeg bly.

Die oplossing is 'n postrotate-aksie wat die diens se gedokumenteerde herlaai- of herbegin-gedrag aktiveer. Om die logger 'n sein te stuur is heeltemal 'n ander aksie en doen niks vir 'n daemon wat sy eie lêer hou nie.

Waar 'n heropening onmoontlik is, is copytruncate die terugval: kopieer die lêer en kort dit dan in plek in. Dit hou die descriptor geldig ten koste van alles wat tussen die kopie en die korting geskryf is, dus dit is 'n ruil eerder as 'n oplossing. Onder las kan daardie gaping juis die fout insluk wat jy probeer vasvang.

Kies een van die twee per lêer en skryf die keuse neer, want om hulle op dieselfde pad te meng lewer gapings wat later baie moeilik toeskryfbaar is. 'n Leser wat albei patrone in een gids vind, kan nie sê watter een gesaghebbend is nie.

Stel bewaar uit die voorvalvenster

Bewaring, kompressie en maksimum grootte behoort te volg uit hoe ver terug jy werklik ondersoek. 'n Venster van sewe dae met kompressie en 'n grootteperk is 'n redelike vertrekpunt vir baie ontplooiings; 'n getal uit 'n handleiding gekopieer is nie.

Hou die beleid op een plek. As logrotate die lêer roteer en rsyslog dit ook roteer, wen die tweede rotasie en die eerste se naamskema oorleef as rommel. Kies die eienaar, skakel die ander rotasie af, en noteer daardie besluit langs die beleid.

Die rsyslog-dokumentasie dek sy roetering- en aksiemodel, terwyl die OpenVPN-diensdokumentasie gesaghebbend bly vir die daemon se eie log-opsies. Nie een van die twee besluit jou bewaarbeleid vir jou nie.

Toets een rotasie en een nuwe gebeurtenis

Forseer 'n enkele rotasie en genereer dan een nuwe gebeurtenis, soos 'n mislukte verifikasie. Bevestig dat die nuwe rekord in die nuwe lêer verskyn en dat die ou lêer opgehou groei het.

Kyk ook na die regte op die nuwe lêer, want 'n rotasie wat dit met 'n ander eienaar herskep, breek die skrywer by die volgende skryf en lewer 'n gaping wat soos 'n ineenstorting lyk. Vergelyk die eienaar en modus met die diensrekening voordat jy wegstap. Bevestig dan dat die saamgeperste argief leesbaar is, want 'n argief wat niemand kan oopmaak nie, is nie bewaring nie. 'n Vinnige lees van die nuutste rekord in die ou lêer bewys beide die kompressie en die regte.

Sluit af deur die eienaar van elke stap op te teken: watter komponent skryf, watter roteer, en waar die bewaarbeleid woon. Daardie rekord is wat die volgende logvoorval in 'n vyf-minute-kontrole verander in plaas van 'n middag se raai watter laag die reël laat val het.