Kam pieder OpenVPN žurnāli: dēmonam, rsyslog vai logrotate?

Žurnālu rotācija sabrūk paredzamā veidā: trīs komponenti katrs uzskata, ka tam pieder fails, un rezultāts ir rotēts žurnāls, kas turpina augt, kamēr jaunais paliek tukšs. Dēmons tur deskriptoru, logrotate pārdēvē ceļu, un rsyslog raksta pavisam citur. Izvēlieties vienu rakstītāju un vienu rotatoru, pirms pievienojat kaudzei vēl vienu noteikumu. Zemāk esošais kontrolsaraksts virzās tieši šajā secībā, jo katrs nākamais solis no tā ir atkarīgs.

Izlemiet, kas raksta failu

Divi risinājumi ir likumīgi. Pirmajā VPN process pats raksta failu, izmantojot savu log vai log-append opciju. Otrajā tas sūta ierakstus sistēmas žurnālam, un rsyslog vai journald izlemj, kur tie nonāks.

Tās ir alternatīvas, nevis slāņi. Resursdators, kas ieslēdz abus, beigās iegūst divus failus, kas nesaskan, un tas, ko jūs lasāt, bieži ir novecojis. Izvēlieties ceļu apzināti un pēc tam noņemiet otru rakstītāju.

Pirms kaut ko maināt, izlasiet pakalpojuma spēkā esošo konfigurāciju, tostarp drop-in failus, kas var pārrakstīt unit failu. Rediģētajā profilā esošā direktīva nav pierādījums, ka tā ir tā, ko ielādēja darbojošais process. Salīdziniet unit ar procesa argumentiem un pēc tam ar failiem, ko tas faktiski atvēra.

Nosauciet dēmonu, lai filtrs varētu būt šaurs

syslog ceļā piešķiriet dēmonam atsevišķu identitāti un filtrējiet pēc tās. Noteikums, kas atbilst šīs VPN instances programmas nosaukumam, tur tās ierakstus ārpus koplietota faila, kura saglabāšanas politika pieder kam citam.

Šauri noteikumi arī ļauj atbildēt uz nākamo jautājumu: kurš pakalpojums radīja šo rindu? Filtrs, kas atbilst visam, kurā ir vārds VPN, labprāt savāks otrā tuneļa datplūsmu un izplūdīs abus. Saskaņojiet ar precīzo identifikatoru, ko unit nodod žurnālam.

Aizveriet noteikumu pēc darbības, lai ieraksti neiekristu arī noklusējuma galamērķī. Atkārtotas rindas divos failos izskatās kā reģistrēšanas kļūda, bet patiesībā tā ir trūkstoša apstāšanās. Šis viens izlaidums arī dubulto saglabāšanas politikas diska izmaksas.

Rotējiet, nezaudējot deskriptoru

Kad dēmons raksta failu, logrotate pārdēvē ceļu, bet process saglabā savu atvērto deskriptoru. Jaunie ieraksti turpina nonākt pārdēvētajā failā, līdz kaut kas liek procesam no jauna atvērt sākotnējo ceļu; tāpēc rotācija var izskatīties strādājoša, kamēr jaunais fails paliek tukšs.

Risinājums ir postrotate darbība, kas iedarbina pakalpojuma dokumentēto pārlādes vai restartēšanas uzvedību. Signāla sūtīšana žurnālam ir pavisam cita darbība un neko nedara dēmonam, kas tur savu failu.

Kur atkārtota atvēršana nav iespējama, copytruncate ir rezerves variants: nokopējiet failu un pēc tam nogrieziet to uz vietas. Tas saglabā deskriptoru derīgu, taču tiek zaudēts viss, kas ierakstīts starp kopēšanu un griešanu, tāpēc tie ir mainīti, nevis risinājums. Slodzes laikā šī plaisa var aprīt tieši to kļūmi, ko mēģināt noķert.

Katram failam izvēlieties vienu no diviem un pierakstiet izvēli, jo to sajaukšana vienā ceļā rada plaisas, kuras vēlāk ir ļoti grūti piedēvēt. Lasītājs, kas vienā direktorijā atrod abus modeļus, nevar pateikt, kurš ir noteicošais.

Saglabāšanu iestatiet pēc incidenta loga

Saglabāšanai, saspiešanai un maksimālajam izmēram jāizriet no tā, cik tālu atpakaļ jūs patiešām pētāt. Septiņu dienu logs ar saspiešanu un izmēra ierobežojumu ir saprātīgs sākumpunkts daudzām ieviešanām; skaitlis, kas nokopēts no apmācības, tāds nav.

Turiet politiku vienā vietā. Ja logrotate rotē failu un rsyslog arī to rotē, uzvar otrā rotācija, un pirmās nosaukumu shēma paliek kā nekārtība. Izvēlieties īpašnieku, izslēdziet otru rotāciju un pierakstiet šo lēmumu blakus politikai.

rsyslog dokumentācija aptver tā maršrutēšanas un darbību modeli, savukārt OpenVPN pakalpojuma dokumentācija paliek noteicošā dēmona paša reģistrēšanas opcijām. Neviena no tām neizlemj jūsu saglabāšanas politiku jūsu vietā.

Pārbaudiet vienu rotāciju un vienu jaunu notikumu

Piespiediet vienu rotāciju un pēc tam ģenerējiet vienu jaunu notikumu, piemēram, neveiksmīgu autentifikāciju. Apstipriniet, ka jaunais ieraksts parādās jaunajā failā un ka vecais fails pārstāja augt.

Pārbaudiet arī jaunā faila atļaujas, jo rotācija, kas to izveido no jauna ar citu īpašnieku, salauž rakstītāju nākamajā rakstīšanā un rada plaisu, kas izskatās kā avārija. Pirms aiziešanas salīdziniet īpašnieku un režīmu ar pakalpojuma kontu. Pēc tam apstipriniet, ka saspiestais arhīvs ir lasāms, jo arhīvs, ko neviens nevar atvērt, nav saglabāšana. Ātra jaunākā ieraksta izlasīšana vecajā failā pierāda gan saspiešanu, gan atļaujas.

Pabeidziet, pierakstot katra soļa īpašnieku: kura komponente raksta, kura rotē un kur dzīvo saglabāšanas politika. Tieši šis pieraksts pārvērš nākamo reģistrēšanas incidentu piecu minūšu pārbaudē, nevis pēcpusdienā, kad jāmin, kurš slānis pazaudēja rindu.