Журнал LinuxFormat - перейти на главную

LXF159:Сисадминам

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Пе­ре­на­прав­ление)
(Пе­ре­на­прав­ление)
Строка 134: Строка 134:
 
{| class="wikitable" style="float:right; margin-left:0.8em; width:50%"
 
{| class="wikitable" style="float:right; margin-left:0.8em; width:50%"
 
|-
 
|-
| Текст ячейки
+
| ИМЯ МОДУЛЯ
| Текст ячейки
+
| ОПИСАНИЕ
 
|-
 
|-
| Текст ячейки
+
|IMUXSOCK
| Текст ячейки
+
| Слу­ша­ет до­мен­ный со­кет unix /dev/log (тра­ди­ци­он­ное по­ве­де­ние syslog)
 
|-
 
|-
| Текст ячейки
+
| IMTC
| Текст ячейки
+
| Слу­ша­ет со­об­ще­ния, пе­ре­на­прав­ляе­мые по TCP-со­еди­не­нию
 +
|-
 +
| IMUDP
 +
|  Слу­ша­ет со­об­ще­ния, пе­ре­на­прав­ляе­мые по UDP-со­еди­не­нию (тра­ди­ци­он­ное по­ве­де­ние syslog)
 +
|-
 +
|  IMKLOG
 +
| Слу­ша­ет со­об­ще­ния яд­ра
 +
|-
 +
|  IMRELP
 +
|  Слу­ша­ет со­об­ще­ния по на­деж­но­му про­то­ко­лу RELP
 +
|-
 +
|  IMFILE
 +
|  Бе­рет со­об­ще­ния из фай­ла
 +
|-
 +
|OMRELP
 +
|Пе­ре­на­прав­ля­ет со­об­ще­ния с ис­поль­зо­ва­ни­ем про­то­ко­ла RELP
 +
|-
 +
|OMRELP
 +
|Пе­ре­на­прав­ля­ет со­об­ще­ния с ис­поль­зо­ва­ни­ем про­то­ко­ла RELP
 +
|-
 +
|OMMYSQL
 +
|От­прав­ля­ет (важ­ные) со­об­ще­ния по элек­трон­ной поч­те
 +
|-
 +
|OMPROG
 +
|От­прав­ля­ет со­об­ще­ния за­дан­ной внеш­ней про­грам­ме для спе­ци­аль­ной об­ра­бот­ки
 
|}
 
|}
  

Версия 03:35, 23 сентября 2018

Содержание

Сисадминам

(thumbnail)
Д-р Крис Браун Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.

По рецептам доктора Брауна

Эзо­те­ри­че­ское сис­тем­ное ад­ми­ни­ст­ри­ро­ва­ние из при­чуд­ли­вых за­во­ро­тов ки­шок сер­вер­ной


Же­ле­зо как сер­вис

(thumbnail)
До­маш­няя стра­ни­ца ин­тер­фей­са поль­зо­ва­теля MAAS с од­ним за­ре­ги­ст­ри­ро­ван­ным ком­пь­ю­те­ром.

В по­следнем Ubuntu Server поя­ви­лось MAAS, сред­ст­во инициа­ли­за­ции сер­ве­ров, при­зван­ное уп­ро­стить жизнь ад­минист­ра­то­рам круп­ных да­та-цен­тров.

