Хто валодае журналамі OpenVPN: дэман, rsyslog ці logrotate?

Ратацыя журналаў ламаецца прадказальным чынам: тры кампаненты лічаць, што валодаюць файлам, і вынікам з'яўляецца паварочны журнал, які працягвае расці, пакуль новы застаецца пустым. Дэман трымае дэскрыптар, logrotate пераймяноўвае шлях, а rsyslog піша зусім у іншае месца. Выберыце аднаго запісвальніка і аднаго рататара, перш чым дадаваць яшчэ адно правіла ў стос. Спіс праверак ніжэй ідзе менавіта ў такім парадку, бо кожны наступны крок залежыць ад яго.

Вырашыце, хто піша файл

Ёсць два правільныя варыянты. У першым працэс VPN сам піша файл праз сваю опцыю log або log-append. У другім ён адпраўляе запісы ў сістэмны лагер, і rsyslog або journald вырашае, дзе яны апынуцца.

Гэта альтэрнатывы, а не слаі. Хост, які ўключае абодва, атрымлівае два файлы, якія не супадаюць, і той, які вы чытаеце, часта састарэлы. Выберыце шлях свядома, затым выдаліце іншага запісвальніка.

Прачытайце дзейную канфігурацыю службы, перш чым нешта змяняць, уключаючы drop-in файлы, якія могуць перавызначыць юніт. Дырэктыва, наяўная ў профілі, які вы адрэдагавалі, не з'яўляецца доказам, што гэта тая, якую загрузіў запушчаны працэс. Параўнайце юніт з аргументамі працэса, а затым з файламі, якія ён фактычна адкрыў.

Назвіце дэмана, каб фільтр быў вузкім

На шляху праз syslog дайце дэману асобную ідэнтычнасць і фільтруйце па ёй. Правіла, якое супадае з імем праграмы гэтага асобніка VPN, трымае яго запісы па-за агульным файлам, палітыка захавання якога належыць чамусьці іншаму.

Вузкія правілы таксама робяць адказна наступнае пытанне: якая служба спарадзіла гэты радок? Фільтр, які супадае з усім, дзе ёсць слова VPN, ахвотна збярэ трафік другога тунэля і размые абодва. Супастаўляйце па дакладным ідэнтыфікатары, які юніт перадае лагеру.

Зачыніце правіла пасля дзеяння, каб запісы не падалі таксама ў прадвызначанае прызначэнне. Дубліраваныя радкі ў двух файлах выглядаюць як памылка лагрыравання, а насамрэч гэта адсутная прыпынак. Гэтае адзінае ўпушчэнне таксама падвойвае дыскавы кошт палітыкі захавання.

Ратуйце, не губляючы дэскрыптар

Калі дэман піша файл, logrotate пераймяноўвае шлях, але працэс захоўвае свой адкрыты дэскрыптар. Новыя запісы працягваюць ісці ў перайменаваны файл, пакуль нешта не прымусіць працэс паўторна адкрыць зыходны шлях; менавіта таму ратацыя можа выглядаць працоўнай, пакуль новы файл застаецца пустым.

Рашэнне — дзеянне postrotate, якое запускае дакументаваныя паводзіны перазагрузкі або перазапуску службы. Пасылка сігналу лагеру — зусім іншае дзеянне і нічога не робіць для дэмана, які трымае ўласны файл.

Там, дзе паўторнае адкрыццё немагчымае, copytruncate — запасны варыянт: скапіруйце файл, затым абрэжце яго на месцы. Ён захоўвае дэскрыптар сапраўдным, але губляе ўсё запісанае паміж капіраваннем і абрэзкай, таму гэта абмен, а не рашэнне. Пад нагрузкай гэтая шчыліна можа праглынуць менавіта той збой, які вы спрабуеце злавіць.

Выберыце адзін з двух на кожны файл і запішыце выбар, бо змешванне іх на адным шляху стварае шчыліны, якія потым вельмі цяжка аднесці да пэўнай прычыны. Чытач, які знойдзе абодва ўзоры ў адной дырэкторыі, не зможа сказаць, які з іх галоўны.

Задайце захаванне ад акна інцыдэнту

Захаванне, сцісканне і максімальны памер павінны вынікаць з таго, наколькі глыбока вы сапраўды даследуеце. Акно ў сем дзён са сцісканнем і абмежаваннем памеру — разумная адпраўная кропка для многіх разгортванняў; лічба, скапіраваная з падручніка, — не.

Трымайце палітыку ў адным месцы. Калі logrotate паварочвае файл і rsyslog таксама яго паварочвае, перамагае другая ратацыя, а схема імёнаў першай застаецца як смецце. Выберыце ўладальніка, адключыце іншую ратацыю і запішыце гэта рашэнне побач з палітыкай.

Дакументацыя rsyslog апісвае яго мадэль маршрутызацыі і дзеянняў, а дакументацыя службы OpenVPN застаецца аўтарытэтнай для ўласных опцый лагрыравання дэмана. Ні адна з іх не вырашае вашу палітыку захавання за вас.

Праверце адну ратацыю і адну новую падзею

Прымусьце адну ратацыю, затым стварыце адну новую падзею, напрыклад няўдалую аўтэнтыфікацыю. Пераканайцеся, што новы запіс з'явіўся ў новым файле і што стары файл перастаў расці.

Праверце таксама правы на новым файле, бо ратацыя, якая стварае яго з іншым уладальнікам, ламае запісвальніка пры наступным запісе і стварае шчыліну, падобную на збой. Параўнайце ўладальніка і рэжым з уліковым запісам службы, перш чым сысці. Затым пераканайцеся, што сціснуты архіў чытэльны, бо архіў, які ніхто не можа адкрыць, не з'яўляецца захаваннем. Хуткае чытанне найноўшага запісу ў старым файле даказвае і сцісканне, і правы.

Скончыце запісам уладальніка кожнага кроку: які кампанент піша, які паварочвае і дзе жыве палітыка захавання. Менавіта гэты запіс ператварае наступны інцыдэнт лагрыравання ў пяціхвілінную праверку замест паўдня здагадак, які слой страціў радок.