Linux: Полное руководство — страница 36 из 98

В любой UNIX-подобной системе есть стандартные файлы протоколов (журналов). В них попадают сообщения, генерируемые ядром, системными демонами, утилитами окружения. Эти файлы размещаются в каталоге /var/log. Прикладные программы обычно помещают свои протоколы в подкаталоги этого каталога, например, /var/log/httpd — журналы HTTP-сервера. Точное расположение журнала прикладной программы зависит от ее настройки.

За ведение журналов отвечает система регистрации событий syslog. Она позволяет сортировать сообщения по источникам и степени важности, а также перенаправлять их в журнальные файлы, на консоль или на другой компьютер в сети. Все подсистемы (демоны) и правильно написанные прикладные программы не ведут протоколов самостоятельно, а посылают сообщения в систему регистрации. Дальнейшая судьба этих сообщений зависит от политики системного администратора.

Система регистрации состоит из следующих компонент:

♦ демон syslogd, принимающий сообщения от других процессов и перенаправляющий их указанным адресатам;

♦ библиотечные функции openlog(), syslog(), closelog(), посредством которых процессы общаются с демоном syslogd. Функция syslog() записывает протокольное сообщение в гнездо (сокет) /dev/log, откуда его читает демон syslogd;

♦ команда logger, с помощью которой сообщение демону syslogd может передать командный интерпретатор.

Демон syslogd запускается инициализационным сценарием в ходе начальной загрузки системы и работает непрерывно. Убедиться в том, что он запущен, можно с помощью команды

$ ps -ef | grep syslogd | grep -v grep

Примечание

Последняя в этом конвейере команда нужна для того, чтобы отфильтровать из вывода команды grep сведения о самой команде grep.

Если ваша система загружается в стиле System V, то сценарий запуска демона — это /etc/rc.d/init.d/syslog. Как обычно, запустить демон самостоятельно вы можете с помощью команды

/etc/rc.d/init.d/syslog start

а остановить — /etc/rc.d/init.d/syslog.stop.

Автоматический запуск системы syslog можно отключить или включить при помощи графического конфигуратора (setup для дистрибутива Red Hal, drakxservices для Mandrake, system-config-services для Fedora Core).

В Red Hat-совместимых дистрибутивах демон syslogd устанавливается из пакета sysklogd, в состав которого входит также демон klogd, принимающий сообщения ядра и отправляющий их на обработку демону syslogd.

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

По сигналу HUP демон закрывает все журнальные файлы, перечитывает конфигурационный файл и возобновляет процесс протоколирования. Чтобы изменения в конфигурационном файле вступили в силу, нужно послать демону syslogd сигнал HUP. Например, так:

$ kill -HUP `cat /var/run/syslogd.pid`

9.3.1. Конфигурационный файл /etc/syslog.conf