Когда вы бу­де­те это чи­тать, вый­дет Ubuntu 12.04. Этот ре­лиз осо­бен­но ва­жен, по­то­му что он «с дол­го­сроч­ной под­держ­кой» (5 лет). Я уве­рен, что кри­ти­кам не тер­пит­ся на­ки­нуть­ся на на­столь­ную вер­сию, и по­ду­мал, что мо­гу вкрат­це рас­смот­реть сер­вер­ную. Марк Шатт­л­ворт [Mark Shuttleworth] уве­ря­ет, что «круп­ные ком­па­нии ста­да­ми пе­ре­хо­дят на Ubuntu с RHEL» (убеди­тель­ный гра­фик – на http://www.markshuttleworth.com/archives/1072). В той же ста­тье он го­во­рит: «12.04 LTS – со­зрев­ший Ubuntu для да­та-цен­тров».

И я ска­чал днев­ную сбор­ку – по­про­бо­вать. Ме­ня боль­ше все­го при­влек­ла но­вая ути­ли­та MAAS (со­кра­щение от «Metal As A Service», Же­ле­зо как сер­вис) – для раз­вер­ты­вания боль­шо­го ко­ли­че­­ст­ва фи­зи­че­­ских сер­ве­ров и управ­ления ими. Идея тут в том, что­бы инициа­ли­зи­ро­вать фи­зи­че­­ские сер­ве­ры по тре­бо­ванию в нуж­ном ко­ли­че­­ст­ве. В уста­нов­щи­ке на CD сер­вер­ной вер­сии мож­но лег­ко соз­дать сер­вер MAAS. Он уста­нав­ли­ва­ет ра­бо­чую сис­те­му, а так­же несколь­ко до­ба­воч­ных сер­ви­сов в под­держ­ку MAAS, в том чис­ле Cobbler и Apache (у MAAS есть web-ин­тер­фейс поль­зо­ва­теля).

При уста­нов­ке мож­но так­же свя­зать но­вый ком­пь­ю­тер с су­ще­ст­вую­щим сер­ве­ром MAAS: сис­те­ма от­прав­ля­ет за­прос на ре­ги­ст­ра­цию в MAAS, за­тем вы­клю­ча­ет­ся и мо­жет быть за­гру­же­на сно­ва сер­ве­ром MAAS с по­мо­щью PXE. По­сле ре­ги­ст­ра­ции сис­те­мы ее мож­но за­пустить с панели управ­ления MAAS (ес­ли в сис­те­ме вклю­че­но Wake on LAN) и за­гру­зить че­рез PXE, по­сле че­го до­ба­вить ее в оче­редь на ди­на­ми­че­­ское вы­де­ление сер­ви­сов или раз­вер­нуть на ней Ubuntu 12.04. Мой экс­пе­ри­мент был ог­раничен – долж­ное тес­ти­ро­вание сис­те­мы тре­бу­ет несколь­ких со­т ком­пь­ю­те­ров. До­ку­мен­та­цию по сис­те­ме мож­но най­ти на https://wiki.ubuntu.com/ServerTeam/MAAS, но она сы­ровата.

Три уров­ня

На­зва­ние MAAS ­– рас­ши­ре­ние обыч­ной клас­си­фи­ка­ции для об­лач­ных вы­чис­ле­ний, ко­то­рая оп­ре­де­ля­ет три уров­ня сер­ви­са:

» IAAS (Infrastructure As A Service – ин­фра­струк­ту­ра как сер­вис) – на нем раз­вер­ты­ва­ет­ся (вир­ту­аль­ное) «же­ле­зо».

» PAAS (Platform As A Service – плат­фор­ма как сер­вис) – на нем вы раз­ме­щае­те свои мас­шта­би­руе­мые при­ло­же­ния.

» SAAS (Software As A Service – про­грам­ма как сер­вис) – здесь ис­поль­зу­ют­ся web-при­ло­же­ния.

> До­маш­няя стра­ни­ца ин­тер­фей­са поль­зо­ва­теля MAAS с од­ним за­ре­ги­ст­ри­ро­ван­ным ком­пь­ю­те­ром.

rsyslog

Поч­тен­ный syslog дол­гие го­ды за­ни­мал­ся жур­на­ли­ро­ва­ни­ем в UNIX и Linux. При­шед­ший на за­ме­ну rsyslog при­нес ре­ше­ние уров­ня пред­при­ятия для жур­на­ли­ро­ва­ния в Linux.

(thumbnail)
На­бор «уст­ройств» по­ка­зы­ва­ет, от­ку­да при­шло со­об­ще­ние. Со­об­ще­ния ти­па ‘kern’ по­зво­ле­но от­прав­лять толь­ко яд­ру.

Для до­ку­мен­ти­ро­вания сво­их дей­ст­вий боль­шин­ст­во сер­ви­сов генери­ру­ют со­об­щения. Лишь немно­гие из них, та­кие как X-сер­вер, Apache и Samba, за­пи­сы­ва­ют их в соб­ст­вен­ные лог-фай­лы – для боль­шин­ст­ва из них «ин­фор­ма­ци­он­ным цен­тром» жур­на­ли­ро­вания вы­сту­па­ет де­мон syslog. Лог-фай­лы, или фай­лы жур­на­лов – не са­мая ув­ле­ка­тель­ная со­став­ляю­щая Linux, кро­ме тех ред­ких слу­ча­ев, когда в них за­пи­са­на ис­то­рия по­пыт­ки взло­ма или па­дения сер­ве­ра. Но 99,9 % вре­мени они скуч­ны. Ад­минист­ра­то­ры не при­хо­дят на ра­бо­ту с ши­ро­ки­ми улыб­ка­ми на ли­цах: они зна­ют, что ско­ро за­ся­дут в тер­ми­на­ле, ув­ле­чен­но чи­тая по­следний вы­пуск /var/log/messages.

Но внут­ри ти­хо ра­бо­та­ет боль­шой ме­ханизм генера­ции, ро­та­ции и ана­ли­за лог-фай­лов. Де­мон syslogd, ко­то­рый мож­но най­ти в ранних ди­ст­ри­бу­ти­вах Linux, ис­поль­зо­вал­ся дол­го. Он был в UNIX и, мно­го лет, в ранних ди­ст­ри­бу­ти­вах Linux. Сер­вис от­прав­лял свои со­об­щения syslogd, и тот (под управ­лением фай­ла кон­фи­гу­ра­ции) за­пи­сы­вал их в файл или пе­ре­на­прав­лял их syslogd на дру­гом, цен­траль­ном «хосте ло­ги­ро­вания». Со вре­менем про­то­кол syslog стал стан­дар­том де-фак­то; он ис­поль­зу­ет­ся в ро­уте­рах и ком­му­та­то­рах Cisco и да­же под­дер­жи­ва­ет­ся сто­ронними ути­ли­та­ми в Windows.

За по­следние го­ды поя­ви­лось несколь­ко за­мен syslogd. Пер­вым был syslog-ng, ко­то­рый ур­вал свою па­ру лет по­пу­ляр­но­сти, осо­бен­но в SUSE Linux. За­тем при­шел rsyslog. В от­ли­чие от syslog-ng, у ко­то­ро­го был но­вый и слож­ный файл кон­фи­гу­ра­ции, rsyslog об­рат­но-со­вмес­тим с прежним syslog (и то, и дру­гое ка­са­ет­ся про­то­ко­ла syslog и фай­ла кон­фи­гу­ра­ции), и, ве­ро­ят­но, по­это­му его при­ня­ли вро­де бы луч­ше. Он при­ме­ня­ет­ся по умол­чанию в Fedora, Red Hat, Debian, Ubuntu и да­же в по­следних вер­си­ях OpenSUSE. Rsyslog – де­ти­ще Райнера Гер­хар­дса [Rainer Gerhards].

В на­ча­ле был syslog...

(thumbnail)
Со­об­ще­ния от ло­каль­ных сер­ви­сов (или от уда­лен­но­го rsyslog) на­прав­ля­ют­ся по ме­сту на­зна­че­ния на ос­но­ве пра­вил из /etc/rsyslog.conf.

Так как rsyslog об­рат­но со­вмес­тим с бо­лее ста­рым syslog, спер­ва изу­чим ра­бо­ту syslog, а за­тем рас­смот­рим неко­то­рые но­вые воз­мож­но­сти rsyslog. Де­мон rsyslog слу­ша­ет на до­мен­ном со­ке­те UNIX /dev/log. При­ло­жения под­клю­ча­ют­ся к нему и от­прав­ля­ют свои со­об­щения, по­ме­чае­мые при­ори­те­том. При­ори­тет – это со­че­тание ин­фор­ма­ции об уст­рой­ст­ве (от­ку­да при­шло со­об­щение) и серь­ез­но­сти со­об­щения (на­сколь­ко оно важ­но). Су­ще­ст­ву­ет фик­си­ро­ван­ный спи­сок уровней серь­ез­но­сти, по­ка­зан­ный на ри­сун­ке. Вы ви­ди­те, что спи­сок немно­го уста­рел – осо­бен­но на при­ме­ре uucp (для тех чи­та­те­лей, кто еще не достиг пен­си­он­но­го воз­рас­та, по­яс­няю, что uucp – со­кра­щение от «Unix to Unix copy [ко­пи­ро­вание с Unix на Unix]» – так на­зы­ва­лась про­грам­ма для пе­ре­сыл­ки фай­лов ме­ж­ду ком­пь­ю­те­ра­ми по ком­му­ти­руе­мо­му со­единению. Что­бы вы осоз­на­ли ее древ­ность, ска­жу, что она при­ме­ня­лась в линиях свя­зи еще до про­то­ко­ла TCP/IP. Но я от­клонил­ся от те­мы). Так­же есть по­сто­ян­ный, упо­ря­до­чен­ный спи­сок уровней серь­ез­но­сти от «от­ла­доч­но­го [debug]» до «кри­ти­че­­ско­­го [emergency]». На ри­сун­ке я по­пы­тал­ся обо­зна­чить со­бы­тия для ка­ж­до­го уров­ня, хо­тя, на­сколь­ко я знаю, точ­ных фор­маль­ных пра­вил клас­си­фи­ка­ции со­бы­тий по уров­ням нет.

Че­ты­ре дей­ст­вия

При­ори­те­ту ка­ж­до­го со­об­щения со­от­вет­ст­ву­ет на­бор пра­вил в фай­ле на­строй­ки rsyslog (/etc/rsyslog.conf и/или фай­лы в ка­та­ло­ге /etc/rsyslog.d), и со­об­щение от­прав­ля­ет­ся в лю­бое ме­сто на­зна­чения, ука­зан­ное в со­от­вет­ст­вую­щем пра­ви­ле. Обыч­ный syslogd уме­ет вы­пол­нять с со­об­щением че­ты­ре дей­ст­вия: за­пи­сать его в файл (са­мое рас­про­странен­ное дей­ст­вие), пе­ре­на­пра­вить его де­мо­ну syslog на дру­гом ком­пь­ю­те­ре, вы­вес­ти его на тер­ми­нал поль­зо­ва­те­ля, во­шед­ше­го в сис­те­му, и от­клонить его (это про­ис­хо­дит, ес­ли со­об­щение не со­от­вет­ст­ву­ет ни од­но­му из пра­вил). Тре­тий ва­ри­ант обыч­но ре­зер­ви­ру­ет­ся для очень важ­ных со­об­щений, но никогда не ка­зал­ся мне осо­бен­но удоб­ным. Ес­ли сис­тем­ный ад­минист­ра­тор ти­хо си­дит в тер­ми­на­ле и ждет его по­яв­ления, все пре­крас­но. Так мож­но по­сту­пить с cообщениями вро­де «сис­те­ма ско­ро бу­дет вы­клю­че­на»; но в осталь­ных слу­ча­ях это не луч­ший спо­соб при­влечь чье-то внимание.

Настала по­ра при­во­дить при­ме­ры. Вот за­пи­си из файла rsyslog.conf в Fedora 15:

(thumbnail)
Уров­ни серь­ез­но­сти со­об­ще­ний за­да­ют­ся зна­че­ния­ми из упо­ря­до­чен­но­го спи­ска. Точ­но­го оп­ре­де­ле­ния то­го, ка­кие со­бы­тия от­но­сят­ся к ка­ким уров­ням, нет.

authpriv.* /var/log/secure

uucp,news.crit /var/log/spooler

  • .info;mail.none;authpriv.none /var/log/messages

В ле­вой час­ти ка­ж­до­го пра­ви­ла опи­сы­ва­ют­ся уст­рой­ст­во и уро­вень серь­ез­но­сти со­об­щения. Пер­вая стро­ка оз­на­ча­ет, что со­об­щения (всех уровней серь­ез­но­сти) уст­рой­ст­ва authpriv бу­дут до­бав­ле­ны в лог-файл /var/log/secure. Вто­рая стро­ка оз­на­ча­ет, что со­об­щения от уст­ройств uucp и news уров­ня серь­ез­но­сти crit или вы­ше бу­дут до­бав­ле­ны в /var/log/spooler. По­след­няя стро­ка от­прав­ля­ет со­об­щения уров­ня info или вы­ше от всех уст­ройств, кро­ме mail и authpriv, в /var/log/messages. Файл /var/log/messages – это «мас­тер на все ру­ки»: боль­шин­ст­во «обыч­ных» со­об­щений ока­зы­ва­ет­ся здесь.

На­при­мер, со­об­щения обыч­но за­пи­сы­ва­ют­ся в локаль­ный файл, а так­же пе­ре­на­прав­ля­ют­ся на за­щи­щен­ный «хост жур­на­ли­ро­вания». Та­кая цен­тра­ли­за­ция лог-фай­лов име­ет ряд пре­иму­ществ. Во-пер­вых, так про­ще со­брать и про­ана­ли­зи­ро­вать лог-фай­лы с несколь­ких ком­пь­ю­те­ров. Во-вто­рых, это услож­ня­ет за­ме­тание сле­дов ква­ли­фи­ци­ро­ван­но­му взлом­щи­ку, умеющему уда­лять сле­ды сво­ей дея­тель­но­сти из лог-фай­лов (по­скольку ему при­дет­ся взла­мы­вать также и хост ло­ги­ро­вания). На­при­мер, доста­точ­но до­ба­вить стро­ку:

authpriv.* @jupiter

и со­об­щения уст­рой­ст­ва authpriv бу­дут пе­ре­на­прав­лять­ся на ком­пь­ю­тер jupiter.

...а по­том был rsyslog

Ис­то­рия, ко­то­рую я рас­ска­зал, от­но­сит­ся к ста­ро­му де­мо­ну syslog, и она имела бы хождение и 25 лет на­зад. Те­перь рас­смот­рим неко­то­рые до­бавоч­ные воз­мож­но­сти, пре­достав­ляе­мые rsyslog:

» Со­об­щения мож­но от­фильт­ро­вы­вать (вы­би­рать) по их со­дер­жи­мо­му, вклю­чая по­иск по ре­гу­ляр­ным вы­ра­жениям

» Со­об­щения мож­но от­пра­вить в ба­зу дан­ных, та­кую как MySQL или PostgreSQL

» Со­об­щения мож­но пе­ре­на­прав­лять по про­то­ко­лу TCP (ис­ход­ный syslog ис­поль­зо­вал UDP, ко­то­рый не га­ран­ти­ру­ет достав­ку со­об­щений). Тра­фик так­же мож­но за­шиф­ро­вать с по­мо­щью SSL (secure sockets layers)

» Со­об­щения мож­но от­прав­лять по элек­трон­ной поч­те (пред­на­зна­че­но толь­ко для сроч­ных опо­ве­щений).

При пе­ре­на­прав­лении со­об­щений на сер­вер ба­зы дан­ных или дру­го­му syslog мож­но ука­зать ре­зерв­ные сер­ве­ры, ко­то­рые бу­дут ис­поль­зо­ва­ны, ес­ли основ­ной вый­дет из строя.

Бо­лее длин­ный спи­сок име­ет­ся на сай­те www.rsyslog.com/doc/features.html. Вме­сте все эти до­полнения де­ла­ют rsyslog сред­ст­вом жур­на­ли­ро­вания про­мыш­лен­но­го уров­ня. Ра­зу­ме­ет­ся, это оплачива­ет­ся бо­лее развесистым син­так­си­сом фай­ла на­строй­ки.

Рас­смот­рим неко­то­рые из этих воз­мож­но­стей.

Пре­ж­де все­го, в rsyslog ис­поль­зу­ет­ся мо­дуль­ная ар­хи­тек­ту­ра. Для за­груз­ки нуж­ных мо­ду­лей с необ­хо­ди­мы­ми воз­мож­но­стя­ми ука­жи­те со­от­вет­ст­вую­щие ди­рек­ти­вы в rsyslog.conf. На­при­мер, в верхней час­ти фай­ла rsyslog.conf вы, ве­ро­ят­но, уви­ди­те та­кие ди­рек­ти­вы:

$ModLoad imuxsock

$ModLoad imklog

В пер­вой стро­ке за­гру­жа­ет­ся мо­дуль вво­да со­ке­та UNIX, ко­то­рый принима­ет со­об­щения от локаль­ных сер­ви­сов. Про­слу­ши­вание до­мен­но­го со­ке­та UNIX /dev/log – тра­ди­ци­он­ное по­ве­дение syslog. Ес­ли не за­гру­зить этот мо­дуль, rsyslog не бу­дет слу­шать локаль­ные со­об­щения. Во вто­рой стро­ке за­гру­жа­ет­ся мо­дуль под­держ­ки жур­на­ли­ро­вания яд­ра. Су­ще­ст­ву­ют и мно­гие дру­гие мо­ду­ли – неко­то­рые из них при­ве­де­ны в таб­ли­це.

Пе­ре­на­прав­ление

Как и syslog до него, rsyslog мо­жет от­прав­лять со­об­щения уда­лен­но­му rsyslog, что­бы все лог-фай­лы мож­но бы­ло со­брать в од­ном мес­те. Ес­ли ука­зать в rsyslog.conf на цен­траль­ном уз­ле стро­ку:

  • .* @192.168.81.44:514

то все со­об­щения бу­дут пе­ре­на­прав­лять­ся на порт 514 UDP (на са­мом де­ле это зна­чение, ис­поль­зуе­мое по умол­чанию) ком­пь­ю­те­ра с IP-ад­ре­сом 192.168.81.44. Вме­сто IP-ад­ре­са мож­но ука­зать имя ком­пь­ю­те­ра, ес­ли оно раз­ре­шае­мо. При пе­ре­на­прав­лении по TCP ис­поль­зу­ют­ся два зна­ка @:

  • .* @@192.168.81.44:514

Конеч­но, при же­лании мож­но су­зить вы­бор­ку, а не брать все со­об­щения *.*. И ничто не по­ме­ша­ет вам до­ба­вить вто­рое по­хо­жее пра­ви­ло для пе­ре­на­прав­ления со­об­щения на вто­рой сер­вер. На локаль­ном ком­пь­ю­те­ре rsyslog дол­жен слу­шать порт 514 UDP (обыч­ное по­ве­дение syslog), кро­ме то­го, там нуж­но за­гру­зить со­от­вет­ст­вую­щий мо­дуль та­ким об­ра­зом:

$ModLoad imudp

$UDPServerRun 514

…а ес­ли нуж­но слу­шать порт 514 TCP, то та­ким:

$ModLoad imtcp

$InputTCPServerRun 514

ИМЯ МОДУЛЯ ОПИСАНИЕ
IMUXSOCK Слу­ша­ет до­мен­ный со­кет unix /dev/log (тра­ди­ци­он­ное по­ве­де­ние syslog)
IMTC Слу­ша­ет со­об­ще­ния, пе­ре­на­прав­ляе­мые по TCP-со­еди­не­нию
IMUDP Слу­ша­ет со­об­ще­ния, пе­ре­на­прав­ляе­мые по UDP-со­еди­не­нию (тра­ди­ци­он­ное по­ве­де­ние syslog)
IMKLOG Слу­ша­ет со­об­ще­ния яд­ра
IMRELP Слу­ша­ет со­об­ще­ния по на­деж­но­му про­то­ко­лу RELP
IMFILE Бе­рет со­об­ще­ния из фай­ла
OMRELP Пе­ре­на­прав­ля­ет со­об­ще­ния с ис­поль­зо­ва­ни­ем про­то­ко­ла RELP
OMRELP Пе­ре­на­прав­ля­ет со­об­ще­ния с ис­поль­зо­ва­ни­ем про­то­ко­ла RELP
OMMYSQL От­прав­ля­ет (важ­ные) со­об­ще­ния по элек­трон­ной поч­те
OMPROG От­прав­ля­ет со­об­ще­ния за­дан­ной внеш­ней про­грам­ме для спе­ци­аль­ной об­ра­бот­ки

Достав­ка со­об­щений по про­то­ко­лу TCP го­раз­до на­дежнее, чем по UDP, по­то­му что ес­ли локаль­ный ком­пь­ю­тер вый­дет из строя, цен­траль­ный rsyslog это об­на­ру­жит. В этом слу­чае rsyslog мож­но на­стро­ить на сбор со­об­щений в оче­редь для по­сле­дую­щей пе­ре­да­чи. Од­на­ко rsyslog пред­ла­га­ет и го­раз­до бо­лее на­деж­ный сер­вер пе­ре­на­прав­ления со­об­щений – RELP (Reliable Event Logging Protocol – на­деж­ный про­то­кол журнали­ро­вания со­бы­тий), ко­то­рый пре­достав­ля­ет яв­ные под­твер­ждения «со­об­щения при­ня­то» на уровне при­ло­жения. Что­бы восполь­зо­вать­ся RELP, нуж­но за­гру­зить мо­ду­ли omrelp (на цен­траль­ном сер­ве­ре) и imrelp (на локаль­ном ком­пь­ю­те­ре).

Кста­ти, обыч­ный сиг­нал ‘HUP’, ко­то­рый за­став­ля­ет де­мон пере­чи­тать свой файл на­строй­ки, для rsyslog не ра­бо­та­ет. Ес­ли вы внесли из­менения в файл на­строй­ки, пе­ре­за­пусти­те де­мон, скомандовав:

service rsyslog restart

От­кло­не­ние со­об­ще­ний

В rsyslog мож­но яв­но за­дать дей­ст­вие discard с по­мо­щью сим­во­ла ~. Ес­ли со­об­щение со­от­вет­ст­ву­ет пра­ви­лу, с ко­то­рым свя­за­но дей­ст­вие discard, со­об­щение не сравнива­ет­ся с дальней­ши­ми пра­ви­ла­ми в фай­ле.

Так, на­при­мер, сле­дую­щие две стро­ки в на­ча­ле спи­ска пра­вил:

authpriv.* /var/log/secure

authpriv.* ~

принудят со­об­щения уст­рой­ст­ва authpriv попадать в /var/log/secure и боль­ше никуда. Это бо­лее энергич­ный спо­соб от­клонения со­об­щения, чем про­сто по­зво­лить ему спуститься по спи­ску пра­вил, ни од­но­му из ко­то­рых оно не со­от­вет­ст­ву­ет.

В до­полнение к тра­ди­ци­он­но­му фор­ма­ту пра­вил уст­рой­ст­во.серь­ез­ность, rsyslog мо­жет вы­би­рать со­об­щения по их тек­сто­вому со­дер­жи­мо­му (или по дру­гим свой­ст­вам, та­ким как имя хоста-ис­точника). Вот про­стой при­мер, что­бы вы по­ня­ли идею:

msg, contains, “NETFILTER” /var/log/iptables.log

& ~

Пер­вую стро­ку по­яс­нять не нуж­но – она вы­би­ра­ет со­об­щения, со­дер­жа­щие стро­ку NETFILTER. Воз­мож­ны и дру­гие ти­пы со­постав­ления, на­при­мер, startswith [на­чи­на­ет­ся с]) вме­сто contains; ли­бо мож­но восполь­зо­вать­ся regex для по­ис­ка по ре­гу­ляр­но­му вы­ра­жению. Вто­рая стро­ка ве­лит rsyslog от­клонить это со­об­щение, и оно не бу­дет про­ве­рять­ся на со­от­вет­ст­вие дальней­шим пра­ви­лам. Так мы га­ран­ти­ру­ем, что со­об­щения NETFILTER по­па­дут толь­ко в iptables.log.

