Конфигурационный файл демона syslogd. Системные журналы Linux (управление логированием) Файл dmesg и команда dmesg

СЕРГЕЙ СУПРУНОВ

FreeBSD tips: использование syslog

– Позвольте, товарищи, у меня все ходы записаны!

– Контора пишет, – сказал Остап.

И.Ильф, Е.Петров «12 стульев».

Протоколирование работы любой системы, и прежде всего сервера, – одна из важнейших составляющих администрирования. Именно в log-файлы мы заглядываем в первую очередь, когда в системе возникают какие-то неполадки. Оттуда черпаем уверенность, что та или иная программа работает так как ожидается. При разработке веб-приложений log-файл становится важнейшим источником отладочной информации. Об особенностях работы демона syslog, отвечающего за протоколирование системной информации, и пойдет речь.

Что такое syslog

Syslog является централизованным сервисом, обеспечивающим сбор и запись протокольной информации, поступающей от различных компонентов операционной системы и пользовательских процессов. Сторонние программы, как правило, умеют работать со своими лог-файлами самостоятельно, хотя многие из них можно настроить на работу и с демоном syslogd. К преимуществам использования syslog можно отнести возможность управлять процессом сбора необходимой информации с помощью одного конфигурационного файла, что обеспечивает единообразие получаемых log-файлов и в итоге упрощает управление ими.

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

Каждое сообщение характеризуется уровнем и источником (facility). Уровень задает степень важности сообщения с точки зрения функционирования системы. Файл syslog.h определяет следующие уровни (приоритеты):

Таблица 1. Уровни сообщений

В таблице 1 уровни сообщений перечислены в порядке убывания. Этот порядок понадобится в дальнейшем при обсуждении синтаксиса конфигурационного файла.

Обозначения уровня сообщения, записанные в одной строке (например, emerg и panic), – это синонимы, и может быть использовано любое из них. Однако panic, error и warn (указанные в таблице вторыми) считаются устаревшими, и следует избегать этих обозначений при редактировании конфигурационного файла. Вместо них используйте emerg, err и warning соответственно.

Возможные источники сообщения перечислены в таблице 2:

Таблица 2. Источники сообщений

При настройке какого-либо приложения для работы со службой syslog уточните, какой источник (facility) оно использует. Некоторые программы позволяют указать источник самостоятельно. Например, демон clamd (главный процесс антивируса clamav) по умолчанию использует local6, однако позволяет задавать другой источник (параметр LogFacility в конфигурационном файле). В ряде случаев может быть полезно объединить его сообщения с сообщениями почтовых служб, указав в качестве источника LOG_MAIL.

Параметры запуска демона

Полный список параметров запуска можно получить на странице руководства man syslogd. Здесь рассмотрим только некоторые из них.

Syslog способен записывать поступающие сообщения в лог-файлы (которые обычно размещаются в каталоге /var/log), отправлять на консоль или подключенный терминал пользователя, пересылать на удаленный хост или отдавать на обработку внешней утилите по конвейеру.

Для работы по сети syslog использует порты 514 (UDP и TCP). Запущенный без дополнительных параметров, syslogd будет прослушивать эти порты, ожидая входящих сообщений. Ключ -s запрещает принимать входящие сообщения, но сокеты на портах 514 по-прежнему создаются для исходящих соединений, чтобы syslogd мог отправлять сообщения удаленным хостам. Удвоение ключа (-ss) запрещает и исходящие соединения.

По умолчанию syslogd запускается с ключом -s (см. /etc/defaults/rc.conf, параметр syslogd_flags), поэтому входящие соединения запрещены. Если вы хотите использовать службу syslog вашего сервера для обслуживания нескольких машин, добавьте в /etc/rc.conf следующую строчку:

syslogd_flags=””

Она переопределит значение, установленное в /etc/defaults/rc.conf, и syslogd сможет обслуживать входящие соединения. Естественно, в этом случае необходимо обеспечить требуемый уровень безопасности, исключив возможность чужим хостам писать что-нибудь в ваши журналы. Установить ограничения на входящие соединения позволяет ключ -a (см. man syslogd). Также не последнюю роль играет правильно настроенный брандмауэр.

Еще один полезный ключ -l позволяет задавать дополнительные файлы сокетов, которые прослушиваются демоном syslogd в дополнение к используемому по умолчанию /var/run/log. Например, этот ключ необходим, чтобы syslog мог обслуживать программы, запущенные в chroot-окружении. В частности, так работает named, начиная с версии BIND 9. Во FreeBSD 5.3 syslogd запускается со следующими ключами:

# ps -wax | grep syslog

Синтаксис конфигурационного файла

Настройка протоколирования осуществляется в файле /etc/syslog.conf. Само собой разумеется, что редактировать его может только пользователь root. Этот файл содержит два вида строк – условно назовем их «фильтры» и «правила».