Это простой текстовый файл, каждая непустая и незакомментированная (знак комментария — #) строка которого имеет следующий формат:

<селектор>[;<селектор>...] <действие>

Селектор представляет собой правило отбора сообщений, а действие — указание, что с отобранными сообщениями дальше делать. Например, строка

user.* -/var/log/user.log

диктует перенаправление сообщений от пользовательских программ в файл /var/log/user.log.

Действиями могут быть:

♦/абсолютное/имя/файла — записать сообщение в файл. Префикс «-» перед именем файла запрещает синхронизировать файл после каждой записи. По умолчанию syslogd после записи каждой строки выполняет вызов fsync(). Это делается ради сохранности журналов, но при интенсивной записи может отнять половину процессорного времени. Поэтому следует отключать синхронизацию протоколов, в которые пишется много сообщений — например, отладочных.

♦@имя_машины —переслать сообщение демону syslogd, работающему на указанной машине. Имя должно быть известно DNS или прописано в /etc/hosts; в противном случае следует писать @IP-адрес.

♦/dev/console — вывести сообщение на консоль.

♦* — вывести сообщение на экраны всех работающих в данный момент пользователей.

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

Селектор, в свою очередь, имеет формат:

<средство> [, средство2..,] . <уровень_серьезности>

Средство (facility) — это категория программы, пославшей сообщение. Категория выбирается из списка ключевых слов, приведенного в таблице 9.2.

Категории программ, ведущих протокол Таблица 9.2

Ключевое слово	Назначение программы, пославшей сообщение
auth authpriv security	Программы, отслеживающие регистрацию пользователей в системе и повышение привилегий пользователи (login, su)
authpriv	Программы, отслеживающие повышение привилегий пользователя (команда su)
cron	Выполнение заданий по расписанию (cron и at)
daemon	Системные демоны, для которых не нашлось более подходящей категории
kern	Ядро
lpr	Подсистема печати
mail	Почтовые программы
news	Подсистема, обслуживающая телеконференции Usenet
uucp	Система UUCP
syslog	Сам демон syslogd
user	Все остальные программы
*	Любая программа
none	Никакая программа

Уровень серьезности (priority) определяет важность сообщения. Программы регистрируют любые сообщения — от отладочной информации до требований экстренного вмешательства — а демон syslogd игнорирует те из них, важность которых ниже, чем указано в конфигурационном файле. Уровень серьезности указывается ключевым словом, список которых в порядке возрастания важности приведен в таблице 9.3. Допускаются также ключевые слова * (все сообщения) и none (никаких сообщений).

Уровни серьезности сообщений Таблица 9.3

Ключевое слово	Означает
debug	Отладочные сообщении
Info	Информационные сообщения о штатных ситуациях
notice	Замечания: сообщения о необычных ситуациях
warning	Предупреждения
err	Ошибки
crit	Критические ошибки
alert	События, требующие срочного вмешательства
emerg	События, угрожающие работе системы

В Red Hat-совместимых системах можно ставить перед уровнем серьезности дополнительные модификаторы «=» (регистрировать сообщения только указанного уровня) и «!» (игнорировать сообщения указанного и более высоких уровней). Можно также направлять сообщения не только в обычный файл, но и в именованный канал, поставив перед ним символ «|».

Листинг 9.4. Примерный файл /etc/syslog.conf

# Протоколирование аутентификации. Файл протокола
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
# Файл регистрации попыток доступа к системе, имеет
# ограниченный доступ. Обычно в этот файл записываются
# сообщения об удаленном доступе к этой машине, например,
# сообщения от демона FTP о том, какие пользователи и
# когда регистрировались на данном сервере.
authpriv.* /var/log/secure

# Сообщения пользовательских программ
user.* -/var/log/user.log

# Протоколировать все информационные сообщения, кроме
# почтовых
*.info;mail.none; -/var/log/messages

# Протоколирование почты
# Уровень отладки, информации и замечаний
mail.=debug;mail.=info;mail.=notice -/var/log/mail/info
# Уровень предупреждений
mail.=warn -/var/log/mail/warnings
# Уровень ошибок
mail.err -/var/log/mail/errors

# Протоколирование демона cron.
cron.=debug;cron.=info;cron.=notice -/var/log/cron/info
cron.=warn -/var/log/cron/warnings
cron.err -/var/log/cron/errors

# Протоколирование ядра
kern.=debug;kern.=infо;kern.=notice -/var/log/kernel/info
kern.=warn -/var/log/kernel/warnings
kern.err -/var/log/kernel/errors

# Очередь печати: сообщения уровня от "инфо" до "предупреждений"
lpr.info;lpr.!err -/var/log/lpr/info

# Протоколирование демонов: сообщения всех уровней, кроме "инфо"
daemon.=debug;daemon.!=info -/var/log/daemons

# Критические сообщения - всем тревога
*.emerg *

# Сохранять ошибки почты и новостей в отдельном файле
uucp,news.crit -/var/log/spooler

# Загрузочные сообщения
lоса17.* -/var/log/boot.log

9.3.2. Сетевое протоколирование

Протоколы — это история жизни системы; они необходимы администратору для выявления и устранения неполадок, но они необходимы и злоумышленнику — для поиска уязвимости или для того, чтобы скрыть следы своего вторжения. Поэтому иногда бывает полезно вести журнал на другом, более безопасном, компьютере.

Протоколирование в сети — это перенаправление сообщений демону syslogd, запущенному на другой машине локальной сети, где они будут записаны в локальный файл. Таким образом, один демон syslogd, передающий сообщения, выступает в роли клиента, а другой такой же, но принимающий и сохраняющий их, — в роли сервера.

Сообщения передаются по протоколу UDP. Он не обеспечивает ни гарантированной доставки пакетов, ни секретности, но работает несколько быстрее, чем TCP. Следующая строка должна присутствовать (в незакомментированном виде!) в файлах /etc/services обоих компьютеров:

syslog 514/udp

Затем необходимо внести некоторые коррективы в файл конфигурации. На клиентской машине определите объекты протоколирования (селекторы), как и раньше, а в качестве действия укажите @имя_узла, где имя_узла — имя компьютера, на который будут перенаправлены сообщения. Это имя желательно указать в файле /etc/hosts, так как демон syslogd может быть запущен до сервера доменных имен или сервер DNS окажется недоступным.

На сервере протоколирования может быть необходимо перезапустить syslogd с другим набором ключей. В Red Hat-совместимых системах syslogd по умолчанию игнорирует сообщения из сети; для того, чтобы он начал их принимать, он должен быть запущен с ключом -r (это верно для пакета sysklogd версии 1.3 и новее. Ранние версии вели себя в точности наоборот).

Каждое сообщение в журнальном файле маркируется полным именем узла, с которого оно поступило (с указанием домена). Чтобы syslogd на сервере записывал только краткие имена узлов, нужно запустить его с ключом -l <список_узлов> или -s <список_доменов>. Узлы и домены в списках нужно разделять двоеточиями.

9.3.3. Протоколирование ядра. Демон klogd и команда dmesg

Демон klogd предназначен для перехвата и протоколирования сообщений ядра Linux. Ядро, в отличие от пользовательского процесса, не может выводить сообщения, пользуясь стандартной функцией syslog(): библиотека, содержащая эту функцию, доступна только обычным приложениям. В ядре есть свои средства вывода сообщений, приложениям недоступные. Обработку этих сообщений и организует демон klogd. Обычно эта обработка состоит в пересылке сообщений демону syslogd, хотя klogd может работать и самостоятельно.

Демон syslogd направляет сообщения ядра вперемешку с сообщениями от других источников в общий журнальный файл (обычно /var/log/messages, смотри /etc/syslog.conf), но ядро поддерживает и собственный кольцевой буфер сообщений. Для просмотра текущего состояния этого буфера предназначена команда dmesg. Ее вывод рекомендуется пропускать через фильтр more или less.

Анализ сообщений ядра может потребоваться для того, чтобы узнать, поддерживает ли ваше ядро то или иное устройство или функцию. Например, чтобы узнать, включена ли поддержка квотирования (п.7.2.3), выполните команду

$ dmesg | grep -i quot

Сообщения, которые ядро генерирует и сохраняет в буфере во время загрузки системы, направляются также в файл /var/log/dmesg (в не Red Hat-совместимых системах этот файл может называться /var/log/boot.msg). По окончании загрузки этот файл закрывается и его содержимое становится доступно для просмотра и анализа.

9.3.4. Что делать с протоколами дальше? Утилита logrotate

Журнальные файлы разрастаются быстро, и рано или поздно с ними приходится что-то делать: сжимать, архивировать или просто удалять. В дистрибутивах линии Red Hat и Debian для управления журналами — не только системы syslog, но и любых прикладных программ, — предназначена утилита logrotate. Она устанавливается из пакета logrotate вместе с примерным конфигурационным файлом и сценарием, обеспечивающим ее периодический запуск (п.9.4). В результате установки этого пакета сценарий logrotate попадает в каталог /etc/cron.daily.

Как следует из названия утилиты logrotate, ее основное занятие — это ротация журнальных файлов. Ротация — это последовательное переименование предыдущих версий журналов (maillog.2 a maillog.3, maillog.1 в maillog.2, maillog в maillog.1) и создание нового пустого журнального файла (maillog) для записи последующих сообщений. Ротация производится либо по истечении указанного времени, либо по превышении журнальным файлом указанного размера.

Список журналов, подлежащих обработке утилитой logrotate, и инструкции по обработке определяются конфигурационными файлами, имена которых в любом количестве передаются как аргументы при вызове утилиты (см. man logrotate). Директивы последующих конфигурационных файлов перекрывают директивы предыдущих, так что порядок имеет значение. Традиционно используется один файл /etc/logrotate.conf, а инструкции для дополнительных журналов включаются в него при помощи директивы include.

Листинг 9.5. Примерный конфигурационный файл /etc/logrotate.conf

# Секция глобальных параметров —
# инструкции для всех журналов
# Расписание ротации: еженедельно.
# Возможны варианты: daily, monthly,
# size <байт> — по достижении файлом указанного размера
weekly
# Сохранять 4 предыдущих журнала
rotate 4
# После ротации создавать новый пустой журнальный файл
create
# Сохранять старые журналы в сжатом виде [по умолчанию
# при помощи gzip, директива compresscmd позволяет указать
# другую программу для сжатия)
compress

# В каталог /etc/logrotate.d прикладные программы помещают
# инструкции по управлению их собственными журналами.
# Директива include <каталог> требует включить все файлы,
# содержащиеся в этом каталоге.
include /etc/logrotate.d

# Секция локальных параметров - инструкции для
# перечисленных в ней журналов
/var/log/wtmp /var/log/lastlog {
 monthly
 create 0664 root utmp
 rotate 1
}

9.4. Выполнение заданий по расписанию