Бортжурнал юниксоида

Anton Karpov

Xakep, номер #063, стр. 063-108-1

(toxa@real.xakep.ru)

Система журналирования событий в подробностях

Залогинься в свою Unix-систему, набери ps waux, если это Linux или BSD, или ps –ef, если это Solaris либо другая реализация System V. Ты увидишь множество процессов, каждый из которых что-то делает. К примеру, это может быть crond, inetd, ntpd, sendmail, sshd и еще масса других демонов, а также процессы ядра системы. И что интересно - все они выводят на стандартные потоки данные, которые регистрируются системой журналирования. Для чего это нужно?

Это сделано для того, чтобы владелец хоста в любой момент времени мог узнать, что конкретно делает каждый из них, а если что-то не работает - выяснить, в чем причина. Логи - история жизни системы, и порой только долгое ковыряние в /var/log помогает выяснить, почему же вдруг провайдер выставил непомерный счет за трафик, и что за клоун всю ночь долбился на все 65535 портов сервера.

Краткая справка

Традиционно за ведение журналов событий отвечает демон syslogd, история которого корнями уходит в институт Беркли и тамошнюю BSD. Syslogd - нечто большее, чем просто демон. Он должен взаимодействовать со всеми демонами, которые запущены в системе, чтобы все они могли протоколировать события. Взаимодействие это происходит через специальный сокет /dev/log. Поэтому любой демон, желающий оставить память о себе в журнале событий, просто пишет в этот файл с определенными аргументами. Системный демон syslogd запускается из инициализационных скриптов при старте системы.

Как и у любого уважающего себя демона, у syslogd есть свой конфигурационный файл. По умолчанию это /etc/syslog.conf, однако ничто не мешает назвать его как угодно, а потом запускать syslogd с ключом -f /path/to/config.file. Именно на файл конфигурации мы обратим свое внимание, а о ключиках, с которыми можно пускать syslogd, можно узнать из man syslogd, благо их немного.

Конфигурирование демона

Каждая строчка syslog.conf состоит из двух записей - правила и действия. В правилах указывается, какая подсистема генерирует события, а также степень подробности, в действиях - что с этими событиями делать. На деле все просто. Основных подсистем всего двенадцать - auth, authpriv, cron, daemon, ke, lpr, mail, mark, news, syslog, user, uucp, однако на практике в основном используют следующие из них: auth - информация о регистрации пользователя в системе ("юзер вася зашел со второй консоли"), authpriv - информация о повышении привилегий в системе ("юзер вася сделал su на рута на второй консоли"), cron - информация о выполняющихся по расписанию заданиях ("в девять утра, как обычно, скрипт опустил firewall, и инет у юзеров кончился"), ke - сообщения ядра ("сетевой интерфейс перешел в promiscious mode"), lpr - сообщения системы печати, mail - сообщения почтовой системы, и т.д.

О назначении подсистемы говорит ее название. Хотя вся эта классификация по большому счету условность. Тут нет ftpd, httpd и т.д. - и не нужно, так как эти демоны сами заботятся о том, сколько и куда писать информации. В общем же случае, это дело программиста - к какому классу отнести своего демона и использовать при написании соответствующий аргумент для функции openlog(3).

Содержание  Вперед на стр. 063-108-2
ttfb: 3.37815284729 ms