Строка-фильтр определяет программу или хост, к сообщениям от которых будут применяться следующие за ней правила. Фильтр вида «!prog» (или «#!prog») указывает на то, что последующие строки относятся к логам, которые генерируются указанной программой prog. Синонимом этой записи является «!+prog». Строка «!-prog», наоборот, говорит о том, что последующие правила будут применяться ко всем сообщениям, кроме тех, которые исходят от программы prog. Допускается перечислять через запятую несколько программ, при этом знак «+» или «-» применяется ко всему списку.

Если строка-фильтр задана как «+hostname», то в качестве источника сообщений, которые должны быть обработаны последующими правилами, будет использоваться указанный хост. Так же как и в случае с программами, символом «-» отмечается, что правила будут применяться ко всем сообщениям, кроме поступающих от указанного хоста. Через запятую можно задавать список хостов.

Символ «*», заданный в качестве программы или хоста, отменяет действие фильтра, установленного ранее. То есть правила, указанные после такой строки, будут применяться ко всем сообщениям. Фильтры с именем хоста или программы независимы друг от друга и могут действовать одновременно. Например:

# Правила, расположенные здесь, применяются ко всем сообщениям

My.host

# Правила применяются ко всем сообщениям с my.host

Logger

# Правила применяются к сообщениям от logger с my.host (фильтр хоста продолжает действовать)

# Правила применяются к сообщениям от su с my.host

# Правила применяются к сообщениям от su с любых хостов (фильтр хоста отменен, фильтр программы продолжает действовать)

# Правила применяются ко всем сообщениям (фильтр программы так же отменен)

Строки правил имеют следующий вид:

facility.CMPlevel destination

Здесь facility – источник сообщения («*» обозначает любые источники), level – уровень сообщений, которые будут обрабатываться в соответствии с данным правилом. Служебное слово «none», указанное вместо уровня, дает указание полностью исключить сообщения от данного источника.

CMP – операция сравнения (допускаются символы «>», «<», «=», «>=», «<=», а также символ отрицания «!»). Если символ сравнения не указан, подразумевается «больше или равно», то есть обрабатываются все сообщения уровня level и выше.

Destination указывает, куда следует сохранять данное сообщение. Это может быть log-файл (указывается полный путь, начиная с «/»), адрес удаленного сервера (начинается с символа «@»), имя пользователя (сообщения будут отправляться на терминал, к которому данный пользователь подключен). Также сообщение может быть передано на обработку внешней программе, для чего используется символ конвейера «|».

Несколько примеров правил

Все сообщения ядра будут отправляться в файл kern.log.

kern.* /var/log/kern.log

Все сообщения об ошибках, а также сообщения уровней emerg, alert и crit будут помещены в all-err.log. Обратите внимание на дефис перед именем log-файла. По умолчанию сообщения буферизуются в памяти и записываются на диск по мере заполнения буфера. Это снижает нагрузку на файловую систему, но может вызвать потерю некоторой информации при аварийном отключении машины. Дефис перед именем файла заставляет демон syslogd немедленно записывать сообщения на диск.

*.err -/var/log/all-err.log

Отладочные сообщения пользовательских процессов будут выводиться на терминал, к которому в настоящее время подключен пользователь vasya.

user.debug vasya

Все сообщения от служб новостей и электронной почты будут пересылаться на 514-й порт машины syslog.host.ru.

mail.*,news.* @syslog.host.ru

В указанный файл будут помещаться все сообщения службы печати, уровень которых ниже warning. Как указывалось ранее, по умолчанию используется сравнение «больше или равно», а символ «!» его инвертирует, заменяя на «меньше». Если нужно исключить конкретный уровень, следует использовать конструкцию «!=».

lpr.!warning /var/log/printers.log

Сообщения уровня debug (и только его), имеющие facility level0 и level3, будут выводиться на все подключенные терминалы.

level0,level3.=debug *

Сообщения службы точного времени, уровень которых выше критического (то есть emerg и alert), а также меньше или равные notice (notice, info и debug), будут отправляться на терминалы пользователей ntpuser и root.

ntp.>crit,<=notice ntpuser,root

Все сообщения уровня warning, исключая поступающие от почтовых служб, будут записываться в файл warn.log.

*.=warning,mail.none /var/log/warn.log

В данном случае все сообщения, уровень которых выше или равен crit, будут отправлены по электронной почте пользователю root.

*.crit | mail -s “critical message” root

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

# kill –HUP `cat /var/run/syslog.pid`

Следует заметить, что если то или иное сообщение подпадает под действие нескольких строк в конфигурационном файле, то оно будет обработано в соответствии с каждой из них. Пример:

mail.* /var/log/maillog

*.=err /var/log/error.log

В данном случае сообщения mail.err попадут как в maillog, так и в error.log.

Стратегия составления конфигурационного файла

Завершая рассмотрение конфигурационного файла, скажу несколько слов о стратегиях его составления. Помимо очень популярной «лишь бы работало», можно выделить две основные, которые условно назовем «по источнику» и «по назначению».

• Первая стратегия, которую можно наблюдать в ряде дистрибутивов GNU/Linux, заключается в том, что для каждого источника сообщений записывается свое правило (или группа правил, если сообщения разных уровней должны обрабатываться по-разному). Ее достоинство – простота определения, куда записываются сообщения конкретных служб.
• Стратегия «по назначению» подразумевает создание по возможности только одной строки для каждого «получателя» сообщения, например, файла. Такого подхода придерживается, в частности, FreeBSD. В итоге можно легко определить, какая информация заносится в конкретный лог-файл, но, например, пункты назначения для сообщений ядра приходится собирать по всему конфигурационному файлу.

Утилита logger

В составе системы есть утилита logger, которая позволяет отправлять сообщения службе syslog непосредственно из командной строки. Ее удобно использовать при тестировании правил конфигурации, а также в разрабатываемых сценариях для протоколирования их работы. Примеры:

user$ logger -p user.err “Error in user program!”

user$ logger -h syslog.host.ru “Test it”

Первый пример отправит сообщение с facility user уровня err, которое будет обработано в соответствии с файлом конфигурации. Вторая команда отправит сообщение на удаленный хост, источник и уровень по умолчанию будут установлены как user.notice.

Использование механизмов ротации

Рассмотренный выше механизм протоколирования не предусматривает какого-либо управления log-файлами. Сообщения просто помещаются в них согласно правилам, описанным в конфигурационном файле. Это значит, что файлы журналов будут постоянно расти, и если ничего не предпринимать, то рано или поздно заполнят все доступное пространство соответствующего раздела. Чтобы этого избежать, используется механизм ротации.

Например, как только размер файла debug.log превысит 100 Мб, он переименовывается в debug.log.0 и упаковывается в debug.log.0.bz2. А вместо него создается новый debug.log. Далее, когда размер и нового файла достигает 100 Мб, debug.log.0.bz2 переименовывается в debug.log.1.bz2, и описанная выше процедура повторяется. Система хранит только определенное количество архивных файлов, удаляя наиболее старые из них. Это и есть ротация.

Утилита newsyslog

В системе FreeBSD за ротацию отвечает утилита newsyslog, которая по умолчанию запускается в начале каждого часа демоном cron. Изменить период ротации можно, отредактировав файл /etc/crontab.

Указанные в приведенном выше примере параметры ротации (размер файла, упаковка), а также ряд других задаются в конфигурационном файле /etc/newsyslog.conf. Для каждого файла, нуждающегося в ротации, в нем содержится строка в общем случае из девяти полей: имя файла, владелец и группа, права доступа, наибольший номер в имени архивных файлов, максимальный размер файла, период ротации, дополнительные флаги, а также путь к PID-файлу приложения, которому нужно отправить сигнал после ротации, и номер сигнала, который должен быть послан. (Отправка сигнала процессу может понадобиться, например, в том случае, если процесс держит log-файл все время открытым; если этого не сделать, то используемый файловый дескриптор не будет соответствовать вновь созданному файлу.) Некоторые поля могут быть опущены. Приведем два примера, полный и «типичный»:

/var/log/pflog root:wheel 600 3 100 * JB /var/run/pflog.pid 1

В соответствии с этим правилом файл pflog должен перезаписываться, как только его размер превысит 100 Мб (5-е поле) независимо от времени (символ «*» в 6-м поле). Архивные файлы будут иметь имена вида pflog.X.bz2 (pflog.0.bz2, pflog.1.bz2 и т. д), причем X не может быть больше трех (параметр 3 в 4-м поле). Флаг J указывает, что архивный файл должен упаковываться с помощью утилиты bzip2. Благодаря флагу B в архивируемый и вновь создаваемый файлы не будут добавляться служебные сообщения о ротации, поскольку файл воспринимается как двоичный. Вновь создаваемый файл будет принадлежать пользователю root и группе wheel (это поле можно было бы опустить, поскольку этот владелец устанавливается по умолчанию). Права доступа будут установлены в rw------- (числовое значение 600), то есть только владелец сможет читать этот файл и писать в него. Наконец, процессу, PID которого хранится в файле /var/run/pflog.pid, будет послан сигнал 1 (HUP), чтобы он переоткрыл свой лог-файл.

/var/log/maillog 640 7 * @T00 J

Это правило указывает параметры ротации для файла maillog: независимо от размера (звездочка в 5-м поле), файл будет перезаписываться каждую ночь в 00:00 (в man newsyslog.conf формат указания времени описан достаточно подробно). Архив должен упаковываться, будут сохраняться последние 8 архивов (с номерами от 0 до 7 включительно), вновь созданный файл будет принадлежать пользователю root (значение по умолчанию, поэтому поле владельца пропущено) и иметь права доступа rw-r-----.

Для просмотра упакованных log-файлов можно использовать утилиты zcat и bzcat (для gzip и bzip2 соответственно). Midnight Commander вызывает соответствующие утилиты автоматически.

После редактирования файла newsyslog.conf никакие сигналы никуда посылать не требуется – конфигурация будет перечитана при следующем вызове newsyslog.

Следует заметить, что утилита newsyslog не привязана к демону syslogd. То есть она может быть использована для ротации любых файлов, которые в этом нуждаются. Если ротация включается для логов, которые приложение ведет самостоятельно (например, к логам clamd или squid), то особенно внимательно отнеситесь к указанию владельца и правам доступа. Их неправильное указание может привести к тому, что после ротации приложение, запущенное от имени непривилегированного пользователя, не сможет осуществлять запись во вновь созданный файл.

Подводя итоги

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

Демон syslogd (system logging-deamon) обеспечивает вид протоколирования, который поддерживается большинством программ. При этом демон syslogd пишет сообщения в файл /var/log/syslog. Записи в этом файле обычно содержат такие поля: дата и время, хост, программа, сообщение. Пример этого файла представлен ниже:

Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can"t locate module sound-service-1-0

Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can"t locate module sound-slot-1

Jan 27 17:12:28 dhsilabs kernel: VFS: Disk change detected on device ide1(22,64)

Jan 27 17:12:31 dhsilabs kernel: ISO 9660 Extensions: Microsoft Joliet Level 1

Jan 27 17:12:31 dhsilabs kernel: ISOFS: changing to secondary root

Jan 27 17:12:32 dhsilabs kernel: VFS: Disk change detected on device fd(2,0)

Jan 27 17:12:32 dhsilabs kernel: end_request: I/O error, dev 02:00 (floppy), sector 0

Например, из предпоследней записи мы можем узнать, что 27-го января 2002 года в 17:12 произошла смена носителя в устройстве fd, о чем нам любезно сообщило ядро системы (запись «программа» - kernel). А носитель (дискета) оказался подпорченным, о чем свидетельствует следующая запись - ошибка ввода/вывода (I/O error, dev 02:00 (floppy), sector 0).

Демон syslogd запускается автоматически при старте системы. Для его запуска предназначен сценарий /etc/rc.d/init.d/syslog. Как обычно, запустить демон самостоятельно вы можете с помощью команды: /etc/rc.d/init.d/syslog start, а остановить - /etc/rc.d/init.d/syslog stop. Для обеспечения автоматической загрузки нужно создать символическую ссылку на этот файл, например:

ls –s /etc/re.d/rc5.d/@S30syslog /etc/rc.d/init.d/syslog.

В этом случае вы обеспечите запуск демона на пятом уровне запуска (автоматический запуск X Window). Если вы используете Linux Mandrake, включить и отключить автоматический запуск вы можете с помощью команды drakxservices. При использовании Linux Red Hat включите автозапуск демона с помощью конфигуратора setup. Демон syslogd можно запускать с опциями, указанными в табл. 5.7.

В табл. 5.7 указаны не все опции демона. Назначение всех остальных опций вы можете найти в справочной системе, введя команду man syslogd.

Опции демона syslogd Таблица 5.7

Действиями демона syslogd управляет файл конфигурации /etc/syslog.conf. Это простой текстовый файл, в котором пустые строки и строки со знаком # в первой позиции игнорируются. Формат файла следующий:

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

Например,

mail.err /var/log/mail.errors

Эта строка обеспечит запись всех ошибок, связанных с доставкой почты в файл /var/log/mail.errors.

Важно: В качестве разделителя между селектором и действием используйте только клавишу . Использование пробелов будет ошибкой, которую не так-то легко обнаружить.

Как вы уже заметили, селектор записывается в составном виде. В общем виде это выглядит, как средство.уровень

К тому же в поле <селектор> может содержаться один или несколько селекторов, разделенных точкой с запятой. Селектор может содержать группу средств, разделенных запятыми. Селектор может содержать символы * и none, которые означают соответственно "все" и "ничего".

Примеры селекторов:

средство.уровень действие

средство1,средство2.уровень действие

средство1.уровень1;средство2.уровень2 действие

*.уровень действие

*.уровень;средство.none действие

Ниже в таблицах перечислены основные имена средств и уровней серьезности системы syslog.

Средство Программы, использующие его

kern Ядро системы

user Пользовательские процессы

mail Система электронной почты

daemon Системные демоны

auth Системы защиты и полномочий

lpr Система печати

news Система телеконференций

cron Демон cron

local0-7 Восемь уровней локального сообщения

syslog Внутренние сообщения системы syslog

ftp Демон ftpd

* Все вышеперечисленные средства

Уровень Значение уровня

emerg Экстренные ситуации

alert Срочные ситуации

crit Критические состояния

err Состояния ошибок

warning Предупреждения

notice Необычные состояния

Info Информационные сообщения

debug Отладочная информация

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

Поле <действие> указывает, что нужно делать с поступившим сообщением.

Действие Описание

имя_файла Записать сообщение в файл на локальной машине

@имя_машины Переслать сообщение демону syslogd на указанную машину

@IP_адрес То же, только указан IP-адрем машины

пользователь1, Вывести сообщение на экраны указанных пользователей ...

пользовательN

* Вывести сообщение на экраны всех пользователей

*.emerg /dev/console

*.err;auth.notice /dev/console

*.err;auth,mail,user.info /var/log/messages

mail.err /var/log/mail.log

mail.info @192.168.0.1

Говоря о системе syslog, нужно упомянуть о команде logger, которая позволяет вносить записи в системный журнал из shell-сценариев.

Эту команду удобно использовать для проверки изменений, внесенных в файл /etc/syslog.conf.

local5.warning /var/log/local.log

и хотите проверить, работает ли она, то введите команду

# logger -p local5.warning "Local test"

Посмотрите файл /var/log/local.log. Если строчки "Local test" в нем нет, значит вы скорее всего забыли послать демону syslogd сигнал HUP.

Список распространенных UNIX/LINUX демонов, в ОС Windows называются службами, которые могут использоваться в разных UNIX/LINUX модификациях. Имена UNIX/LINUX демонов в окончании часто содержат букву d как сокращение от англ. daemon. Проверить запущен ли процесс/демон можно командой top или ps aux .

Ниже представлен список имён самых распространенных демонов и их краткое описание. Приведённый ниже список UNIX/LINUX демонов не является полным/исчерпывающим и в вашей UNIX/LINUX системе один, все или несколько из них могут быть в наличии или же отсутствовать в зависимости от версии/типа/модификации/конфигурации вашей UNIX/LINUX системы и установленного на ней ПО.

Если в приведённом выше списке UNIX/Linux демонов/служб нет работающей на вашей системе, то для получения справки о такой службе используйте man name_daemon , а если и там нет информации о работающей службе, то пишите в комментарии и мы сообща накопаем информации по такой службе и пополним приведённый здесь список UNIX/Linux демонов/служб.

Если в справке man name_daemon нет описания службы, то демон/служба может оказаться вирусом , в таком случае выполните поиск исполняемого файла whereis name_daemon и отправьте его на анализ в вирусную лабораторию - это можно сделать без установки антивируса через веб-интерфейс, например http://vms.drweb.com/online/ , http://www.esetnod32.ru/.support/scanner/ или https://www.virustotal.com/ .

Автозагрузка демонов/служб UNIX/LINUX

Ниже даны подробные инструкции по управлению автозагрузкой демонов/служб в наиболее распространённых модификациях/версиях UNIX-подобных ОС таких как CentOS Linux, Debian Linux и ОС BSD типа . В остальных же модификациях/версиях UNIX-подобных ОС управление автозагрузкой демонов/служб имеет схожий порядок, хотя может иметь некие не существенные или же вовсе радикальные отличия!

Автозагрузка демонов/служб в CentOS Linux

В CentOS уровни загрузки определены по принципу System V и расписаны в файле /etc/inittab , читаем less /etc/inittab .

Каталоги для каждого из уровней загрузки носят названия и расположены в директории /etc/rc.d .

В каждом из каталогов, который соответствует тому или иному уровню загрузки расположены шел скрипты, вернее ссылки на них, с инструкциями для запуска демона/программы/службы, а сами же шел скрипты с инструкциями для запуска демона/программы/службы расположены в каталоге /etc/rc.d/init.d

Пример скриптов управляющих запуском демона/программы/службы можно просмотреть выполнив less /etc/rc.d/init.d/mysqld или less /etc/rc.d/init.d/sshd . Обычно скрипты управляющие запуском демона/программы/службы появляются в /etc/rc.d/init.d/ и линкуются в каталоги уровней запуска после установки ПО, а их статус off/on для каждого из уровней запуска управляется утилитой chkconfig .

Какой из демонов будет запущен на различных уровнях запуска можно посмотреть командой chkconfig --list . Включить демон для автоматического запуска в какой-либо из уровней запуска можно командой chkconfig --level 345 mysqld on , а выключить chkconfig --level 345 mysqld off соответственно, chkconfig –del service_ name удалить службу, chkconfig service_name on|off включить или выключить службу на всех уровнях.

Что касается добавления скриптов в автозагрузку, то для автоматической загрузки скриптов служит /etc/rc.local , в /etc/rc.local достаточно добавить полный путь к скрипту, например: /root/scripts/script.sh или /bin/sh /root/scripts/script.sh . Если после установки ПО в /etc/rc.d/init.d/ нет скрипта управляющего автозапуском нужной программы, то строку её инициализации/запуска проще добавить в /etc/rc.local.

Для управления уровнями запуска существует утилита ntsysv, man ntsysv .

Автозагрузка демонов/служб в Debian Linux

Каталоги для каждого из уровней загрузки в Debian Linux тоже носят названия rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d но, расположены уже не в директории /etc/rc.d, а в корне каталога /etc

Шел скрипты с инструкциями для запуска демона/программы/службы, вернее символические ссылки на них расположены в каталогах /etc/rc?.d где знак? соответствует уровню загрузки, а сами же шел скрипты с инструкциями для запуска демона/программы/службы расположены в каталоге /etc/init.d . Пример такого скипта, по образцу которого можно написать свой, можно найти в файле less /etc/init.d/skeleton .

Ниже дадим пояснения служебной информации используемой в заготовке скрипта /etc/init.d/skeleton:

• Provides: Описывает предоставляемые этим скриптом объекты (арг1, агр2, ...) таким способом, что, когда скрипт запускается с аругментом start, данные объекты считаются существующими, и, следовательно, другие скрипты в init, которые требуют существование этих объектов, смогут запуститься на более поздней стадии. Обычно, можно использовать имя скрипта в качестве объекта, но так же можно использовать имя сервиса, которую он заменяет. Виртуальные объекты тут не указываются. Они определены вне скриптов init.d
• Required-Start: Задаёт объекты, которые должны существовать, чтобы запустить скрипт. При необходимости можно использовать виртуальные объекты, как описано ниже. Если объекты не указывается, то скрипт может быть запущен сразу после старта, без необходимости подключения локальных файловых систем, запуска системного журнала и т.д.
• Required-Stop: Задаёт используемые сервисом объекты, предоставляемые скриптом. Предоставляемый этим скриптом объект, должен завершиться до завершения перечисленных тут объектов, чтобы избежать конфликтов. Обычно, здесь указывают те же объекты, что и в Required-Start
• Should-Start: Задаёт объекты, которые, если существуют, должны должны быть запущены перед сервисом, предоставляемым данным скриптом. Это допускает слабые зависимости, которые не приводят сервис к ошибке, если объекты не доступны. Можно использовать при необходимости виртуальные объекты, как описано ниже.
• Should-Stop: Задаёт объекты, если существуют должны быть остановлены уже после данного сервиса. Обычно, здесь указывают те же объекты, что и в Should-Start
• Default-Start: Задаёт уровни запуска, на которых скрипт должен быть запущен (остановлен) по умолчанию. Например, если сервис должен быть запущен на только уровнях 3, 4 и 5, укажите "Default-Start: 3 4 5" и "Default-Stop: 0 1 2 6".
• Short-Description: Задаёт короткое описание действия скрипта. Ограничено одной строкой.
• Description: Задаёт более подробное описание действия скрипта. Может быть в несколько строк, в этом случае, каждая строка описания должна начинаться с символа # с последующим знаком табуляции или как минимум 2-мя символами пробела. Описание заканчивается перед линией, не совпадающим с этим условием.
• X-Start-Before, X-Stop-After: Задаёт обратные зависимости, которые значат то же, как если бы они были указаны в should-start и should-stop в пакетах, указанных тут.

Для отслеживания зависимостей важны ключевые слова provides, required- и should-. Остальные не используются. Уровни запуска используются программой по умолчанию для упорядочивания скриптов (например, insserv ) для того, чтобы отслеживать, какой из каталогов rc?.d обновлять, когда служба добавляется в первый раз, и должны отражать назначение сервиса. Вот некоторые "виртуальные" объекты:

• $local_fs - Все локальные фаловые системы подключены. Все скрипты, которые производят запись в /var/ должны зависеть от этого, если они уже не зависят от $remote_fs
• $network - низкоуровневая сеть, т.е. сетевые карты, может подразумеваться PCMCIA запущеной
• $named - Демоны, которые могут предоставлять разрешение доменных имён предполагаются запущенными. Например, DNS, NIS+ или LDAP
• $portmap - Демоны, предоставляющие сервис SunRPC/ONCRPC portmapping как указано в 1833 (если они есть)
• $remote_fs - Все файловые системы подключены. Скрипты, которые должны быть запущены во время остановки системы до того, как всем процессам будет отправлен сигнал уничтожения, должны зависеть от $remote_fs.
• $syslog - системный журнал функционирует
• $time - установленно корректное системное время, например, ntp или rdate, или RTC
• $all - Запускает скрипт как можно последним

Управление автозагрузкой демонов в Debian Linux осуществляется при помощи утилиты update-rc.d, подробно в man update-rc.d . Утилита update-rc.d не создаёт и не удаляет ничего, кроме символических ссылок в /etc/rc?.d на так званые init скрипты управляющие запуском и остановкой демона/программы/службы, которые расположены в каталоге /etc/init.d.

Если скрипт для автозапуска демона/сервиса создан вручную по шаблону /etc/init.d/skeleton , то его нужно сначала разместить в каталоге /etc/init.d, потом создать символьную ссылку на этот скрипт в каталоге /etc/rc?.d, где? - номер runlevel’а (уровень загрузки системы ). Символическая ссылка должна иметь такой вид S№№имя_скрипта , где №№ - это номер очередности запуска, если требуется оставить символическую ссылку но, скрипт временно не запускать, то символическую ссылку следует модифицировать до такого состояния K№№имя_скрипта.

Перед началом обработки любого из уровней исполнения сначала выполняются все скрипты, которые начинаются с буквы "K " (эти скрипты останавливают сервисы ), а потом выполняются все скрипты, которые начинаются с буквы "S " (эти скрипты запускают сервисы ). Двузначное число после буквы "S" или "K" указывает на порядок, в котором будут выполняются скрипты . Скрипты с меньшим номером выполняются первыми, например: S01имя_скрипта стартует первым, а S09имя_скрипта будет запущен девятым.

Для создания символьной ссылки используется программа ln -s file1 file2 , где ключ -s говорит о создании именно символьной ссылки, file1 указывает на существующий файл, а file2 имя новой ссылки но, вместо создания символических линков вручную, можно использовать утилиту update-rc.d, которая создана именно для создания символических ссылок в /etc/rc?.d на скрипты из /etc/init.d.

Синтаксис update-rc.d такой : добавление с параметрами по умолчанию update-rc.d defaults , удаление и остановка демона/сервиса update-rc.d -f remove && update-rc.d stop 20 2 3 4 5 . Стартом и остановкой демонов/сервисов можно управлять через скрипт service name start|stop|restart .

Признаться update-rc.d является относительно мутной утилитой, более удобной является утилита chkconfig , которая в Debian Linux отсутствует по умолчанию. Для её установки нам нужно добавить дополнительные репозитории, желательно использовать только официальные репозитории пакетов Debian Linux , в конец списка vi /etc/apt/sources.list , пример sources.list в Debian GNU/Linux 6.0.5 _Squeeze_ - Official i386 :

# # deb cdrom:/ squeeze main deb cdrom:/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-updates, previously known as "volatile" # A network mirror was not selected during install. The following entries # are provided as examples, but you should amend them as appropriate # for your mirror of choice. # # deb http://ftp.debian.org/debian/ squeeze-updates main # deb-src http://ftp.debian.org/debian/ squeeze-updates main deb http://backports.debian.org/debian-backports squeeze-backports main deb http://ftp.debian.org/debian/ squeeze main #deb http://repo.yandex.ru/debian squeeze main contrib #deb http://mirror.yandex.ru/debian squeeze main contrib #deb http://mirror.yandex.ru/debian-multimedia/ squeeze main contrib

После чего обновить список пакетов apt-get update и выполнить установку chkconfig apt-get install chkconfig , а также как альтернативу дополнительно можно поставить sysv-rc-conf apt-get install sysv-rc-conf . Как пользоваться утилитой chkconfig было упомянуто выше, дополнительно смотрим man sysv-rc-conf и man chkconfig .

Добавляя репозитории Debian Linux следует помнить о политике программного обеспечения применяемой к каждой из областей таких как main, contrib и non-free :

• main : - пакеты из этой области являются частью полного дистрибутива Debian Linux и ни один из пакетов из области main для полноценного функционирования не требуют программного обеспечения из-за пределов этой области. Любой может свободно использовать, обмениваться, изменять и распространять пакеты из области main.
• contrib : - пакеты из этой области могут свободно распространяться, однако некоторые их зависимости могут быть не свободны.
• non-free : - содержит пакеты, которые не могут распространяться бесплатно согласно DSFG, а также пакеты из области могут содержать такие ошибки которые не учитываются при разработке и обновлении Debian Linux.

Для автозапуска прочих скриптов и программ в Debian Linux можно использовать старый-добрый /etc/rc.local.

Размещение перед именем файла символа канала (|) позволит использовать fifo (first in - first out, первый пришел - первый вышел) или именованный канал (named pipe) в качестве приемника для сообщений. Прежде чем запускать (или перезапускать) syslogd, необходимо создать fifo при помощи команды mkfifo. Иногда fifo используются для отладки.

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Чтобы сообщения пересылались на другой хост, поместите перед именем хоста символ (@). Обратите внимание, что сообщения не пересылаются с принимающего хоста. (для работы данного назначения на клиенте и сервере в файле /etc/services должна быть прописана строчка syslog 514/udp , и открыт UTP-порт 514)

Список пользователей

Разделенный запятыми список пользователей, получающих сообщения (если пользователь зарегистрирован в системе). Сюда часто включается пользователь root.

Все зарегистрированные пользователи

Чтобы известить всех зарегистрированных пользователей при помощи команды wall, используйте символ звездочки (*).

Пример несложного syslog.conf:

# Все сообщения ядра выдавать на консоль. #kern.* /dev/console # Все логи уровня info или выше, кроме сообщений электронной почты, а так же # не логировать сообщения аутентификации и сообщений демона cron! *.info;mail.none;authpriv.none;cron.none /var/log/messages # Записывать в отдельный файл сообщения, содержащие конфиденциальную # информацию аутентификации, независимо от их уровня. authpriv.* /var/log/secure # Все сообщения почтовой системы тоже записывать в отдельный файл. mail.* -/var/log/maillog # Логировать сообщения планировщика в файл /var/log/cron cron.* /var/log/cron # Сообщения о чрезвычайных ситуациях должны немедленно получить # все пользователи системы *.emerg * # Сохранять сообщения новостей уровня crit и выше в отдельный файл. uucp,news.crit /var/log/spooler # Сохранять сообщения загрузки в boot.log local7.* /var/log/boot.log

Как и во многих конфигурационных файлах, синтаксис следующий:

• строки, начинающиеся с #, и пустые строки игнорируются.
• Символ * может использоваться для указания всех категорий или всех приоритетов.
• Специальное ключевое слово none указывает, что журналирование для этой категории не должно быть выполнено для этого действия.
• Дефис перед именем файла (как -/var/log/maillog в этом примере) указывает, что после каждой записи журнал не должен синхронизироваться. В случае аварии системы вы можете потерять информацию, но отключение синхронизации позволит повысить производительность.

В синтаксисе конфигурационного файла можно поставить перед приоритетом знак! , чтобы показать, что действие не должно применяться, начиная с этого уровня и выше . Подобным образом, перед приоритетом можно поставить знак = , чтобы показать, что правило применяется только к этому уровню, или != , чтобы показать, что правило применяется ко всем уровням, кроме этого. Ниже показано несколько примеров (man syslog.conf можно найти множество других примеров):

# Посылать все сообщения ядра в /var/log/kernel. # Посылать все сообщения уровня critical и higher на удаленную машину sysloger и на консоль # Посыласть все сообщения уровня info, notice и warning в /var/log/kernel-info # kern.* /var/log/kernel kern.crit @sysloger kern.crit /dev/console kern.info;kern.!err /var/log/kernel-info # Посылать все сообщения почтовой системы, кроме уровня info в /var/log/mail. mail.*;mail.!=info /var/log/mail

Я постарался максимально понятно работу syslogd показать на схеме:

Запуск демона syslogd

Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog , однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт - начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian) .

