Syslogd - logowanie w Debianie

Artykuł ten traktuje o jednym z aspektów dotyczących systemów linux, logowaniu przy pomocy demona syslog jak i jego konfiguracji. Zarządzanie dziennikami systemowymi i ich monitorowanie należą do jednych z podstawowych czynności które każdy szanujący się administrator powinien umieć. Jeżeli jesteś zwykłym użytkownikiem linuxa, przewrażliwionym na punkcie bezpieczeństwa, to również mam nadzieję znajdziesz tu coś dla siebie. W końcu każdy chciałby wiedzieć, czy w jego systemie nie dzieje się aktualnie nic złego.

1. Instalacja

Jeżeli jakimś dziwnym zbiegiem okoliczności, nie masz zainstalowanego syslog'a ( używając debiana jest praktycznie nie możliwe gdyż jest on dołączany przy instalacji ), musimy go najpierw zainstalować aptitude update aptitude install syslogd

2. Konfiguracja

Pozwolę sobie dla przykładu wkleić część pliku konfiguracyjnego syslog'a.

#  /etc/syslog.conf    Configuration file for syslogd.
#
#            For more information see syslog.conf(5)
#            manpage.

#
# First some standard logfiles.  Log by facility.
#

auth,authpriv.*            /var/log/auth.log
*.*;auth,authpriv.none        -/var/log/syslog
#cron.*                /var/log/cron.log
daemon.*            -/var/log/daemon.log
kern.*                -/var/log/kern.log
lpr.*                -/var/log/lpr.log
mail.*                -/var/log/mail.log
user.*                -/var/log/user.log

Jak widzimy, komentarze są standardowo poprzedzone znakiem #, natomiast każdy wpis wygląda mniej więcej w ten sposób.

kanał.priorytet    podejmowana akcja
user.*                -/var/log/user.log

Przez kanał generalnie rozumiemy kategorię komunikatów, natomiast priorytety są określane przez programistów piszących daną aplikację. Czyli możemy komunikaty z tego samego kanału ale ważniejsze, zapisywać do jednego pliku a te mniej istotne w mniemaniu programisty, do drugiego. Ostatnim argumentem jest tzw. akcja, jak zapewne słusznie się domyśliłeś jest to "miejsce" do którego będą zapisywane/wysyłane logi. Poprzez "miejsce" rozumiem tutaj plik, potok, konsolę bądź inny host. Czasami przed ścieżką do pliku możemy natknąć się na znak - , informuje on demona iż nie należy synchronizować pliku dziennika, po tym jak wpiszemy do niego komunikat. Ma to swoje zastosowanie w przypadku, gdy relatywnie często będą wysyłane informacje do pliku. Wadą tego rozwiązania są możliwe niespójności w logach. Zaletą jest zwiększenie wydajności. Dostępnymi kategoriami kanałów są

auth - autoryzacja
authpriv - również autoryzacja
cron - kanał na który wysyła informacje demon cron
deamon - demony systemowe
ftp - demon ftp
kern - logi z kernela
lpr - logi z drukarki
mail - komunikaty związane z pocztą
mark - co jakiś czas wysyłana jest aktualna data i czas
news - nazwa mówi sama za siebie
security - komunikaty związane z bezpieczeństwem
syslog - logi demona syslog
user - logi z aplikacji używanych przez użytkowników
uucp - logi protokołu Unix-to-Unix CoPy
local0-7 - lokalne komunikaty

Administrator jest zazwyczaj człowiekiem zapracowanym, więc musi sobie pracę ułatwiać, nie chcemy być zalewani tysiącami mało istotnych informacji. Z tego powodu każdy kanał ma odpowiednie priorytety.

debug
info
notice
warning/warn
err/error
crit
alert
emerg/panic

warn, error, panic są uznane za przestarzałe i nie zaleca się ich używania

Programiści syslog'a dodali również możliwość używania przedrostków.

kern.warning
kern.!warning
err.=crit
err.!=crit

Do omówienia pozostał jeszcze parametr akcja.

/scieżka/do/pliku/err.log   - Zapisanie do wskazanego pliku ( z synchronizacją )
-/scieżka/do/pliku/err.log   - Zapisanie do wskazanego pliku ( bez synchronizacji )
/sciezka/do/potoku/nazwa_potoku   - Zapisanie do wskazanego potoku
/dev/tty1   - Wyświetlenie na wskazanej konsoli
@serwer.logow   - Przesłanie logów pod wskazany adres
@10.3.4.5   - To samo co powyżej tylko adres podany w formie ip

3. Przykłady

Na koniec dla utrwalenia, podam kilka przykładów. Załóżmy iż mamy serwer o adresie ip 192.168.12.12, na którym nasłuchuje demon syslog. Chcemy wysyłać tam logi tylko z kanałów security, auth, kern, i authpriv ale pod warunkiem że mają priorytet co najmniej warning.

auth.warning, kern.warning, security.waring, authpriv.warning     @192.168.12.12

Wysyłamy wszystkie log o priorytecie co najmniej notice, na konsole tty12

*.notice    /dev/tty12

Mało ważne informacje będziemy zapisywać w pliku /var/log/nieistotne.log

*.!notice  /var/log/nieistotne.log

Wszystkie logi o priorytecie tylko i wyłącznie alert w pliku /var/log/istotne.log

*.=alert  /var/log/istotne.log

Nie chcemy żadnych logów z priorytetem info bądz debug

*.!notice   /dev/null

4. Podsumowanie

Podsumowjąc syslog jest bardzo użytecznym narzędziem, może ułatwić nam diagnozowanie wielu problemów, informować iż system nie działa prawidłowo i ogólnie zaoszczędzić nam sporo czasu. Kończąc dodam jeszcze parę słów o programie logger. Służy on do testowania min. syslog'a, jego działanie jest bardzo proste.

logger -p kanał.priorytet "Tekst który chcemy zapisać do loga"

Dzięki niemu, będziesz mógł sprawdzić czy wszystko działa tak jak sobie to zamierzyłeś. I to by było na tyle...