LXF91:Дневники демонов - История изменений

-=JeN=-: /* Взгляд разработчика */

2008-03-27T20:46:49Z

‎Взгляд разработчика

-=JeN=-: /* Шаг за шагом: Удаленное журналирование */

2008-03-26T21:14:08Z

‎Шаг за шагом: Удаленное журналирование

-=JeN=- в 21:11, 26 марта 2008

2008-03-26T21:11:12Z

-=JeN=- в 21:01, 26 марта 2008

2008-03-26T21:01:15Z

-=JeN=- в 20:51, 26 марта 2008

2008-03-26T20:51:12Z

-=JeN=- в 16:34, 10 марта 2008

2008-03-10T16:34:30Z

-=JeN=-: Новая: == Ведение журналов Syslog и его окрестности. Записки демонов == ''Учитесь правильно читать файлы журналов:...

2008-03-10T15:58:04Z

Новая: == Ведение журналов Syslog и его окрестности. Записки демонов == ''Учитесь правильно читать файлы журналов:...

Новая страница

== Ведение журналов Syslog и его окрестности. Записки демонов ==
''Учитесь правильно читать файлы журналов: они дают ценные данные о вашей системе. '''Д-р Крис Браун''' начинает серию руководств из двух частей с рассказа о '''syslogd''' ''
<br /><br />

Не будем врать: файлы журналов, вероятно, скучнейшие из всех в Linux-системе. Они однообразны и нудны, и просматривать их – все равно что перематывать бесконечные видеозаписи службы безопасности в поисках чего-нибудь интересного. Вдобавок сообщения в журнале часто пишутся в расчете на разработчика, а не конечного пользователя, и понять их трудно. Логично спросить: зачем вообще смотреть файлы журналов? Никуда не денешься: файлы журналов рассказывают о сервисах системы (демонах) и других программах, которые не имеют видимого пользователю интерфейса и не могут сами рассказать о своих действиях и ошибках. Файлы журналов – это записки демонов.

Например:
# Файлы журналов сообщат, насколько загружен сервер. Допустим, вам нужно выставить счет за его использование или понять, хорошо ли сервер работает как средство маркетинга или доставки данных. Журналы web-сервера особенно важны, и существует довольно много инструментов, позволяющих выдавать статистику на основе файлов журналов сервера ''Apache''.
# Файлы журналов помогут выявить ошибки в настройках (например, неправильные настройки авторизации) или отсутствие файлов (например, ошибки типа ‘404 файл не найден’).
# Файлы журналов прояснят, почему сервис не желает правильно запускаться. Это особенно ценно при первом запуске приложения после изменений в настройке. Мудрые администраторы запускают '''tail -f''' на файле журнала (тогда можно просматривать файл по мере его роста) в одном окне терминала, а в другом запускают сервер.
# Файлы журналов расскажут, что кто-то норовит вломиться в вашу систему. Фактически, о любой машине, имеющей внешний видимый IP-адрес, можно утверждать, что кто-то пытается в нее проникнуть. Вопрос, преуспел ли этот кто-то? К примеру, журнал сервера под управлением автора содержит свыше 50000 строк, относящихся к попыткам проникновения – и это только за одну неделю!

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

@@ Строка 115: / Строка 115: @@
 === Взгляд разработчика ===
 Прежде чем покинем syslog, взглянем на журналирование с точки зрения разработчика демона (не путать с заклинателями демонов). Сообщения в ''syslogd легко'' посылать из программы на С.
   #include <syslog.h>
   #include <fcntl.h>
@@ Строка 125: / Строка 126: @@
      return 0;