Вот некоторые возможные параметры запуска демона syslogd:

• -a /folder/socket - указание дополнительного слушающего сокета (не забудьте предварительно создать сокет)
• -d - отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал;
• -f имя-конфигурационного-файла . Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf;
• -l список-хостов - задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN - Full Qwalified Domain Name);
• -m минут - запущенный без этой опции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений;
• -p socket - задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
• -r - разрешение принимать сообщения от удаленных хостов;
• -x - запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
• -v - показать версию и закончить работу

После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid .

С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`

можно послать демону syslogd один из следующих сигналов: SIGHUP - перезапуск демона; SIGTERM - завершение работы; SIGUSR1 - включить/выключить режим отладки.

Вообще-то в системе запускаются два демона протоколирования - syslogd и klogd . Оба демона входят в состав пакета sysklogd .

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

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

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate , которая обычно выполняется демоном cron . О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.

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

# сначала заданы параметры "по-умолчанию" (глобальные опции) # обновлять файлы журнала еженедельно weekly # хранить архив логов за 4 последние недели rotate 4 # создавать новый (пустой) файл после ротации (обновления) create # раскомментируйте, если желаете, чтобы сохраненные файлы сжимались #compress # включить настройки ротации из указанного каталога include /etc/logrotate.d # не хранить wtmp, или btmp -- настройки ротации данных журналов следующие: /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0664 root utmp rotate 1 } # специфичные системные журналы могут быть настроены ниже

Глобальные опции размещаются в начале файла logrotate.conf . Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.

В этом примере также содержатся специальные правила для /var/log/wtmp и /var/log/btmp (хранящие информацию о удачных и неудачных попытках входя в систему), ротация которых происходит ежемесячно. Если файлы отсутствуют, сообщение об ошибке не выдается. Создается новый файл и сохраняется только одна резервная копия.

В этом примере по достижении резервной копией последнего поколения она удаляется, поскольку не определено, что следует с ней делать.

Резервные копии журналов могут также создаваться, когда журналы достигают определенного размера, и могут быть созданы скрипты из наборов команд для выполнения до или после операции резервного копирования. Пример:

/var/log/messages { rotate 5 mail logadmin@sysloger size 100k postrotate /usr/bin/killall -HUP syslogd endscript }

В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.

Параметры , задаваемые в конфигурационном файле logrotate.conf:

• compress | nocompress (старые версии сжимаются или не сжимаются с помощью gzip)
• compresscmd (задает программу сжатия, по умолчанию - gzip)
• uncompresscmd (задает программу разжатия, по умолчанию - ungzip)
• compressext (задает суффикс для сжатых файлов)
• compressoptions (задает параметры программы сжатия; по умолчанию - "-9", т.е. максимальное сжатие для gzip)
• copytruncate | nocopytruncate (обычно старая версия переименовывается и создается новая версия журнала; при задании этого параметра logrotate копирует журнал в новый файл, а затем обрезает старый; используется, если программа, создающая журнал, не умеет его закрывать; теряются записи, сделанные в промежутке между копированием и обрезанием; а поможет ли, если создающая журнал программа вместо режима append просто пишет в файл, используя внутренний указатель?)
• create [права-доступа владелец группа] | nocreate (сразу после переименования старой версии журнала и до вызова postrotate создается новый журнал с указанными атрибутами - права доступа задаются в восьмеричном виде, как в chmod.2; если атрибуты не указаны, то берутся от старого журнала)
• daily (смена версий в серии происходит ежедневно)
• delaycompress | nodelaycompress (некоторые программы не сразу закрывают журнал, в этом случае сжатие надо отложить до следующего цикла)
• errors email (кому направлять сообщения об ошибках)
• extension суффикс (задается суффикс, добавляемый к именам файлов при ротации перед суффиксом сжатия)
• ifempty | notifempty (смена версий даже если файл пуст; действует по умолчанию)
• include имя-файла | имя-директории (текстуально подставить файл или все файлы из указанной директории; не включаются поддиректории, специальные файлы и файлы с суффиксами из списка исключений; нельзя использовать внутри секции)
• mail адрес | nomail (когда смена версий приводит к необходимости удалить старый журнал, то послать его по указанному адресу)
• mailfirst (посылать не удаляемую версию журнала, а первую)
• maillast (посылать удаляемую версию журнала; действует по умолчанию)
• missingok | nomissingok (не посылать сообщения об ошибке, если журнал отсутствует)
• monthly (смена версий происходит ежемесячно)
• olddir директория | noolddir (во время смены версий журнал перемещается в указанную директорию; д.б. на том же физическом устройстве)
• postrotate (все дальнейшие строчки до строки endscript исполняются как команды shell после процесса смены версии)
• prerotate (все дальнейшие строчки до строки endscript исполняются перед процессом смены версии)
• rotate число (сколько старых версий хранить; если 0, то ни одной)
• size байт (смена версии происходит, если размер журнала превысил указанное число; можно использовать суффиксы "k" - килобайт - и "M" - мегабайт)
• sharedscripts | nosharedscripts (выполнять команды prerotate и postrotate только один раз для всех файлов, описанных в секции)
• tabooext [+] список-суффиксов (задание списка суффиксов-исключений для include; если указан знак "плюс", то дополнение, иначе замена; по умолчанию: .rpmorig, .rpmsave, .rpmnew, ",v", .swp и "~")
• weekly (смена версий происходит еженедельно)

Изучение и мониторинг журналов

Записи в журналах обычно содержат метку времени, имя хоста, на котором выполняется описываемый процесс, и имя процесса. Просматривать журналы можно при помощи программы постраничного вывода, например, less , искать определенные записи (например, сообщения ядра от определенного демона) можно при помощи команды grep :

# less /var/log/messages # grep "ppp" /var/log/messages | tail Dec 17 16:34:25 proxy pppd: Connection terminated. Dec 17 16:34:25 proxy pppd: Exit. Dec 17 16:35:57 proxy pppd: LCP terminated by peer (^P]kV^@

Компьютер может работать не постоянно и выключаться, допустим на ночь. Поэтому в /var/log/messages записи хранятся циклически от запуска компьютера к выключению, это можно заметить по сообщениям:

Дек 17 08:32:56 syslog-server syslogd 1.4-0: restart. Дек 17 08:32:56 syslog-server syslog: запуск syslogd succeeded Дек 17 08:32:56 syslog-server kernel: klogd 1.4-0, log source = /proc/kmsg started. Дек 17 08:32:56 syslog-server syslog: запуск klogd succeeded

Dec 17 08:32:56 syslog-server kernel: Kernel command line: auto BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2 Dec 17 08:32:56 syslog-server kernel: Memory: 125652k/130560k available (1365k kernel code, 4200k reserved, 92k data, 236k init, 0k highmem) Dec 17 08:32:56 syslog-server kernel: CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz stepping 02

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

Иногда может возникать необходимость мониторинга системных журналов с целью поиска текущих событий. Например, можно попробовать поймать редко случающееся событие в тот момент, когда оно произошло. В таком случае можно использовать команду tail с опцией -f для отслеживания содержимого системного журнала. Пример:

# tail -f /var/log/messages | grep syslog-server Dec 17 16:46:09 syslog-server pppd: pptpd-logwtmp.so ip-up ppp0 maikop 94.77.0.150 Dec 17 16:46:09 syslog-server pppd: Script /etc/ppp/ip-up finished (pid 12552), status = 0x0 Dec 17 16:46:49 syslog-server pptpd: CTRL: Client 85.175.197.65 control connection started Dec 17 16:46:49 syslog-server pptpd: CTRL: Starting call (launching pppd, opening GRE) Dec 17 16:46:49 syslog-server pppd: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

Кроме файлов-журналов, указанных в /etc/syslog.conf, существуют так же и другие файлы, например файл , который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы , имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах пользователей в систему и о всех неудачных входах пользователей в систему соответственно. Так же в каталоге /var/log/ могут находится лог-файлы таких демонов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журналам syslogd.

На последок, хотелось бы сделать акцент на том, что данный протокол очень не защищен, т.к. syslog не содержит никаких средств защиты от подделок сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам посылать сообщения от имени любого хоста. Ваша локальная сеть должна быть защищена экраном от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp. Известны случаи переполнения диска ложными сообщениями.

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

Конфиденциальность сообщений не обеспечивается, так как они передаются открытым текстом.

Если при настройке генератора сообщений указать неправильный адрес коллектора или релея, то никаких сообщений об ошибке не будет - сообщения будут удаляться (или записываться в чужой журнал).

Были предложены несколько проектов улучшения протокола syslog. Например, документ RFC 3195 предлагает систему протоколирования (syslog-conn), основанную на TCP, обеспечивающую гарантированную доставку сообщений в правильной последовательности. Проект syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации специальных сообщений, содержащих цифровую подпись (signature) блока предыдущих сообщений с сохранением стандартного протокола и формата syslog и использованием UDP.

Подведем небольшой итог:

В линукс есть единый демон, отвечающий за журналирование событий локальной системы и удаленных систем. Все события собираются из сокета /dev/log, порта UDP - 514, а так же от "помощника" - демона klogd, который присылает сообщения от ядра. Все собранные сообщения фильтруются демоном syslogd через правила в файле /etc/syslog.conf и в соответствии с правилами распределяются по соответствующим местам назначения. Файлы логов периодически "обрезаются". Периодичность определяет файл logrotate.conf и команда logrotate, которая запускается системным планировщиком - cron.

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

С Уважением, Mc.Sim!