Шаб­ло­ны

С по­мо­щью шаб­ло­на мож­но оп­ре­де­лить струк­ту­ру строк, ко­то­рые rsyslog за­пи­сы­ва­ет в лог-фай­лы. Для на­ча­ла про­ясним, что у со­об­щений есть струк­ту­ра (оп­ре­де­лен­ная в RFC3164). Вот при­мер (взя­тый из /var/log/messages в Fedora):

Mar 22 05:06:12 saturn dhclient[880]: DHCPACK from 192.168.81.254

Вы ви­ди­те, что здесь есть вре­мя, имя хоста (saturn), имя про­грам­мы, иден­ти­фи­ка­тор про­цес­са и, на­конец, некое тек­сто­вое опи­сание. (Эта по­след­няя часть про­ве­ря­ет­ся на со­от­вет­ст­вие свой­ст­ву msg со­об­щения в мо­ем пре­ды­ду­щем при­ме­ре). Это при­мер фор­ма­та по умол­чанию. Но с по­мо­щью шаб­ло­нов мож­но оп­ре­де­лить соб­ст­вен­ные фор­ма­ты. На­при­мер, вот как с по­мо­щью шаб­ло­на мож­но вклю­чить в вы­во­ди­мый текст при­ори­тет со­об­щения (по­жа­луй, стран­но, что, учи­ты­вая роль при­ори­те­та в вы­бо­ре со­об­щений тра­ди­ци­он­ны­ми пра­ви­ла­ми syslog уст­рой­ст­во.серь­ез­ность, сам при­ори­тет по умол­чанию не за­пи­сы­ва­ет­ся в лог-файл). При­мер, со­знаюсь­, принадлежит Райнеру...