+  }
+</source>
 Первый аргумент '''openlog''' – это идентификатор, который будет появляться во всех сообщениях (обычно имя демона); аргумент '''LOG_PID''' велит включать в сообщение идентификатор процесса демона, а последний аргумент указывает, что сообщения будут поступать от источника '''local6'''. (Эти символические константы определены в файле '''syslog.h'''.) Вызов '''syslog()''' посылает сообщение: первый аргумент – это уровень, а второй аргумент – строка в формате '''printf''', определяющая оставшийся текст сообщения. В примере показан особый код формата – '''%m''', он генерирует текст, описывающий последнюю ошибку – в данном случае, отказ вызова '''open()''' строкой выше. По выполнении программы, в нашем демо-журнале появится результирующая строка:
   Dec 27 19:40:55 frodo mydaemon[22572]: xyzzy: No such file or directory

@@ Строка 169: / Строка 169: @@
 '''1. Обновим файл настройки'''
-Давайте сделаем так, чтобы сообщения приоритета local6.notice журналировались удаленно. Вам потребуется две Linux-системы (назовем их «машина A» и «машина B») и плитка шоколада. На машине A добавим запись в /etc/syslog.conf:
+Давайте сделаем так, чтобы сообщения приоритета local6.notice журналировались удаленно. Вам потребуется две Linux-системы (назовем их «машина A» и «машина B») и плитка шоколада. На машине A добавим запись в '''/etc/syslog.conf''':
   local6.notice @loghost
 '''2. Добавим удаленный IP адрес'''
-Все еще на машине А, добавим в /etc/hosts что-то наподобие
+Все еще на машине А, добавим в '''/etc/hosts''' что-то наподобие
 .168.0.14 loghost
 Подставьте сюда IP-адрес машины B.
@@ Строка 180: / Строка 180: @@
 '''3. Запустим pkill'''
-Теперь прикажите syslogd перечитать файл настройки с помощью команды
+Теперь прикажите ''syslogd'' перечитать файл настройки с помощью команды
   # pkill -HUP syslogd
 '''4. Настроим syslogd'''
-На машине B надо удостовериться, что syslogd запущен с опцией -r так, чтобы он прослушивал UDP-порт. На системе с Fedora, например, потребуется отредактировать /etc/sysconfig/syslog, включив строку:
+На машине B надо удостовериться, что ''syslogd'' запущен с опцией -r так, чтобы он прослушивал UDP-порт. На системе с Fedora, например, потребуется отредактировать '''/etc/sysconfig/syslog''', включив строку:
   SYSLOGD_OPTIONS=”-m 0 -r”
 '''5. Перезапустим демон'''
-На машине B перезапустите syslogd. В Fedora или Red Hat это можно сделать командой
+На машине B перезапустите ''syslogd''. В Fedora или Red Hat это можно сделать командой
   # service syslog restart
-В Ubuntu, где нет sysconfig, понадобится отредактировать скрипт загрузки /etc/init.d/syslogd и добавить флаг -r в определение переменной Syslogd. Затем нужно ввести команду
+В Ubuntu, где нет ''sysconfig'', понадобится отредактировать скрипт загрузки '''/etc/init.d/syslogd''' и добавить флаг -r в определение переменной ''Syslogd''. Затем нужно ввести команду
   # /etc/init.d/sysklogd restart
 для перезапуска демона.
@@ Строка 198: / Строка 198: @@
 '''6. Проверим сокет'''
-На машине B запустите команду netstat -au и проверьте, что на порте syslog открыт активный UDP-сокет.
+На машине B запустите команду '''netstat -au''' и проверьте, что на порте syslog открыт активный UDP-сокет.
 '''7. Зададим местоположение'''
-Далее отредактируйте /etc/syslog.conf, определив, куда должны идти сообщения от local6.notice. Например, добавьте строку
+Далее отредактируйте '''/etc/syslog.conf''', определив, куда должны идти сообщения от '''local6.notice'''. Например, добавьте строку
   local6.notice /var/log/demolog
-Все еще на машине B, прикажите syslogd перечитать файл, как вы сделали это на машине А в шаге 3.
+Все еще на машине B, прикажите ''syslogd'' перечитать файл, как вы сделали это на машине А в шаге 3.
 '''8. Проверим соединение'''
@@ Строка 213: / Строка 213: @@
 '''9. Убедимся, что оно работает'''
