Sysklogd
предоставляет две системные утилиты, обеспечивающих журналирование событий происходящих в системе и сообщений ядра. Поддерживая и домены интернет и unix-домены, этот пакет утилит обеспечивает как локальное, так и удалённое журналирование.
Системный журнал ведёт версия
syslogd(8),
восходящая в своём происхождении к исходникам BSD. Поддержка журналирования для ядра обеспечивается утилитой
klogd(8),
которая может работать либо отдельно, либо в виде клиента syslogd.
Многие современные программы, используют обеспечиваемый
syslogd
вид журналирования. Каждое занесённое в журнал сообщение содержит, по меньшей мере поля с указанием времени и имени машины, обычно также и поле с названием программы, но это зависит от доверия журналирующей программы.
Не смотря на то, что исходные тексты
syslogd
были серьёзно переработаны, есть пара моментов, которые необходимо отметить. Первое, разработчики строго придерживались положения о том, что syslogd должен сохранить стандартное для BSD поведение.
Вторая важная концепция, это прозрачное взаимодействие этой версии syslogd с находящейся в системных библиотеках версии syslog. Если выполняемый код связанный со стандартной разделяемой библиотекой не будет правильно выполняться, мы бы хотели получить пример этого ненормального поведения.
При запуске читается основной конфигурационный файл
/etc/syslog.conf
или альтернативный файл, заданный опцией
-f.
В нем игнорируются любые пустые строки и начинающиеся с символа решетки ("#"). Если при разборе какой-либо строки возникает ошибка, то она полностью игнорируется.
ОПЦИИ
-a сокет
Используя этот аргумент, вы можете определить дополнительные сокеты, которые
syslogd
будет слушать. Это необходимо, если некоторые службы планируется выполнять в окружении chroot(). Вы можете использовать до 19 дополнительных сокетов. Если же потребуется больше, то можно увеличить идентификатор
MAXFUNIX
в файле syslogd.c. Ребята из OpenBSD рассматривают пример с работающим в chroot() сервисе на странице
<http://www.guides.sk/psionic/dns/>.
-d
Включает режим отладки. Применение этой опции укажет службе syslogd не использовать порождение дочернего процесса
fork(2)
для перехода в фоновой режим работы, напротив, демон останется в интерактивном режиме выполнения и будет выводить довольно много отладочной информации на текущий tty. За дополнительной информацией обратитесь к разделу ОТЛАДКА.
-f файл_конфигурации
Определить альтернативный файл конфигурации взамен используемого по умолчанию
/etc/syslog.conf.
-h
По умолчанию syslogd не пересылает сообщения получаемые от удалённых станций. Использование этой опции в командной строке укажет службе журналирования, что любые получаемые сообщения от удалённых машин необходимо пересылаться на определённый сетевой узел.
-i адрес_IP
Если
syslogd
сконфигурирован для приёма сообщений через порт UDP, то предпочтительнее указать адрес IP, к которому его привязать, нежели использовать настройку по умолчанию INADDR_ANY. Адрес должен состоять из четырех чисел разделённых точками, DNS-имя не требуется.
-l список_сетевых_узлов
Определить сетевой узел, журналирование которого необходимо производить, используя только простое имя машины (например, aurora), а не полностью определённое доменное имя (FQDN) (например, aurora.tux.ru). Имена нескольких машин можно перечислить используя в качестве разделителя двоеточие (":").
-m интервал
Syslogd
регулярно отмечает текущее время делая запись в журнале. Стандартно, между двумя строками с отметками -- MARK -- определён
интервал
в 20 минут. Это можно изменить с помощью данной опции. Установив в
интервал
нулевое значение вы полностью отключите запись этих отметок.
-n
Отменить автоматический переход в фоновый режим. Это главным образом необходимо если
syslogd
запущен и контролируется
init(8).
-p сокет
Взамен
/dev/log,
вы можете определить альтернативу сокету домена unix.
-r
Эта опция активирует возможность получения сообщений из сети используя сокет домена интернет через службу syslog (см.
services(5)).
По умолчанию сообщения из сети не принимаются.
Эта опция впервые появилась в версии 1.3 пакета sysklogd. Вы можете это использовать, только пожалуйста, примите во внимание, что стандартное поведение зависит от используемой версии.
-s список_доменов
Определить имя домена, которое будет отсекаться при журналировании. Несколько доменов можно перечислить используя в качестве разделителя двоеточие (":").
Пожалуйста учтите, что нельзя указывать субдомены, а только домены целиком. Например, если указать
-s north.de
и журналируемым узлом является satu.infodrom.north.de, то домен не будет отсечён, вам необходимо будет указать два домена:
-s north.de:infodrom.north.de.
-u имя_пользователя
Прежде чем начать журналирование, служба
syslogd
получит имя (псевдо)пользователя.
Обратите внимание, что когда эта опция используется, то при первом запуске
syslogd
откроет файлы журналов как суперпользователь (root);
однако, после вызова
SIGHUP,
файлы будут открыты вновь от имени непривилегированного пользователя. Это стоит принять в расчёт, когда будете назначать права владения файлами журналов.
-j каталог_chroot
Указывает службе
syslogd,
после инициализации, сменить корневой каталог (chroot(2)) на данный.
Эта опция допустима, только при одновременном использовании опции -u, для запуска
syslogd
без привилегий суперпользователя (root).
Учтите, что эта опция делает вызов
SIGHUP
бесполезным, что делает перезагрузку сервиса практически невозможным.
-v
Показать версию программы и выйти.
СИГНАЛЫ
Syslogd
реагирует на набор сигналов. Вы можете просто послать сигнал
syslogd
используя команду вида:
kill -СИГНАЛ `cat /var/run/syslogd.pid`
SIGHUP
Этот сигнал, переданный
syslogd
вызовет пере-инициализацию. Все открытые файлы будут закрыты, файл настроек (по умолчанию это
/etc/syslog.conf)
будет прочитан заново, и сервис
syslog(3)
запуститься вновь.
SIGTERM
Прервёт работу
syslogd.
SIGINT, SIGQUIT
Если режим отладки включен, то эти сигналы будут проигнорированы, иначе
syslogd
прервёт работу.
SIGUSR1
Включение/выключение режима отладки. Этот сигнал может быть использован только если при запуске
syslogd
применялась опция включающая режим отладки
-d.
SIGCHLD
Во время отправки сообщений с помощью команды wall, ожидать реакции дочерних процессов, если они были порождены.
РАЗЛИЧИЯ В СИНТАКСИСЕ ФАЙЛОВ КОНФИГУРАЦИИ
Syslogd
использует слегка отличающийся от принятого в BSD синтаксис конфигурационного файла. Изначально, все сообщения с соответствующим приоритетом и выше направлялись в файл журнала.
Например, следующая строка повлечёт направление ВСЕЙ выводной информации от системных служб выполняющихся в режиме демонов в файл
/usr/adm/daemons
(режим отладки (debug) имеет наименьший приоритет, поэтому все сообщения имеющие более высокий приоритет также подходят под условие):
# Пример syslog.conf
daemon.debug /usr/adm/daemons
По новой схеме это поведение остаётся тем же. Различие состоит в четырех добавившихся спецификаторах: шаблон - символ звёздочки (*), знак равенства (=), восклицательный знак
(!), и знак минуса (-).
Символ "*" определяет, что все сообщения указанного сервиса направляются в назначенный файл. Заметьте, что это поведение не поменяется при изменении приоритета отладочных сообщений. Пользователи отметили, что нотация с использованием символа звёздочки более интуитивно понятная.
Шаблон "=" используется для чтобы ограничить журналирование видом имеющим только определенный приоритет. Это позволит, например, направить только отладочные сообщения в соответствующий журнал.
Например, следующая строка в
syslog.conf
направит все отладочные сообщения из всех источников в файл
/usr/adm/debug.
# Пример syslog.conf
*.=debug /usr/adm/debug
Восклицательный знак "!" используется для того чтобы исключить некоторое журналирование.
И это затронет все возможные виды данного исключения.
Например, следующая строка указывает журналировать все сообщения категории mail в файл
/usr/adm/mail,
кроме имеющих метку приоритета info. И все сообщения от news.info (включительно) до news.crit
(исключая последние), будут журналироваться в файл
/usr/adm/news.
# Пример syslog.conf
mail.*;mail.!=info /usr/adm/mail
news.info;news.!crit /usr/adm/news
Вы можете использовать это для указания исключений. Здесь просто инвертирована интерпретация символа "=". Таким образом, вы можете указать
mail.none
или
mail.!*
или
mail.!debug
и все сообщения от почтового сервиса будут игнорироваться. Что ж, здесь есть с чем поиграться. :-)
Если вы хотите опустить выполнение sync для файла после каждого его изменения, то используйте символ "-" как префикс имени файла.
Тем кто использовал чистый синтаксис BSD может потребоваться небольшая акклиматизация, однако тестеры отмечают, что новый синтаксис в обращении более гибок. Отметим, что эти изменения не затрагивают стандартные файлы
syslog.conf(5).
Вам необходимо специально изменить конфигурационные файлы чтобы получить расширенное поведение.
ПОДДЕРЖКА УДАЛЁННОГО ЖУРНАЛИРОВАНИЯ
Эта версия предоставляет поддержку сети для сервиса syslogd.
Поддержка сети означает, что сообщения могут быть пере-направлены с одного узла сети на котором запущен syslogd, на другой сетевой узел с выполняющимся на нём syslogd, где они и будут в действительности помещены в файл журнала на жестком диске.
Для включения этой возможности, в командной строке следует указать опцию
-r.
По умолчанию
syslogd
не прослушивает сеть.
Идея заключается в том, чтобы иметь syslogd который прослушивает сокет домена unix на предмет локально сгенерированных сообщений, помещаемых в журнал. Это поведение позволяет syslogd взаимодействовать с syslog находящемся в стандартной библиотеке C. В тоже время syslogd прослушивает стандартный порт syslog, ожидая сообщений пересылаемых с других сетевых узлов. Для того чтобы это работало корректно, необходимо в файл
services(5),
находящийся в
/etc
внести следующую запись:
syslog 514/udp
Если эта запись отсутствует, то
syslogd
не сможет ни получать, ни отправлять сообщений, так как UDP-порт нельзя будет открыть. Вместо этого,
syslogd
немедленно аварийно завершит работу, выдав сообщение об ошибке.
Включить пере-направление сообщений на другой сетевой узел можно изменив строку в
syslog.conf,
содержащую имя файла журнала, его следует заменить на имя узла сети с префиксом "@", на которую будут пересылаться сообщения.
Например, для пере-направления
ВСЕХ
сообщений на удалённую машину используйте следующую запись в
syslog.conf:
# Пример конфигурационного файла syslogd,
# который предписывает пересылать все сообщения
# на удалённую машину.
*.* @имя_хоста
Для пере-направления всех сообщений ядра (kernel) на удалённую машину, конфигурационный файл должен быть следующего вида:
# Пример конфигурационного файла syslogd.
# Все сообщения ядра пере-направляются на
# удалённую сетевую машину.
kern.* @имя_хоста
Если во время загрузки системы имя удалённой машины не может быть разрешено (т.е. определён адрес сетевого узла в числовом виде), потому что сервер имён не доступен (он может запускаться после запуска syslogd), то не стоит беспокоиться.
Syslogd
предпримет ещё 10 попыток для разрешения имени удалённой машины и в случае неудачи выразит недовольство. Другое возможное решение это поместить имя удалённого сетевого узла в
/etc/hosts.
С обычными настроенными
syslogd
легко угодить в syslog-петлю, когда сообщения полученные от удалённого узла пересылаются на ту же самую машину (или в более сложном варианте, на третью машину, которая отсылает сообщения на первую, и т.д.). В моём домене (Infodrom Oldenburg) мы это неожиданно обнаружили заполненными все наши диски одним и тем же сообщением. :-(
Во избежание этого не следует далее пересылать сообщения полученные с удалённой машины на другую (или ту же) машину. Если установленная у вас программа так не поступает, пожалуйста обратитесь к опции командной строки
-h.
Если удалённая машина находится в том же домене что и станция на которой выполняется
syslogd,
то в журнал вместо FQDN, будет записываться только простое имя узла.
В локальной сети вы можете организовать централизованный сервер журналирования для хранения всей важной информации на одной машине. Если локальная сеть состоит из нескольких доменов, то не стоит сетовать на то, что в журнал вместо простых имён, будут заноситься полные имена узлов. Воспользуйтесь возможностью отсечения доменов для этого сервера, опция
-s.
Вы можете сказать
syslogd
отсекать несколько доменов, а не только один в котором он находится, и журналировать только простые имена машин.
Использование опции
-l,
также позволяет определить указанные машины как локальные. Что также приведёт к журналированию только их простых имён, а не FQDN.
UDP-сокет используемый для пересылки сообщений на удалённые машины или получения сообщений от них, открыт только когда это требуется. В версиях до 1.3-23 он был открыт постоянно, но соответственно закрыт для для пересылки и чтения.
ВЫВОД В ИМЕНОВАННЫЕ КАНАЛЫ (FIFOs)
Эта версия syslogd поддерживает вывод журналирования в именованные каналы (FIFOs). FIFO или именованные каналы могут быть использованы как место назначения для сообщений журнала, указанием символа канала ("|") перед именем файла. Это удобно применять для отладки. Учтите, что прежде чем syslogd будет запущен, FIFO должен быть создан командой mkfifo.
Нижеследующий конфигурационный файл задаёт пере-направление отладочных сообщений ядра в FIFO:
# Пример настройки для пере-направления ТОЛЬКО отладочных
# сообщений ядра в /usr/adm/debug, который является
# именованным каналом.
kern.=debug |/usr/adm/debug
ВОПРОСЫ УСТАНОВКИ
Возможно, есть только один важный момент на который стоит обратить внимание при установке этой версии syslogd. Эта версия syslogd зависит от надлежащего форматирования сообщений функцией syslog. Где-то в районе версий libc.so.4.[2-4].n, изменилась работа функции syslog находящейся в разделяемой библиотеке. Конкретно поменялось следующее: теперь перед отправлением в сокет
/dev/log,
сообщения получают завершающий ноль. Правильное функционирование этой версии syslogd зависит от наличия в сообщении завершающего нуля.
Если в системе используются старые исполняемые файлы со статическим связыванием, то обычно эта проблема проявит сама себя. Исполняемые файлы использующие старые версии функций syslog будут писать пустые строки после первого символа журналируемого сообщения. Данную проблему исправит перекомпоновка этих двоичных файлов с новыми версиями разделяемых библиотек.
И
syslogd(8) и the klogd(8)
могут быть запущены из
init(8)
или стартовать как часть rc.* последовательности.
Если запуск производится из init, то необходимо применить опцию -n, иначе вы получите тонны запущенных служб syslog. Это происходит потому что
init(8)
зависит от идентификатора (ID) процесса.
УГРОЗЫ БЕЗОПАСНОСТИ
Потенциально, сервис syslogd может быть использован в качестве лазейки для атак приводящих к отказу в обслуживании (DoS, denial of service). Спасибо Джону Моррисону (John Morrison, jmorriso@rflab.ee.ubc.ca) за предупреждение об этой потенциально существующей опасности.
Злоумышленник или программа довольно просто может утопить службу syslogd в сообщениях syslog, в результате чего файлы журналов займут всё доступное место в файловой системе. Конечно же, активирование журналирования через сокеты домена интернет подвергает систему риску атак со стороны внешних, либо локальных, злоумышленных программ или лиц.
Некоторые методы защиты машины:
1.
Для ограничения доступа к сокету 514/UDP только конкретным хостам или сетям, обеспечьте работу межсетевого экрана ядра.
2.
Журналирование может быть направлено на изолированную или не корневую файловую систему, которая в случае заполнения не повредит работе машины.
3.
Можно использовать файловую систему ext2, в которой есть возможность настроить процент использования файловой системы суперпользователем (root). ВНИМАНИЕ,
это потребует работы syslogd в виде непривилегированного процесса.
ТАКЖЕ УЧТИТЕ, что это воспрепятствует использованию удалённого журналирования, так как syslogd не сможет связаться с сокетом 514/UDP.
4.
Запрет использования сокетов домена интернет уменьшит риск для локальной машины.
5.
Если вы применили п.4 и это не помогло устранить проблему с злоумышленной программой/демоном, то возьмите стальной метровый прут и проведите с пользователем разъяснительную беседу.
ОТЛАДКА
Если использованием в командной строке опции
-d,
отладка включена, то рапортуя о выполняемых действиях на stdout,
syslogd
будет достаточно многословен. Всякий раз когда конфигурационный файл заново перечитан и проанализирован, вы увидите таблицу соответствующую внутренней структуре данных. Эта таблица состоит из четырёх полей:
number(номер)
Это поле содержит порядковый номер начиная с нуля. Этот номер представляет позицию во внутренней структуре данных (массиве). Если один из номеров отсутствует, то возможно имеется ошибка в соответственной строке в файле
/etc/syslog.conf.
pattern(шаблон)
Это поле очень информативно и в точности представляет внутреннюю структуру. В каждом столбце отдельно представлено одно из средств обслуживания (см.
syslog(3)).
Как видите, некоторые средства обслуживания ещё не сформированы и свободны для использования, в основном используются только те что слева. В каждом поле в столбце представлены приоритеты (см.
syslog(3)).
action(действие)
Данное поле описывает конкретное действие, которое выполняется каждый раз при получении сообщения соответствующего шаблону. Для получения информации о всех возможных действиях, смотрите страницу руководства
syslog.conf(5).
arguments(аргументы)
В этом поле показаны дополнительные аргументы, которые можно использовать при осуществлении действия (action). Для записи журнала в файл это имя файла журнала; для журналирование работы пользователей это список пользователей; для удалённого журналирования это имя машины, журнал которой будет вестись; для журналирования консоли, используемая консоль; для tty-журнала установленная tty; wall не имеет дополнительных аргументов.
ФАЙЛЫ
/etc/syslog.conf
Файл настроек для
syslogd.
Для полной информации смотрите
syslog.conf(5).
/dev/log
Сокет домена Unix из которого читаются локальные сообщения syslog.
/var/run/syslogd.pid
Файл содержит идентификатор (ID) процесса
syslogd.
ОШИБКИ
Всё правило игнорируется в случае наличия ошибки в одной строке.
На любых стадиях работы,
syslogd
не изменит режима доступа к открытым файлам журналов. Если файл создан с разрешённым доступом на чтения для всех. Для избежания этого, создайте файл и назначьте права доступа по своему усмотрению. Это может быть сделано в комбинации с оборотом файлов журналов при использовании программы
savelog(8),
которая поставляется с версиями 3.x программы
smail.
Помните, что открытый для всех доступ на чтение сообщений авторизации auth.*, которые могут содержать пароли, может быть дырой в безопасности.
Syslogd
взят из исходных кодов BSD, Грег Ветстейн (Greg Wettstein, greg@wind.enjellic.com)
выполнил его перенос на Linux, Мартин Шульце (Martin Schulze, joey@linux.de) исправил некоторые ошибки и добавил несколько новых возможностей.
Klogd
изначально был написан Стивом Лордом (Steve Lord, lord@cray.com), затем Грег Ветстейн
сделал значительные улучшения.
