Linux: Полное руководство

Аллен Питер В.

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

# После ротации создавать новый пустой журнальный файл