-На машине В проверьте файл /var/log/demolog и убедитесь, что сообщение прибыло. Если да, поздравляем: удаленное журналирование готово! Если вы еще потихоньку не съели свой шоколад, можете сделать это сейчас. Нам он больше не понадобится. Заметим: если удаленное журналирование отказывается работать, проверьте, пропускает ли брандмауэр трафик syslogd на каждой из машин.
+На машине В проверьте файл '''/var/log/demolog''' и убедитесь, что сообщение прибыло. Если да, поздравляем: удаленное журналирование готово! Если вы еще потихоньку не съели свой шоколад, можете сделать это сейчас. Нам он больше не понадобится. Заметим: если удаленное журналирование отказывается работать, проверьте, пропускает ли брандмауэр трафик syslogd на каждой из машин.
 В установках Linux по умолчанию он, скорее всего, заблокирован.

← Предыдущая		Версия 21:11, 26 марта 2008
Строка 215:		Строка 215:
	На машине В проверьте файл /var/log/demolog и убедитесь, что сообщение прибыло. Если да, поздравляем: удаленное журналирование готово! Если вы еще потихоньку не съели свой шоколад, можете сделать это сейчас. Нам он больше не понадобится. Заметим: если удаленное журналирование отказывается работать, проверьте, пропускает ли брандмауэр трафик syslogd на каждой из машин.		На машине В проверьте файл /var/log/demolog и убедитесь, что сообщение прибыло. Если да, поздравляем: удаленное журналирование готово! Если вы еще потихоньку не съели свой шоколад, можете сделать это сейчас. Нам он больше не понадобится. Заметим: если удаленное журналирование отказывается работать, проверьте, пропускает ли брандмауэр трафик syslogd на каждой из машин.
	В установках Linux по умолчанию он, скорее всего, заблокирован.		В установках Linux по умолчанию он, скорее всего, заблокирован.
		+
		+	==== Разбор общего формата журналов ====
		+	[[Изображение:Lxf91 razbor.PNG]]
		+
		+	==== Syslog.conf парой слов ====
		+	[[Изображение:Lxf91 syslogconf.PNG]]

← Предыдущая		Версия 21:01, 26 марта 2008
Строка 163:		Строка 163:
	LXF91 14:41:54 from chris: конец руководства		LXF91 14:41:54 from chris: конец руководства
	LXF91 14:42:44 from chris: последнее сообщение повторилось 42 раза		LXF91 14:42:44 from chris: последнее сообщение повторилось 42 раза
		+
		+	=== Врезки ===
		+
		+	==== Шаг за шагом: Удаленное журналирование ====
		+	'''1. Обновим файл настройки'''
		+
		+	Давайте сделаем так, чтобы сообщения приоритета local6.notice журналировались удаленно. Вам потребуется две Linux-системы (назовем их «машина A» и «машина B») и плитка шоколада. На машине A добавим запись в /etc/syslog.conf:
		+	local6.notice @loghost
		+
		+	'''2. Добавим удаленный IP адрес'''
		+
		+	Все еще на машине А, добавим в /etc/hosts что-то наподобие
		+	192.168.0.14 loghost
		+	Подставьте сюда IP-адрес машины B.
		+
		+	'''3. Запустим pkill'''
		+
		+	Теперь прикажите syslogd перечитать файл настройки с помощью команды
		+	# pkill -HUP syslogd
		+
		+	'''4. Настроим syslogd'''
		+
		+	На машине B надо удостовериться, что syslogd запущен с опцией -r так, чтобы он прослушивал UDP-порт. На системе с Fedora, например, потребуется отредактировать /etc/sysconfig/syslog, включив строку:
		+	SYSLOGD_OPTIONS=”-m 0 -r”
		+
		+	'''5. Перезапустим демон'''
		+
		+	На машине B перезапустите syslogd. В Fedora или Red Hat это можно сделать командой
		+	# service syslog restart
		+	В Ubuntu, где нет sysconfig, понадобится отредактировать скрипт загрузки /etc/init.d/syslogd и добавить флаг -r в определение переменной Syslogd. Затем нужно ввести команду
		+	# /etc/init.d/sysklogd restart
		+	для перезапуска демона.
		+
		+	'''6. Проверим сокет'''
		+
		+	На машине B запустите команду netstat -au и проверьте, что на порте syslog открыт активный UDP-сокет.
		+
		+	'''7. Зададим местоположение'''
		+
		+	Далее отредактируйте /etc/syslog.conf, определив, куда должны идти сообщения от local6.notice. Например, добавьте строку
		+	local6.notice /var/log/demolog
		+	Все еще на машине B, прикажите syslogd перечитать файл, как вы сделали это на машине А в шаге 3.
		+
		+	'''8. Проверим соединение'''
		+
		+	Теперь все установлено. Проверьте настройку, запустив на машине А:
		+	# logger -p local6.notice “Тестирование удаленного журналирования”
		+
		+	'''9. Убедимся, что оно работает'''
		+
		+	На машине В проверьте файл /var/log/demolog и убедитесь, что сообщение прибыло. Если да, поздравляем: удаленное журналирование готово! Если вы еще потихоньку не съели свой шоколад, можете сделать это сейчас. Нам он больше не понадобится. Заметим: если удаленное журналирование отказывается работать, проверьте, пропускает ли брандмауэр трафик syslogd на каждой из машин.
		+	В установках Linux по умолчанию он, скорее всего, заблокирован.