Пре­ж­де все­го мы оп­ре­де­ля­ем шаб­лон в фай­ле на­строй­ки:

$template TraditionalPlusPRI,”%pri-text%:

%timegenerated% %HOSTNAME%

%syslogtag%%msg:::drop-last-lf%\n”

При­ме­не­ние шаб­ло­нов

Этот шаб­лон со­от­вет­ст­ву­ет тра­ди­ци­он­но­му фор­ма­ту syslog с до­бав­лением по­ля %pri-text %.Оп­ре­де­лив шаб­лон и дав ему имя, мы мо­жем ве­леть rsyslog ис­поль­зо­вать его в на­ших дей­ст­ви­ях при­мер­но с та­ким пра­ви­лом:

  • .info;mail.none;authpriv.none /var/log/messages;TraditionalPlusPRI

С этим из­ме­не­ни­ем на­ше со­об­ще­ние DHCPACK вы­гля­де­ло бы следующим образом:

daemon.info<30>: Mar 22 19:53:04 saturn dhclient[880]: DHCPACK from 192.168.81.254

Об­ра­ти­те внимание, что пе­ред ис­поль­зо­ванием шаб­ло­на нуж­но оп­ре­де­лить его в фай­ле на­строй­ки. Кста­ти, оп­ре­де­ления стан­дарт­но­го фор­ма­та вы там не уви­ди­те – он встро­ен в rsyslog.

Ес­ли вы хо­ти­те уз­нать боль­ше, страница man rsyslog.conf – хо­ро­шее ме­сто для стар­та. Бо­лее под­роб­ную ин­фор­ма­цию мож­но най­ти по ссыл­кам на www.rsyslog.com/doc. Там есть мас­са до­ку­мен­та­ции, и на­пи­са­на она хо­ро­шо, но немно­го лоскут­ная (про­сти, Райнер!). Райнер так­же за­пи­сал не­сколь­ко удоб­ных ви­део­ру­ко­водств, они дос­туп­ны на www.rsyslog.com/video-tutorials. |

Персональные инструменты
купить
подписаться
Яндекс.Метрика