← Предыдущая		Версия 20:51, 26 марта 2008
Строка 105:		Строка 105:

	Если посылать одно и тоже сообщение '''syslogd''' много раз подряд, то '''syslogd''' будет сохранять их раз в минуту и добавлять отметку вроде ‘'''last message repeated 22 times'''’ [«последнее сообщение повторялось 22 раза»] в конце каждого интервала времени. Это не дает демонам распоясаться и затопить файлы журналов потоком однотипных сообщений.		Если посылать одно и тоже сообщение '''syslogd''' много раз подряд, то '''syslogd''' будет сохранять их раз в минуту и добавлять отметку вроде ‘'''last message repeated 22 times'''’ [«последнее сообщение повторялось 22 раза»] в конце каждого интервала времени. Это не дает демонам распоясаться и затопить файлы журналов потоком однотипных сообщений.
		+
		+	=== Централизация журналов ===
		+	По умолчанию, ''syslogd'' прослушивает Unix-сокет '''/dev/log''', то есть доступен только процессам на локальной машине. Однако он также может прослушивать и UDP-сокет, и, как мы уже видели, одним из действий syslog является перенаправление сообщения в ''syslogd'' на удаленной машине. Это позволяет централизовать подсистему журналирования в вашей сети, выделив одну машину полностью под работу с журналами, чтобы другие просто пересылали ей свои сообщения. У такого подхода есть несколько преимуществ. Первое, сбор журналов на одной машине упрощает их анализ. Второе, это более безопасно. Если журналы хранятся на машине локально, коварный нарушитель может отредактировать их и замести свои следы; а если журналы хранятся на другой машине, то до нее надо еще добраться.
		+
		+	Однако с точки зрения безопасности удаленное журналирование имеет и недостаток: уязвимость к атакам на отказ в обслуживании от тех, кто просто посылает лавину сообщений в ''syslogd'', пока не забьет весь диск. Поэтому имеет смысл установить на узле, ведущем журнал, брандмауэр и принимать пакеты на порт syslog (UDP-порт 514) только из своей локальной сети.
		+
		+	Вы заметите, что ''syslogd'' очень гибок в настройке обработки сообщений. Сложите все сообщения в один файл, разбейте их по нескольким файлам или просто передайте их удаленной машине – выбор за вами. На своих системах вы найдете различные вариации файла '''syslog.conf'''. Одно из преимуществ использования ''syslogd'' – для изменения стратегии ведения журнала достаточно отредактировать один файл.
		+
		+	=== Взгляд разработчика ===
		+	Прежде чем покинем syslog, взглянем на журналирование с точки зрения разработчика демона (не путать с заклинателями демонов). Сообщения в ''syslogd легко'' посылать из программы на С.
		+	#include <syslog.h>
		+	#include <fcntl.h>
		+	int main()
		+	{
		+	openlog(“mydaemon”, LOG_PID, LOG_LOCAL6);
		+	if (open(“/etc/xyzzy”, O_RDONLY) < 0) {
		+	syslog(LOG_NOTICE, “xyzzy: %m”);
		+	}
		+	return 0;
		+	}
		+
		+	Первый аргумент '''openlog''' – это идентификатор, который будет появляться во всех сообщениях (обычно имя демона); аргумент '''LOG_PID''' велит включать в сообщение идентификатор процесса демона, а последний аргумент указывает, что сообщения будут поступать от источника '''local6'''. (Эти символические константы определены в файле '''syslog.h'''.) Вызов '''syslog()''' посылает сообщение: первый аргумент – это уровень, а второй аргумент – строка в формате '''printf''', определяющая оставшийся текст сообщения. В примере показан особый код формата – '''%m''', он генерирует текст, описывающий последнюю ошибку – в данном случае, отказ вызова '''open()''' строкой выше. По выполнении программы, в нашем демо-журнале появится результирующая строка:
		+	Dec 27 19:40:55 frodo mydaemon[22572]: xyzzy: No such file or directory
		+
		+	Чтобы регистрировать сообщения из сценария на языке оболочки,
		+	конечно, используется команда '''logger''', изученная нами ранее.
		+
		+	=== Путь Apache ===
		+	Syslog – не единственный способ ведения журналов. Некоторые сервисы – в частности, ''Samba'' и ''Apache'' – делают все сами. Где находятся эти журналы и что именно в них пишется, определяется в собственном файле настройки сервиса. «Место жительства» файла настройки ''Apache'' варьируется от дистрибутива к дистрибутиву; в Fedora, например, это '''/etc/httpd/conf/htppd.conf'''.
		+
		+	''Apache'' обычно ведет два журнала: журнал передач и журнал ошибок. Вообще-то журнал ошибок создается независимо от того, просите вы об этом или нет, но вы можете явно определить его расположение директивой '''ErrorLog'''; например:
		+	ErrorLog /var/log/Apache/errorlog
		+
		+	Вы можете также попросить ''Apache'' вести журнал через ''syslogd'', например:
		+	ErrorLog syslog:local2
		+	где '''local2''' – источник, от имени которого будет вестись журнал '''syslog'''.
		+
		+	Директива '''LogLevel''' поможет вам управлять уровнем подробностей в журнале ошибок. Например,
		+	LogLevel crit
		+	– инструкция для журналирования сообщений уровня crit и выше. Список доступных уровней идентичен списку ''syslogd''. Будьте осторожны при журналировании сервера предприятия: слишком подробное
		+	описание моментально заполнит ваш диск!
		+
		+	Apache пишет строку передачи при каждом запросе страницы браузером. Журнал передач создается только тогда, когда вы явно запрашиваете это в файле настройки с помощью директивы '''TransferLog''':
		+	TransferLog /var/log/Apache/transferlog
		+
		+	На самом деле, ''Apache'' часто настраивается на ведение нескольких журналов передачи (по одному на виртуальный узел), но мы здесь ограничимся ситуациями попроще. Можно также направить ваш журнал в другую программу. Чаще всего это программа ''Rotatelogs'', она периодически закрывает журнал и начинает новый. (''Rotatelogs'' включе на в состав ''Apache''. Не путайте ее с утилитой более общего назначения ''logrotate'', которой мы займемся в следующий раз.) Директива, позволя ющая передать журнал в вашу программу через канал, выглядит так:
		+	TransferLog “\| rotatelogs”
		+
		+	''Apache'' пишет журналы передач в формате, известном как «общий формат журналов» (common log format). Он широко поддерживается большинством web-серверов, инструментами анализа файлов журналов и рассмотрен во врезке «Разбор общего формата журналов», выше.
		+
		+	Еще один журнал, иногда оказывающийся полезным для диагностики – журнал X-сервера, обычно '''/var/log/Xorg.0.log'''. Этот файл переписывается каждый раз при перезапуске X-сервера. 0 в имени файла – это номер дисплея X-сервера, и если у вас в системе несколько мониторов, вы можете найти дополнительные файлы, относящиеся к разным дисплеям.
		+
		+	Наконец, существует собственный «поток сознания» ядра – сообщения, которые оно создает при загрузке. Они даже не записываются в файл (многие из них генерируются на ранней стадии процесса загрузки, до того, как станет доступна файловая система), а хранятся в памяти ядра – «кольцевом буфере [ring buffer]», который отображает команда ''dmesg''. Некоторые дистрибутивы скидывают вывод dmesg в файл на поздних стадиях загрузки системы; например, Red Hat и Fedora пишут его в '''/var/log/dmesg'''. Большая часть этих сообщений создается модулями ядра при попытке определения и инициализации ассоциированного с ними оборудования, и они загадочны даже по стандартам Linux. Их внимательное изучение при случае поможет определить, распознается ли ваше оборудование, но для большей части
		+	сообщений dmesg есть два выхода: игнорировать их или отправить гуру для удаленной диагностики.
		+
		+	В следующий раз мы рассмотрим некоторые типичные журналы; а пока –
		+	LXF91 14:41:54 from chris: конец руководства
		+	LXF91 14:42:44 from chris: последнее сообщение повторилось 42 раза

← Предыдущая		Версия 16:34, 10 марта 2008
Строка 12:		Строка 12:

	В данной серии из двух уроков мы хотели бы помочь вам понять и настроить процесс регистрации событий. Начнем с создания файлов журналов, затем разберемся, как и где настроить журналируемые события. А через месяц рассмотрим некоторые инструменты для управления, анализа и обобщения этих файлов.		В данной серии из двух уроков мы хотели бы помочь вам понять и настроить процесс регистрации событий. Начнем с создания файлов журналов, затем разберемся, как и где настроить журналируемые события. А через месяц рассмотрим некоторые инструменты для управления, анализа и обобщения этих файлов.
		+
		+	=== Тонкости Syslogd ===
		+	Нет единого жесткого правила, определяющего, что нужно записывать. По сути, сервис записывает сообщение при совершении действия, которое создатель программы посчитал достойным упоминания. FTP-
		+	сервер может создавать запись каждый раз при запросе файла; ядро – находя новое устройство; и т.д., причем обычно стараются записывать события, выходящие за рамки обычных.
		+
		+	Некоторые сервисы, например, ''Apache'', ведут свои собственные журналы. Другие – включая почту, печать, подсистему безопасности, ''Cron'' и ядро – делают записи с помощью отдельного демона, ''syslogd'', обрабатывающего сообщения от их имени. Рассмотрим сначала метод ''syslog''.
		+
		+	Отправляя записи через ''syslogd'', сервисы не только передают тексты сообщений, но и указывают ‘источник’ (facility) и ‘уровень’ (level). Источник идентифицирует подсистему, от которой пришло сообщение, а уровень означает его важность. Syslog имеет файл настроек, определяющий, куда посылать то или иное сообщение, на основе его источника и уровня (как мы увидим, записи не обязательно направляются в журнал, хотя это их обычный путь).
		+
		+	Список источников включает '''auth, authpriv, cron, daemon, fpm kern, lpr, mail, news, syslog, user, uucp''' и от '''local0''' до '''local7'''. Восемь источников '''local''' ''syslogd'' предоставляет для пользовательских нужд. Кому интересно, '''uucp''' означает ‘Unix to Unix copy’, это древний набор программ для удаленной передачи файлов и выполнения программ. Название также выдает возраст syslog: он начал использоваться с 1980-х.
		+	Существует восемь возможных уровней, начиная от щадящего до катастрофического, как показано в таблице «''Уровни Syslog''». (Описание каждого уровня является нашей интерпретацией). Между прочим, некоторые авторы используют термин ‘приоритет’, а не ‘уровень’, но большая часть документации по syslog использует термин ‘приоритет’ для обозначения комбинации источника и уровня. Будьте осторожны – возможны недоразумения.
		+
		+	Что происходит, когда сообщение доходит до ''syslogd''? Это зависит от файла настройки, но возможны пять вариантов:
		+	*Оно может быть добавлено в файл. Это наиболее распространенный выбор.
		+	*Оно может выдано на терминал любого указанного пользователя.
		+	*Оно может быть записано в FIFO (именованный канал). Это бывает полезно при отладке; или можно запустить grep и вытаскивать интересные сообщения из FIFO, пользуясь шаблоном регулярного выражения.
		+	*Оно может быть перенаправлено syslogd, находящемуся на удаленном узле.
		+	*Наконец, если для сообщения не определено, что с ним делать, оно просто игнорируется.
		+
		+	Мы скоро рассмотрим каждое из этих действий подробно. А сейчас
		+	займемся самым важным файлом настройки, '''/etc/syslog.conf''', который
		+	связывает все вместе. Вот возможные варианты строк этого файла.
		+	Это не настоящие настройки, просто набор примеров для пояснения
		+	синтаксиса. Номера строк даны для удобства ссылки – в сам файл они
		+	не входят.
		+	1 mail.err /var/log/mail
		+	2 mail.* /var/log/mail
		+	3 mail.debug /var/log/mail
		+	4 *.crit /var/log/critical
		+	5 . @loghost
		+	6 mail.=debug /var/log/maildebug
		+	7 mail.warn;cron.notice var/log/messages
		+	8 .;auth.none /var/log/messages
		+	9 auth,kern.crit /var/log/critical
		+	10 .;auth,kern.none /var/log/messages
		+	11 .=debug;.=info -/var/log/messages
		+	12 *.crit root
		+	13 .crit
		+	14 .=notice;.=warn \|/dev/xconsole
		+
		+	Каждое правило содержит селектор и действие. Так, в строке 1
		+	селектором является '''mail.err'''. Это значит, что правило применяется к
		+	сообщениям от источника '''mail''' уровня '''err''' или выше; то есть уровни '''err,
		+	crit, alert''' или '''emerg'''. Затем идет действие – добавить сообщение в файл
		+	'''/var/log/mail'''. Легко, правда?
		+
		+	Правила бывают и посложнее. Селекторы допускают символы подстановки ('''*''') как для источника, так и для уровня. Так, селектор в строке '''2''' означает ‘все сообщения от источника '''mail'''’ согласно принципу ‘от этого уровня и выше’, строка '''3''' делает то же самое. Селектор в строке '''4''' означает ‘сообщения уровня crit (или выше) от любого источника’, а строка '''5''', понятное дело, применяется ко всем сообщениям. Знак равенства ('''=''') перед уровнем означает, что правило применимо только к этому уровню, поэтому правило в строке '''6'''применимо сообщениям от источника '''mail''' только уровня '''debug'''. Можно указать несколько селекторов, разделив их точкой с запятой(''';''') как показано в строке '''7''' (такой же эффект достигается написанием двух отдельных правил). Пустой уровень none используется для исключения всех сообщений от данного источника и обычно используется вместе с ''';''', как показано в строке '''8''', соответствующей всем сообщениям, кроме идущих от источника auth.
		+	{{Врезка\|left\|
		+	Заголовок=Новое поколение\|
		+	Содержание=
		+	Некоторые из последних дистрибутивов – отметим SUSE – заменили
		+	''syslogd'' на ''syslog-ng''. Этот демон обратно совместим с syslogd (он все
		+	еще использует источники и уровни), но дает системному администра-
		+	тору больший контроль над тем, откуда приходит сообщение и куда оно
		+	пересылается (ценой усложнения файла настройки). Сообщения могут
		+	выбираться на основе регулярных выражений, и для удаленного журна-
		+	лирования используется TCP, а не UDP. Если вы хотите, чтобы мы рас-
		+	смотрели syslog-ng подробно, пишите на letters@linuxformat.ru.\|
		+	Ширина=350px}}
		+	Наконец, если надо, чтобы селектор включал несколько источников одного уровня, отделите имена источников запятой (''',''') как показано в строке '''9'''. Между прочим, для сообщения вполне нормально соответ-
		+	ствовать более чем одному селектору – '''syslogd''' просто выполнит все предписанные действия, по очереди.
		+
		+	=== Предпринимаем действие ===
		+	Как мы уже упомянули, чаще всего сообщения добавляются к файлу; вы просто определяете в качестве действия (абсолютный) путь к нему, как мы делали в наших примерах. Обычно '''syslogd''' сбрасывает свои буферы на диск после каждой записи. Это увеличивает шансы сообщения попасть в файл до того, как система рухнет, но это также значит, что менее критичные (и более объемные) сообщения уровней '''debug, '''info''' и '''notice''' вызывают излишнюю дисковую активность. Поставив дефис ('''-''') перед именем файла, вы разрешите '''syslogd''' не сбрасывать буферы на диск каждый раз (см. строку '''11'''). Можно попросить сообщение отобразиться на консоль любого подключенного пользователя ('''root''' является фаворитом), определив в качестве действия имя учетной записи, как в строке '''12'''.
		+
		+	Здесь также применяется символ подстановки ('''*'''); действие в строке '''13''' означает ‘написать всем подключенным пользователям’. Во времена, когда системный администратор постоянно сидел в текстовой консоли (если такое вообще было), это имело значение, но настольные компьютеры работают в графическом режиме, а за серверами особо не присматривают. Вы можете заставить '''syslogd''' перенаправлять сообщения на удаленную машину, добавив знак @ перед именем машины, указанным в качестве действия; пример приведен в строке '''5''', но мы подробно рассмотрим его попозже.
		+
		+	Наконец, можно велеть syslogd записывать сообщения в именованный канал, поставив символ канала ('''\|''') перед его именем; пример – строка '''14''' (взятая из стандартного '''syslog.conf''' в Ubuntu).
		+
		+	=== Поэкспериментируем ===
		+	В порядке иллюстрации, настроим '''syslogd''' так, чтобы он посылал все сообщения от источника '''local6''' в файл '''/var/log/daemon'''. Для внесения изменений необходимо быть суперпользователем. Добавьте в файл '''syslog.conf''' строчку:
		+	local6.notice /var/log/demolog
		+
		+	Далее, из командной строки, пошлите '''syslogd''' сигнал '''SIGHUP''', что-
		+	бы он перечитал файл.
		+
		+	# pkill -HUP syslogd
		+
		+	Для отправки сообщения в '''syslogd''' из командной строки служит команда '''logger'''. Вот типичный пример ее использования (опция '''-p''' указывает на источник и уровень сообщения):
		+
		+	# logger -p mail.info “Тестовое сообщение от источника mail”
		+
		+	Чтобы послать сообщение с созданным нами приоритетом '''local6.notice''', выполните
		+
		+	# logger -p local6.notice “Это тест”
		+
		+	Теперь просмотрите файл '''/var/log/demolog'''. Там должна быть примерно такая строка:
		+
		+	Dec 27 10:38:38 frodo chris: Это тест
		+
		+	Вы увидите, что '''syslogd''' предварил сообщение некоторой информацией: в данном случае это отметка времени, имя машины и UID процесса, пославшего сообщение. Попробуйте записать сообщения от источника '''local6''' с различными уровнями и проверить, какие уровни записываются.
		+
		+	Если посылать одно и тоже сообщение '''syslogd''' много раз подряд, то '''syslogd''' будет сохранять их раз в минуту и добавлять отметку вроде ‘'''last message repeated 22 times'''’ [«последнее сообщение повторялось 22 раза»] в конце каждого интервала времени. Это не дает демонам распоясаться и затопить файлы журналов потоком однотипных сообщений.