Демоны в Linux. Кто они или что они? FreeBSD tips: использование syslog auth Системы защиты и полномочий

Протокол syslog и программные средства поддержки обеспечивают запись информации о событиях в системный журнал (журналы, системную консоль), а также передачу их на сервер журнализации по сети, сортировку и обработку в зависимости от источника и важности сообщений. В статье описывается протокол syslog, его реализация в Solaris и Linux (syslogd), Cisco IOS, а также вспомогательные средства: logrotate, logwatch.

Компонентами системы являются генератор сообщений (устройство или процесс), протокол обмена, коллектор сообщений (collector, syslog server), релей (relay, принимает сообщения от одного или нескольких генераторов и передает одному или нескольким коллекторам или следующим релеям). Генератор (или релей при передаче) не знает является ли приемник релеем или коллектором, может передавать одно сообщение нескольким приемникам, может обрабатывать сообщение самостоятельно (например, записывая в файл).

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

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

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

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

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

RFC 3195 предлагает новый протокол над TCP (syslog-conn, 601), обеспечивающий гарантированную доставку в правильной последовательности. Реализация мне не известна. Чудовищная смесь XML, команд и кодов возврата в стиле SMTP и заголовков MIME (BEEP), в которую заворачиваются сообщения стандартного формата syslog. Используется два режима - RAW (аналог нынешнего UDP протокола) и COOKED (сообщения структурированы по полям). BEEP позволяет обеспечить аутентификацию, целостность и конфиденциальность (SASL, TLS).

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

Для приема сообщений используется порт 514/UDP. Рекомендуется также использовать исходный порт 514 для передачи сообщений. Сообщение представляет собой текстовую строку и не может иметь длину более 1024 байт, в противном случае его разрешается обрезать или даже выбрасывать. Даже неправильно сформированное сообщение, посланное на 514 порт, должно рассматриваться как сообщение syslog. Однако, если релей передает сообщение дальше, то он должен добавить к нему стандартные заголовки (при этом, возможно обрезав его до 1024 байт) - USER, NOTICE, свое локальное время и простое имя источника сообщения.

Сообщение начинается с поля PRI, которое в закодированном виде содержит информацию об источнике сообщения (facility) и уровне серьезности (Severity level) сообщения. За ним записывается время (TIMESTAMP), пробел, имя или IP адрес хоста в десятичной записи (HOSTNAME), пробел, произвольный текст сообщения (MSG) в US-ASCII (0x20 - 0x7e).

Имя хоста (простое, не FQDN!) записывается так, как оно известно генератору сообщения. Если устройство имеет несколько интерфейсов с различными IP-адресами, то в качестве имени или адреса хоста может быть использовано любое из них.

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

syslogd осуществляет прием сообщений с порта 514/UDP и от местных источников (сокет /dev/log), их маршрутизацию в зависимости от источника сообщений и уровня серьезности. Позволяет выводить сообщения в журнал, выводить на консоль, на терминал, посылать на другой сервер. Вводится дополнительный тип источника MARK (регулярные отметки, info)

Каждая строка журнала содержит запись одного сообщения, состоящую из полей, разделенных пробелами:

• дата в стандартном текстовом формате (поле TIMESTAMP из сообщения syslog)
• имя хоста (fqdn или сокращенное, поле HOSTNAME из сообщения syslog)
• текст сообщения (поля TAG и CONTENT из сообщения syslog)

Параметры запуска:

• -a дополнительный-прослушиваемый-сокет (полезен для демонов, делающих chroot; может быть несколько)
• -d (отладочный режим)
• -f имя-конфигурационного-файла (по умолчанию, /etc/syslog.conf )
• -h (изменить обычное поведение, при котором сообщения, принятые от удаленных хостов, не передаются дальше для записи на удаленном хосте во избежание зацикливания)
• -l список-хостов (список хостов, имена которых не должны записываться в виде FQDN; разделяются двоеточием)
• -m минут (интервал для регулярных временных записей; по умолчанию - 20; если 0, то не делать вообще)
• -n
• -p прослушиваемый-сокет (по умолчанию: /dev/log )
• -r (разрешить принимать сообщения от удаленных хостов; firewall д.б. приоткрыт; в /etc/services д.б. определен syslog для 514/udp)
• -s список-доменов (обрезать из имен хостов имена указанных доменов; разделяются двоеточием; по умолчанию обрезается домен, совпадающий с доменом сервера syslog)
• -v
• -x (запретить определять имя хоста по его адресу, предотвращает deadlock при работе на одном хосте с сервером DNS)

Используемые файлы:

• /etc/syslog.conf - конфигурационный файл (изменяется при запуске параметром -f )
• /dev/log - сокет, с которого читаются локальные сообщения (изменяется при запуске параметром -p )
• /var/run/syslogd.pid - идентификатор процесса

Реакция на сигналы:

• SIGHUP - реинициализация (закрывает все файлы, читает заново файл конфигурации)
• SIGTERM - завершение работы
• SIGINT, SIGQUIT - завершение работы, если выключена отладка
• SIGUSR1 - включить/выключить отладку (только при использовании ключа -d)

Запускается с правами root. Не меняет права доступа к файлам. Если вынужден создавать файл, то делает его с правами 644. При необходимости ограничить доступ к журналу, соответствующий файл надо создать вручную (или поменять права доступа). Особые проблемы создает logrotate .

Представляет собой набор правил маршрутизации сообщений. Каждое правило состоит из селектора и действия, которые разделяются табуляциями (в старых системах - Solaris 5) или пробелами (Linux). Получив сообщение для записи в журнал (от klogd, от локальной или удаленной программы), syslogd для каждого правила проверяет не подходит ли сообщение под шаблон, определяемый селектором. Если подходит, то выполняется указанное в правиле действие. Для одного сообщения м.б. выполнено произвольное количество действий (т.е. обработка сообщения не прекращается при первом успехе).

Селектор состоит из двух частей, разделенных точкой: источник сообщения и уровень серьезности. Прописные и строчные буквы не различаются. Можно также использовать числа (см. /usr/include/syslog.h). Кроме определенных в syslog.3 источников, можно указывать mark (регулярные временные метки), security (устаревший синоним для auth ). Кроме определенных в syslog.h уровней серьезности можно использовать warn (синоним для warning ), error (синоним для err ), panic (синоним для emerg ). Сообщения с уровнем, равным или выше указанного в селекторе, и источником, равным указанному в селекторе, считается подходящим. Звездочка перед точкой соответствует любому источнику, после точки - любому уровню. Слово none после точки - никакому уровню для данного источника. Можно указывать несколько источников в одном селекторе (через запятую). В одной строке можно указывать несколько селекторов. Семантика не ясна: если использовать позитивные селекторы, то выполняется логическое ИЛИ , если негативные (none и восклицательный знак), то логическое И .

В новом syslogd (linux) перед уровнем можно поставить знак равенства - селектору будут соответствовать только сообщения с указанным уровнем (но не с высшим); восклицательный знак - не будут соответствовать сообщения с уровнем равным или большим; восклицательный знак и равенство - не будут соответствовать сообщения с уровнем, равным указанному.

В качестве действия можно указывать:

• имя обычного файла (полный путь от корня), минус перед именем отключает синхронизацию записи
• поименнованные каналы - fifo (перед именем ставится вертикальная черта), сам канал д.б. создан перед запуском syslogd командой mkfifo
• терминал или консоль
• @имя-хоста (передать сообщений для удаленной журнализации)
• список пользователей (через запятую), на терминалы которых будет послано сообщение
• звездочка для посылки сообщения на все терминалы (wall)

При разборе файла конфигурации syslogd сравнивает адрес loghost (определяется в /etc/hosts, не через DNS) с адресом своего компьютера и при совпадении определяет переменную LOGHOST . После этого syslog.conf пропускается через макропроцесссор m4(1). В основном, это используется для того, чтобы один и тот же конфигурационный файл можно было использовать на клиентских и серверном (с точки зрения syslog) хостах.

Процедура запуска и остановки: /etc/init.d/syslog (ссылки на нее из директорий /etc/rc?.d). Номер процесса хранится в /etc/syslog.pid .

klogd читает сообщения ядра (либо через /proc/kmsg, либо с помощью системных вызовов), определяет уровень, преобразует адреса команд в имена программ и передает сообщение syslogd.

Параметры запуска:

• -c уровень (сообщения данного уровня и менее серьезные будут передаваться syslog, а более серьезные - выводиться на консоль; по умолчанию - 7; 0 указывать нельзя)
• -d (отладочный режим)
• -f имя-файла (журнализовать в указанный файл вместо syslog)
• -i (перезагрузить символы модулей в уже работающем klogd, необходимо использовать при каждой загрузке или выгрузке модуля; надеюсь, что текущие версии insmod, rmmod и modprobe делают это самостоятельно)
• -I (перезагрузить символы ядра и модулей в уже работающем klogd)
• -k имя-файла (использовать указанный файл как таблицу символов ядра вместо /boot/System.map )
• -n (не уходить в фоновый режим; необходим для запуска из init)
• -o (одноразовый режим - журнализовать все сообщения, скопившиеся в буфере ядра и завершить работу)
• -p (на всякий случай перезагружать таблицу символов модулей в момент преобразования адресов - ядро может оказаться не в состоянии сделать это)
• -s (использовать только системные вызовы и не обращаться к /proc/kmsg для получения исходных сообщений)
• -v (показать версию и закончить работу)
• -x (не преобразовывать адреса в имена)
• -2 (сообщения аварийного завершения ядра - Oops! -выдаются дважды: до преобразования адресов в имена - для ksymoops - и после)

Уровни сообщений ядра (определяется по цифре в угловых скобках и преобразуется в уровень серьезности syslog, при выводе в файл не изменяется):

• KERN_EMERG - 0 (system is unusable)
• KERN_ALERT - 1 (action must be taken immediately)
• KERN_CRIT - 2 (critical conditions)
• KERN_ERR - 3 (error conditions)
• KERN_WARNING - 4 (warning conditions)
• KERN_NOTICE - 5 (normal but significant condition)
• KERN_INFO - 6 (informational)
• KERN_DEBUG - 7 (debug-level messages)

Реакция на сигналы:

• SIGINT, SIGKILL, SIGTERM and SIGHUP - завершение работы
• SIGTSTP - остановить журнализацию
• SIGCONT - возобновить, возможно выбрав другой
источник сообщений (/proc/kmsg или системные вызовы)
• SIGUSR1 - перезагрузить символы модулей
• SIGUSR2 - перезагрузить символы ядра и модулей

Номер процесса хранится в /var/run/klogd.pid .

Инициализация записи в журнал: openlog - указывается стандартный префикс, добавляемый ко всем последующим сообщениям (обычно имя программы, номер процесса в квадратных скобках и двоеточие); источник и опции. closelog - завершить запись в журнал. syslog - запись в журнал (указывается источник, уровень серьезности и формат строки как в printf).

logrotate (версия 3.2-1/3.3.2-1/3.5.9) - борьба с растущими журналами: ротация (создание версий), сжатие, удаление и отправка по почте. Запускается ежедневно cron-ом (/etc/cron.daily/logrotate ) и позволяет обрабатывать журналы, если они превысили указанный размер или с указанным временным интервалом. Позволяет обрабатывать не только журналы syslog, но и любых других программ. Параметры:

• [-d] (отладочный режим, реальных изменений не производится)
• [-f] (производить изменения, даже если logrotate не видит необходимости - используется при изменениях в списке обрабатываемых журналов)
• [-s имя-файла-состояния ] (текущее состояние журналов хранится в этом файле между запусками, по умолчанию - /var/lib/logrotate.status )
• имена-конфигурационных-файлов (имена через пробел; порядок имеет значение; если указано имя директории, то каждый файл в ней считается конфигурационным; в RH используется файл /etc/logrotate.conf и директория /etc/logrotate.d )

Конфигурационный файл определяет глобальные параметры (по одному на строке), задающие параметры по умолчанию для всех журналов. Для каждой серии обрабатываемых журналов задаются локальные параметры: указывается базовое имя файла, а затем в фигурных скобках локальные параметры по одному на строке. Имя файла может быть заключено в кавычки по правилам shell, если оно содержит пробелы и другие специальные символы. Можно указывать несколько имен файлов или шаблонов имен файлов через пробел (шаблоны также по правилам shell). Обработка каждой секции рассматривается как единое действие. Строки, начинающиеся с символа "#" являются комментраиями. Параметры, указанные в следующем конфигурационном файле перекрывают значение параметров, указанных в предыдущем файле. Локальные параметры имеют приоритет над глобальными. Порядок файлов в конфигурационной директории не определен.

Параметры:

• 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 (смена версий происходит еженедельно)

В поставке RH /etc/logrotate.conf описывает глобальные параметры и параметры для /var/log/wtmp и /var/log/lastlog и ссылается на директорию /etc/logrotate.d , в которую каждый пакет записывает локальные параметры для своих журналов.

logwatch представляет собой платформу (framework) для написания программ (называемых фильтрами) извлечения полезной информации из многочисленных, больших и разноформатных журналов (не только syslog). В "пакете" приходит несколько фильтров, рассчитанных на Red Hat Linux (какой-то древней версии, т.к. упоминается inetd вместо xinetd), но адаптировать их под конкретную ситуацию придется самому. Последнее изменение было внесено автором в сентябре 2000, так что дальнейшего развития можно уже не ждать.

Фильтры могут быть написаны на любом языке программирования, но автор пакета предпочитает perl. Фильтры должны быть написаны так, что читают данные с stdin и выводят результат на stdout. Перед вызовом фильтра устанавливаются переменные окружения: LOGWATCH_DATE_RANGE, LOGWATCH_DETAIL_LEVEL, LOGWATCH_TEMP_DIR, LOGWATCH_DEBUG. Основная программа также написана на perl: /etc/log.d/scripts/logwatch.pl (/etc/log.d/logwatch, /usr/sbin/logwatch и /etc/cron.daily/00-logwatch - это символьные ссылки на нее).

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

• LogFile = имя файла, содержащего журнал, или шаблон имен; можно задавать несколько имен или шаблонов; имена м.б. относительно LogDir
• Archive = имя файла, созданного logrotate архивной версии журнала, или шаблон имен; можно задавать несколько имен или шаблонов; имена м.б. относительно LogDir
• имена фильтров (только по одному разу, хотя в показано другое! ) из /etc/log.d/scripts/shared/ в виде
  *имя-фильтра = параметры , например, чтобы отфильтровать журнал по дате, если она записана в стандартном формате syslog, надо использовать строку:
  *ApplyStdDate =

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

• LogFile = имя группы журналов
• имена фильтров из /etc/log.d/scripts/shared/ в виде
  *имя-фильтра = параметры , запускаемых до фильтра сервиса
• $имя-переменной окружения = значение

Директория /etc/log.d/scripts/logfiles/ содержит фильтры обработки групп журналов: при обработке группы журналов все файлы в директории /etc/log.d/scripts/logfiles/имя-группы используются как фильтры.

Директория /etc/log.d/scripts/services/ содержит фильтры обработки записей конкретных сервисов.

Директория /etc/log.d/scripts/shared/ содержит общие фильтры, используемые в конфигурационных файлах групп журналов:

• applystddate - фильтрует журнал по требуемой дате, если он записан в формате syslog (здесь и в приватных фильтрах по дате навставлять LANG= перед вызовом date, а то Mar никак не совпадает с Мар;)
• expandrepeat - превращает строки "last message repeated" в соответствующее число строк с текстом сообщения из предыдущей строки
• onlycontains - оставляет только те строки журнала, которые содержат указанную строку (я поставил кавычки вокруг "$*")
• onlyservice - выделяет из журнала в формате syslog строки, относящиеся к указанному сервису (имя сервиса передается как параметр)
• remove - оставляет только те строки журнала в формате syslog, которые не содержат указанную строку (я поставил кавычки вокруг "$*" и наделал remove1, remove2 и т.д. так как не понял как указать несколько подшаблонов для egrep в одной строке ; кстати, параметры подставляются в shell, так что спецсимволы тоже нельзя использовать)
• removeheaders - удаление стандартных полей (дата, время, имя хоста, этикетка сервиса и номер процесса)
• removeservice - выделяет из журнала в формате syslog строки, не относящиеся к указанному сервису (имя сервиса передается как параметр)

Параметры по умолчанию хранятся в файле /etc/log.d/conf/logwatch.conf (/etc/log.d/logwatch.conf есть символьная ссылка на него), комментарии в котором позволяют понять смысл параметров:

• LogDir - директория, относительно которой рассматриваются имена файлов
• MailTo - кому отправлять отчет
• Print - вместо посылки отчета по почте выдать его на stdout
• Save - вместо посылки отчета по почте сохранит его в указанном файле
• Archives - использовать версии журналов, созданных logrotate
• Range - рассматриваемый временной интервал: All, Today, Yesterday (вчерашние календарные сутки)
• Detail - уровень подробности отчета: от 0 до 10 или Low, Med, High
• Service - All или имя фильтра из /etc/log.d/scripts/services/ (можно указывать несколько фильтров)
• LogFile - All или имя группы журналов (можно указывать несколько групп)

Параметры запуска:

• --detail уровень (уровень продробности отчета: high, med или low)
• --logfile группа-журналов (обрабатывать только журналы данной группы; группа задается символическим именем в конфигурационном файле; можно задавать несколько групп)
• --service имя-сервиса (обрабатывать только те записи в журналах, которые относятся к данному сервису; сервис задается символическим именем в конфигурационном файле; можно задавать несколько сервисов; имя All вызывает обработку записей для всех сервисов)
• --print (выдавать отчет на stdout)
• --mailto адрес (послать отчет по указанному адресу)
• --save имя-файла (записать отчет в указанный файл)
• --archives (обрабатывать не только текущие версии журналов, но и созданные logrotate старые копии)
• --range интервал-дат (обрабатывать только те записи в журналах, которые относятся к данному интервалу времени: Yesterday , Today , All )

Основной способ использования состоит во включении файла 00-logwatch (начинается с "00", чтобы выполняться до logrotate) в директорию /etc/cron.daily, что вызывает ежедневное выполнение logwatch с параметрами по умолчанию.

К сожалению, все фильтры рассчитаны на то, что журналы записываются на том же хосте, на котором работает сервис.

Все журналы ведутся на одном компьютере (если есть параноидальные наклонности, то можно записывать журналы сразу на двух серверах).

Соответствие между формальным именем источника и реальным устройством или программой:

• local0 - Cisco
• local3 - ftp (есть специальное имя источника, но Solaris 2.5 его не знает)
• local4 - зарезервировано под учет
• local5 - POP3/IMAP
• local6 - tac_plus>

На сервере должен быть открыт экран для порта 514/udp (можно ограничить исходные адреса пакетов, но это поможет только от случайностей). Запуск syslogd (параметры в /etc/rc.d/init.d/syslog или /etc/sysconfig/syslog) должен быть с ключами "-r -m 0" (и еще "-x", если на этом же компьютере работает сервер DNS). Запуск klogd с ключами "-2 -c 1". Настройка syslog.conf:

• *.crit - сообщения уровня серьезности CRIT и выше выдавать на терминалы и записывать в отдельный файл (chmod 600), свои сообщения посылать на запасной сервер; sendmail считает критическими сообщения о проблемах с приемом письма
• kern - создать файл kern для сообщений всех уровней (chmod 600)
• mail - создать файл mail для сообщений всех уровней (без синхронизации)
• auth, authpriv - создать файл secure для сообщений всех уровней (chmod 600)
• news - в директории news создать для каждого уровня серьезности отдельный файл (debug без синхронизации)
• cron - создать файл cron для сообщений всех уровней (cron в RH 6.2 и Solaris 2.5 не умеют использовать syslog)
• local0 - в директории cisco создать для каждого уровня серьезности отдельный файл (err и ниже без синхронизации)
• local3 - в директории ftp создать для каждого уровня серьезности отдельный файл (info и debug без синхронизации)
• local5 - создать файл imap.log для сообщений всех уровней
• local6 - создать файл tac_plus.log для сообщений всех уровней
• local7 - файл boot.log (сообщения при загрузке системы и запуске или остановке syslogd и klogd)
• все сообщения уровня INFO и выше, не попавшие в один из определенных выше файлов, записывать в файл messages (chmod 600)

На клиентских компьютерах настраиваем syslog так, чтобы все сообщения передавались на сервер syslog, сообщения об ошибках дублировались в /var/log/syslog, сообщения о критическом состоянии дублировались на консоль, терминалы пользователей. На компьютерах с linux также сбрасывать в локальный файл сообщения о загрузке (local7, boot.log). Запасной сервер syslog должен принимать сообщения критического уровня из сети и записывать их в файл (дырка в экране, ключ запуска "-r").

logrotate: хранить вечно, менять версии по возможности реже (ежемесячно, кроме squid), сбрасывать в отдельные директории (кроме squid) и сжимать (в отложенном режиме, кроме ftpd, linuxconf, sendfax), ошибки и удаляемые файлы посылать мне. Привести в соответствие параметры для syslog.

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

Происхождение термина
В реальном (т.е., не-компьютерном) мире термином (или словом) "демон" обозначают духа (чаще всего - злого) или "внутренний голос". Стоит отметить, что оба эти значения применимы и к программам-демонам в Unix. Подобно мифологическим демонам, демоны в Unix прячутся где-то "за кулисами", стараясь остаться невидимыми. И, подобно внутреннему голосу или нашему подсознанию, они все время "начеку", всегда доступны, всегда могут "проявиться". Само слово "демон" представляет один из тех компьютерных акронимов , происхождение которого так же трудно выяснить, как и решить вопрос о том, была ли вначале курица или яйцо. Предположительно этот термин ("DAEMON") происходит от слов "Disk And Execution MONitor" program.

Задавшись целью изучить вопрос, поехал к одному батюшке, который пользуется компьютером с операционной системой Ubuntu. На всякий случай взял диск с виндой. Мало ли... Человек я прямолинейный, ходить вокруг да около не стал, сразу выдал всю информацию. Объяснял долго и подробно. К моему огромному счастью, воспринял он все это спокойно, местами, пока я рассказывал даже улыбался, особенно когда рассказал о причинах отказа мужа моей сестры от ubuntu. Батюшка, мужик нормальный, ему уже лет 50. Мы еще немного поговорили, точнее поговорил я, чтобы понять что он правильно усвоил то, что я сказал. После чего он мне сказал, дословно не помню, а записать на диктофон, голова не сообразила, поэтому опишу своими словами. В общем в том, что применяется этот термин в линукс, нет ничего страшного, главное вера в Бога.

Введение в сервисы

Демоны, ссылки на которых присутствуют /etc/init.d, призваны работать в Linux как сервисы или службы. Сервисы - это программы, которые запускаются и останавливаются через инициализационные скрипты, расположенные в каталоге /etc/init.d. Многие из этих сервисов запускаются на этапе загрузки системы. Утилита /sbin/service обеспечивает интерфейс (взаимодействие) пользователя с инициализационными скриптами. А сами эти скрипты обеспечивают интерфейс для управления сервисами, предоставляя пользователю опции для запуска, остановки, перезапуска, запроса состояния сервиса и выполнения других воздействий на сервис. К примеру, инициализационный скрипт сервиса httpd имеет следующие опции:

/sbin/service httpd Usage: httpd {start|stop|restart|condrestart|reload|status|fullstatus|graceful|help|configtest}

Вы можете просмотреть текущее состояние всех системных служб с помощью следующей опции утилиты service:

/sbin/service --status-all acpid (pid 2481) is running... anacron (pid 2647) is running... atd (pid 2657) is running... auditd (pid 2189) is running...

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

/sbin/chkconfig --list syslog syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Мы видим, что сервис syslog автоматически запускается при переходе на уровни 2, 3, 4 и 5. Для того, чтобы отключить его запуск на уровнях 3 и 4 (не очень хорошая идея, кстати), можно воспользоваться следующей опцией команды chkconfig:

/sbin/chkconfig --levels 34 syslog off

Утилита /usr/bin/system-config-services предоставляет графический интерфейс к системным службам, позволяющий просматривать и модифицировать их текущее состояние, а также задавать их запуск на различных уровнях исполнения

Давайте посмотрим, как эти сервисы и демоны отображаются в выводе команды ps. Вот небольшая выдержка:

UID PID PPID C STIME TTY TIME CMD root 1 0 0 23:36 ? 00:00:00 init root 2161 1 0 23:37 ? 00:00:00 auditd root 2177 1 0 23:37 ? 00:00:00 syslogd -m 0 root 2180 1 0 23:37 ? 00:00:00 klogd -x root 2207 1 0 23:37 ? 00:00:00 mcstransd root 2254 1 0 23:37 ? 00:00:00 rpc.statd root 2287 1 0 23:37 ? 00:00:00 rpc.idmapd root 2577 1 0 23:37 ? 00:00:00 crond root 2631 1 0 23:37 ? 00:00:00 /usr/sbin/atd root 2654 1 0 23:37 ? 00:00:00 rhnsd --interval 240

Что здесь интересно отметить (кроме того, конечно, что я сегодня слишком поздно засиделся за компьютером)? Для каждого из демонов идентификатор родительского процесса (PPID) равен 1. Это показывает, что демоны были запущены процессом init во время загрузки системы.

Более наглядно этот результат можно видеть в выводе такой полезной команды как "pstree", отображающей "дерево" процессов с указанием "родителей". Вот небольшой фрагмент из вывода pstree:

Init-+ |-NetworkManager---2*[{NetworkManager}] |-NetworkManagerD |-acpid |-atd |-auditd-+-python | `-{auditd} |-avahi-daemon---avahi-daemon |-bonobo-activati---{bonobo-activati} |-crond |-cupsd---cups-polld |-2* |-dbus-launch |-dhcdbd---dhclient

Подробнее о демонах в вашей системе

С вводной информацией покончили. Теперь давайте поговорим о системных демонах по отдельности и посмотрим, с какими из них можно безопасно экспериментировать. Отмечу еще раз, что в этой заметке идет речь о системе, использующей Red Hat Enterprise Linux Beta 2, в конфигурации рабочей станции. В зависимости от специфики вашей системы вы можете увидеть большее или меньшее число демонов, в том числе и таких, которые здесь не рассматриваются.

В описании каждого демона приведены ссылки на сайты, где вы сможете получить дополнительную информацию, но все же лучше всего начинать изучение демонов с просмотра соответствующих man-страниц. У O"Reilly имеется великолепный список команд Linux, перечисленных в алфавитном порядке, и в википедии (wikipedia.org) также приведены разделы по большинству из этих демонов. Еще не забудьте заглянуть в файлы README.

Это служба усовершенствованного интерфейса конфигурирования системы и управления энергопитанием (the Advanced Configuration and Power Interface - ACPI). ACPI - это открытый промышленный стандарт, определяющий действия по управлению системой, в первую очередь - определение устройств по принципу plug-and-play и управлению питанием, в том числе действия при запуске и остановке системы, а также при переводе ее в режим пониженного энергопотребления.

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

Дополнительная информация: http://www.acpi.info

Если вы используете лэптоп, как делают многие в наши дни, то одна из проблем заключается в том, что, задавая какую-то работу демону cron, вы не всегда уверены в том, что ваш комьютер будет включен в то время, на которое назначено выполнение задания. Anacron (это название происходит от "anachronistic cron", то есть что-то вроде "устаревший cron") решает эту проблему путем проверки того, выполнялись ли задания в определенный промежуток времени. Например, anacron запустит задачу на выполнение, если она не запускалась заданное число дней.

В каких случаях вы можете отказаться от использования anacron? Если ваша система запущена постоянно.
Можете ли вы просто отказаться от запуска cron, если у вас запущен anacron? Нет; для anacron период перезапуска заданий может быть задан только в днях, а не в минутах и секундах.

Дополнительная информация:

Это демон расширенного управления питанием (the Advanced Power Management - APM) через драйвер в BIOS. Стандарт APM и демон apmd в настоящее время заменены на ACPI и acpid. Если ваша аппаратура поддерживает ACPI, вам нет нужды запускать apmd.

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

Этот демон автоматически монтирует диски и файловые системы, которые определены в конфигурационном файле. Использование этого демона делает более удобной работу со съемными дисками.

Дополнительная информация: http://freshmeat.net/projects/autofs

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

Нужно ли держать auditd в запущенном состоянии? Информация из журналов протоколирования может быть очень полезной в настройке всего, что связано с безопасностью системы. Например, auditd используется в протоколировании событий SELinux. Существуют также такие утилиты, как aureport, которые позволяют вам просматривать журналы аудита. Вот пример отчета, созданного утилитой aureport:

Summary Report
======================

Range of time in logs: 11/28/2006 06:07:04.800 - 02/06/2007 21:10:09.957 Selected time for report: 12/31/1969 19:00:00 - 02/06/2007 21:10:09.957 Number of changes in configuration: 285 Number of changes to accounts, groups, or roles: 32 Number of logins: 145 Number of failed logins: 11 Number of users: 2 Number of terminals: 22 Number of host names: 11 Number of executables: 27 Number of files: 91 Number of AVC denials: 688 Number of MAC events: 12 Number of failed syscalls: 404 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 0 Number of process IDs: 14022 Number of events: 70694 Avahi-daemon и avahi-dnsconfd

Веб-сайт Avahi дает такое определение: "Avahi - это система, которая обеспечивает возможность обнаружения сервисов в локальной сети. Это означает, что после подключения вашего компьютера к локальной сети вы сможете мгновенно обнаружить доступные принтеры, увидеть, какие разделяемые ресурсы имеются в сети, узнать, с кем из других пользователей сети вы можете поговорить через chat и так далее". Avahi является реализацией протокола Zeroconf. А Zeroconf - это подход, который позволяет пользователям создавать IP-сети без специальных конфигурационных служб типа DNS-серверов.
Чаще всего avahi-daemon используется вместе с Rhythmbox, так что вы можете видеть музыкальные файлы, которые сделаны общедоступными для других. Если вы не предоставляете музыку или файлы с вашего компьютера в общий доступ, вы можете отключить этого демона.

Дополнительная информация: http://avahi.org , http://zeroconf.org

Bluetooth и демоны hidd и pand

Сами названия все объясняют. Запустите эти сервисы, если хотите использовать Bluetooth-устройства. Название реально запускаемого демона - hcid (Host Controller Interface Daemon).

Название демона hidd происходит от "the Bluetooth Human Interface Device Daemon". Он обеспечивает поддержку клавиатуры, мыши и трекбола по протоколу Bluetooth. А демон pand поддерживает подключение вашего компьютера к ethernet-сети посредством Bluetooth.

Дополнительная информация: http://www.bluetooth.com ,

Этот демон поддерживает the Common ISDN Application Programming Interface (интерфейс прикладного программирования для цифровой сети с интеграцией услуг). Его следует запускать, если вы подключаетесь к аппаратным ISDN-компонентам. Эта служба запускает capiinit.

Дополнительная информация: http://www.capi.org/pages

Нет, это не имеет никакого отношения к ночным передачам про инвестиции в недвижимость. Сервис conman (и демон conmand) поддерживают управление консолями. Обеспечивается поддержка нескольких консольных устройств и одновременная работа пользователей, поддержка локальных последовательных устройств и удаленных терминальных серверов (по протоколу telnet). Если вы управляете несколькими серверами, вам может потребоваться conman.

Дополнительная информация: http://home.gna.org/conman/
cpuspeed

Этот демон изменяет скорость работы центрального процессора с целью снижения энергопотребления. Если ЦПУ простаивает, можно снизить скорость, тем самым понижая затраты энергии, а для повышения производительности прихоодится энергопотребление увеличивать. Если вы работаете на портативном компьютере, имеет смысл запустить cpuspeed.

Дополнительная информация: http://carlthompson.net/Software/CPUSpeed
crond

Этот демон служит для автоматического запуска задач. Это необходимо во всех Linux и Unix-системах. Не останавливайте и не отключайте эту службу.

Дополнительная информация: http://www.unixgeeks.org/security/newbie/unix/cron-1.html , http://www.linuxhelp.net/guides/cron/

CUPS and cups-config-daemon

Это демон общей службы печати UNIX (the "Common UNIX Printing Solution"). Как следует уже из названия, это система печати, которая обеспечивает работу с различными форматами файлов и различными типами принтеров. Если вы хотите печатать, пусть этот демон работает в вашей системе.

Дополнительная информация: http://www.cups.org , http://www.easysw.com/cups/index.php

Название этого демона является аббревиатурой от "DHcp Client D-Bus Daemon". Ресурс The Free DeskTop wiki дает следующее определение:

D-Bus - это система шины сообщений, простой способ общения (или взаимодействия) приложений между собой. В дополнение к межпроцессному взаимодействию (interprocess communication) D-Bus помогает координировать жизненный цикл процесса; она обеспечивает простую и надежную реализацию в программном коде возможности запуска "отдельного экземпляра" приложения или демона, что позволяет запускать приложения и демоны по требованию, тогда, когда возникает потребность в соответствующих сервисах.

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

Демон dhcdbd обеспечивает интерфейс к D-Bus для dhclient, DHCP-клиента от ISC. Это дает возможность NetworkManager-у обращаться к dhclient-у и управлять им.

Дополнительная информация: http://www.freedesktop.org/wiki/Software/dbus

Этот демон дает вам возможность использовать мышь в консольных (text-based) приложениях, таких как файловый менеджер Midnight Commander. Это может оказаться полезным, если вы часто работаете в консоли; в противном случае, то есть если вы все время работаете через систему X Window, gpmd вам может никогда не понадобиться.

Нет, это не злобный компьютер из фильма "Космическая одиссея 2001". В данном контексте HAL означает "Hardware Abstraction Layer" - "уровень абстрагирования от оборудования". Демон HAL собирает (с помощью ядра и самих устройств) информацию об аппаратных устройствах и предоставляет ее приложениям в согласованном виде.

Не отключайте эту службу. Ее используют многие приложения.

Дополнительная информация: "Desktop and hardware configuration," by David Zeuthen

Этот демон обеспечивает поддержку системы HP Linux Imaging and Printing (HPLIP), используемой для печати, сканирования и обработки факсов на струйных и лазерных устройствах от HP. HPLIP взаимодействует с CUPS, обеспечивая для последней доступ к устройствам от HP.

Дополнительная информация:

Это демон для реляционных баз данных на Java. Свое название он унаследовал от проекта Hypersonic SQL, который более не поддерживается. hsqldb широко используется в проектах с открытыми кодами, таких как OpenOffice.org, а также в демонстарционных программах, так как он может исполняется полностью в оперативной памяти. За счет чего быстро работает. Надо ли вам запускать эту службу? Только если вы запускаете какие-то программы, использующие ее. Но вообще-то это очень полезный инструмент и, если вы с ним не знакомы, стоит на него посмотреть.

Дополнительная информация: http://hsqldb.org , http://dba.openoffice.org

Веб-серве Apache. Используется почти на 60% всех веб-сайтов. Если вы хотите поддерживать веб-сайт, вы запускаете Apache. Нужно ли еще что-то говорить?

Дополнительная информация: http://httpd.apache.org

ip6tables и iptables

Это файерволы или межсетевые экраны. Согласно Википедиа, "Межсетевой экран или брандмауэр (жарг. файрвол или файервол от англ. firewall) - комплекс аппаратных и/или программных средств, осуществляющий контроль и фильтрацию проходящих через него сетевых пакетов на различных уровнях модели OSI в соответствии с заданными правилами. Основной задачей сетевого экрана является защита компьютерных сетей или отдельных узлов от несанкционированного доступа."

Iptables работает путем задания правил фильтрации пакетов IPv4 в виде таблицы ядра. Входящие и исходящие пакеты проверяются на соответствие этим правилам и те из них, которые не удовлетворяют правилам, блокируются. Ip6tables делает то же самое по отношению к пакетам IPv6.

Которую из двух служб необходимо запускать? Обе. Всегда. Сеть - это опасная штука!

Дополнительная информация: http://www.netfilter.org , http://www.ipv6.org

IrDA (Infrared Data Association) - это промышленный стандарт для беспроводной связи между устройствами по инфракрасному каналу. Большинство лэптопов оборудовано инфракрасным передатчиком, соответствующим стандарту IrDA. Запускать эту службу нужно только в том случае, если вы собираетесь организовывать связь с другими устройствами по инфракрасному каналу.

Дополнительная информация:

irqbalance

Этот демон занимается распределением аппаратных прерываний между ЦПУ в мультипроцессорных SMP (symmetric processor) архитектурах с целью повышения производительности.

На однопроцессорных системах запускать этот демон нет необходимости, его влияние сказывается только в многопроцессорных системах.

Дополнительная информация: http://www.irqbalance.org

Это очень полезный демон. Он работает во время загрузки и проверяет, какие аппаратные устройства были добавлены в или удалены из системы. Имеет смысл запускать kudzu во время загрузки, даже если вы не планируете часто добавлять или удалять устройства. Потому что рано или поздно вы равно окажетесь в ситуации, когда добавите какое-то устройство и будете ожидать, что система его обнаружит. К тому же, поскольку kudzu отрабатывает на этапе загрузки, это не оказывает отрицательного влияния на производительность системы.

Дополнительная информация: http://fedora.redhat.com/projects/additional-projects/kudzu

Этот демон получил свое название от Lan Information Server. Lisa обеспечивает функционал, подобный тому, который предоставляет служба "Мое сетевое окружение" (Network Neighborhood) в MS-Windows, то есть обеспечивает доступ к серверам вашей локальной сети, включая сервера CIFS (Common Internet File Systems). lisa работает по протоколам TCP/IP, рассылая ICMP-запросы по IP-адресам в заданном диапазоне, который вы указали в конфигурационном файле, и ожидая, какие компьютеры откликнутся.

Дополнительная информация: http://docs.kde.org/stable/en/kdenetwork/lisa , http://docs.kde.org/userguide/networking-with-windows.html ,

lm_sensors

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

Дополнительная информация: http://www.lm-sensors.org , http://freshmeat.net/projects/lm_sensors

mcstrans

SELinux Context Translation System Daemon. Этот демон преобразует информацию контекста безопасности (security context informartion) в форму, приспособленную для восприятия человеком. Вы можете остановить этот демон, но в таком случае вы увидите, что изменится информация SELinux, выдаваемая по команде ls -Z. Например, при запущенном демоне вы увидите:

Ls -Z -rw-r--r-- jsmith jsmith user_u:object_r:user_home_t bookmarks.html drwxr-xr-x jsmith jsmith user_u:object_r:user_home_t Desktop -r-xr-xr-x jsmith jsmith user_u:object_r:user_home_t hello -r--r--r-- jsmith jsmith user_u:object_r:user_home_t hello.c

А если демон остановлен, вы увидите следующее:

Ls -Z -rw-r--r-- jsmith jsmith user_u:object_r:user_home_t:s0 bookmarks.html drwxr-xr-x jsmith jsmith user_u:object_r:user_home_t:s0 Desktop -r-xr-xr-x jsmith jsmith user_u:object_r:user_home_t:s0 hello -r--r--r-- jsmith jsmith user_u:object_r:user_home_t:s0 hello.c

Обратите внимание на то, что если демон остановлен, отображается значение контекста безопасности "s0". Mctrans в данном случае обнулил контекст. Другие значения контекста безопасности преобразуются из буквенно-цифровых значений в их названия.

Дополнительная информация: http://fedoraproject.org/wiki/SELinux/Understanding , http://danwalsh.livejournal.com

mdmonitor и mdmpd

Эти два демона используются в системах хранения данных с RAID-массивами (redundant array of inexpensive/independent disks). Mdmonitor запускает, останавливает и перезапускает mdadm (multipath device monitoring and management) - программную службу мониторинга и управления RAID. Запускать эту службу нужно только в том случае, если в вашей системе имеются RAID-устройства.

Дополнительная информация: http://www.linuxdevcenter.com/pub/a/linux/...12/05/RAID.html

messagebus

Это демон системной шины сообщений D-BUS. Он рассылает широковещательные сообщения о системных событиях и таких событиях, как изменения в очереди печати, или добавление или удаление устройств (заметьте, что это не то же самое, что делает kudzu, поскольку такие события могут иметь место в любой момент работы системы, а не только на этапе загрузки).

Дополнительная информация: http://www.freedesktop.org/software/dbus

netplugd и ifplugd

Эти демоны производят настройку Ethernet-устройств в том случае, когда происходит подключение сетевого кабеля, и отключают эти устройства когда кабель отсоединяется. Когда вам это нужно? Например, на лэптопах, чтобы ваши сетевые подключения восстанавливались только на то время, когда подсоединен сетевой кабель.

Отметим, что поддержка netplugd была прекращена, сейчас вместо него используется ifplugd.

Дополнительная информация: http://0pointer.de/lennart/projects/ifplugd

NetworkManager и NetworkManagerDispatcher

Демон NetworkManager автоматизирует переключение между сетевыми соединениями. Этот демон полезен для пользователей лэптопов, которые переключаются между беспроводными WiFi-соединениями и соединениями по Ethernet. Демон NetworkManagerDispatcher автоматически запускает скрипты для выполнения необходимых операций (например, скрипты для задания специфических направлений маршрутизации пакетов), когда NetworkManager изменяет состояние сети.

Дополнительная информация: http://www.gnome.org/projects/NetworkManager

Это демон, который выполняет функции сервера доменных имен (Domain Name Server). Вы должны его запускать только в том случае, если ваш компьютер является DNS-сервером для вашей сети.

Дополнительная информация: http://www.dns.net/dnsrd

Демон nfsd осуществляет поддержку протокола сетевых коммуникаций nfs, который служит для предоставления доступа к сетевым ресурсам в TCP/IP-сетях. Вам нужно его запускать, если вы предоставляете доступ другим пользователям к своим файловым системам по протоколу nfs.

Дополнительная информация:

Это демон кэширования для службы имен. Он поддерживает таблицу групп и паролей для запущенных программ, а затем выдает запомненный результат по следующему запросу тех служб, которые иначе работают слишком медленно, например, NIS или LDAP. Если у вас запущены эти службы, вам следует запустить и nscd.

Это демон, который поддерживает протокол сетевой службы времени (Network Time Protocol). Он устанавливает системное время и синхронизуирует его со временем, задаваемым Интернет-серверами, поддерживающими эталонное время. Если ваша система подключена к Интернет (а разве нет?), то этот демон будет следить за правильностью установки системного времени на вашем компьютере.

Дополнительная информация: http://www.ntp.org

Демон oddjobd обеспечивает работу службы com.redhat.oddjob на системной шине. Каждая возможность, предоставляемая oddjobd, предоставляется как отдельный метод D-Bus. Oddjobd обеспечивает поддержку выполнения привелигированных операций для непривелигированных приложений.

Запускать этот демон следует только в том случае, если вы используете приложения, которым он необходим, такие как Conga.

Дополнительная информация: http://people.redhat.com/nalin/oddjob/oddjob.html ,

Этот демон поддерживает виртуальные частные стеи (virtual private networks, VPNs). В стартовом скрипте этого демона сказано следующее:

OpenVPN - это надежное и в высшей степени гибкое приложение для обеспечения туннелирования, которое использует возможности шифрования, аутентификации и сертификации, заложенные в библиотеке OpenSSL, для организации безопасного тоннеля в IP-сети через один UDP порт.

Если ваша система является узлом VPN, то вам, вероятно, следует запустить OpenVPN.

Дополнительная информация: http://openvpn.net

pcscd (PC/SC Smart Card Daemon) - демон для pcsc-lite (программное обеспечение для доступа к смарт-картам) и (основанной на java) среде разработки MuscleCard. Он обеспечивает обмен данными со считывателями смарт-карт и самими смарт-картами.

(Смарт-карта - это небольшая плата, в которую встроен либо модуль памяти, дибо микропроцессор с модулем памяти. А Muscle расшифровывается как Movement for the Use of Smart Cards in a Linux Environment (движение за использование смарт-карт в среде Linux).

Дополнительная информация: http://www.smartcardalliance.org , http://pcsclite.alioth.debian.org , http://www.linuxnet.com/musclecard/index.html

Демон portmapper управляет соединениями по протоколу RPC (remote procedure call - удаленный вызов процедур). Он преобразует номера RPC-программ в номера портов протокола TCP/IP (или UDP/IP). Чаще всего portmapper используется службами NFS и NIS.

Так что, если ваша система зависит от NIS или NFS, не отключайте демон portmap.

Дополнительная информация: http://www.linux-nis.org/nis-howto/HOWTO/portmapper.html

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

Дополнительная информация: http://www.postfix.org

Этот демон (the router discovery daemon) находит маршруты в локальной подсети. Он запускается на этапе загрузки для того, чтобы внести в таблицы маршрутизации маршруты, выбираемые по умолчанию.

Дополнительная информация: http://www.informit.com/articles/article.asp?p=23951&rl=1

restorecond

Это демон из SELinux. Restorecond отслеживает создание файлов (для файлов, перечисленных в /etc/selinux/restorecond.conf) и следит за тем, чтобы файлы имели правильный файловый контекст, соответствующий установленой политике (policy), а также определяет файловый контекст SELinux, используемый по умолчанию.

Не отключайте эту службу. Она необходима для SELinux.

Дополнительная информация: http://fedoraproject.org/wiki/SELinux/Understanding , http://danwalsh.livejournal.com/

Этот демон периодически проверяет, какие операции должны быть выполнены через сетевой интерфейс Red Hat (Red Hat Network web interface), и запускает их. Эти операции включают инсталляцию, удаление или обновление программного обеспечения, перезагрузку системы, установку конфигурационных файлов и так далее.

Дополнительная информация: https://www.redhat.com/rhn/

rpcgssd, rpcidmapd и rpcsvcgssd

Демоны rpcgssd и rpcsvcgssd служат для обеспечения безопасности при работе через RPC. Rpcidmapd преобразует имена пользователей в номера UID и GID.

Если вы используете NFS или NIS, эти демоны у вас должны быть запущены.

Дополнительная информация:

readahead_early и readahead_later

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

saslauthd

Это демон сервера аутентификации SASL. SASL (Simple Authentication and Security Layer) добавляет возможности аутентификации в протоколы, основанные на удаленных соединениях.

Дополнительная информация: http://asg.web.cmu.edu/sasl

sendmail

Это сервер SMTP (Simple Mail Transfer Protocol). Sendmail пересылает почту от одной системы к другой, то есть является агентом передачи почты (Mail Transport Agent). Если вы используете такие почтовые программы как Thunderbird или Evolution, вам не требуется запускать sendmail.

Дополнительная информация: http://www.sendmail.org

setroubleshoot

Это демон разрешения проблем SELinux. Setroubleshooter - одно недавних великолепных новшевств в SELinux. Setroubleshooter обеспечивает в реальном времени обратную связь с пользователями при отказах SELInux AVC (Access Vector Cache). Причем эта обратная связь предоставляется в удобном формате.

Дополнительная информация: https://hosted.fedoraproject.org/projects/setroubleshoot

Этот демон следит за показаниями датчиков SMART (Self-Monitoring, Analysis and Reporting Technology), устанавливаемых во многих типах дисководов, например, в жестких дисках типа SCSI-3. Демон обеспечивает наблюдение за нормальной работой таких устройств и выполняет самотестирование. Если ваше оборудование поддерживает технологию SMART, нужно запускать эту службу.

Дополнительная информация:

spamassassin

Этот демон использует программу Apache SpamAssassin для проверки почты на наличие спама. Он обычно запускается совместно с сервером доставки почты (a mail deleivery agent (MDA) server). Если вы используете клиентские программы вроде Thunderbird или Evolution для доступа к вашей почте, вам не требуется запускать spamassassin.

Дополнительная информация: http://spamassassin.apache.org

Это демон для протокола open ssh. Ssh заменяет небезопасные программы rsh и rlogin и обеспечивает шифрование соединений между хостами в небезопасных сетях. Если вы используете соединения с другими системами через открытый Интернет, вы должны использовать ssh и запускать этот демон.

Дополнительная информация: http://www.ssh.com , http://www.openssh.com

syslog - это стандартная система протоколирования для Linux. Не отключайте её.

Дополнительная информация: http://www.syslog.org

Этот демон является частью пакета Samba. Он дает возможность пользователям домена Windows подключаться как пользователям Unix к Unix-серверам. Запускать этот демон следует в том случае, когда вы имеете дело со смешанной сетью, состоящей из Windows и Linux/Unix-компьютеров.

Дополнительная информация: http://www.samba.org/samba/docs/man/Samba-...on/winbind.html , http://www.samba.org

Это сервер шрифтов (font server). Этот демон загружает шрифты в память для того, чтобы графические приложения работали быстрее, чем в том случае, когда они вынуждены загружать шрифты с жесткого диска. Эту службу надо запускать для повышения производительности приложений в вашей системе.

Дополнительная информация: http://linuxreviews.org/howtos/xfree/xfs

Эта служба связывает NIS-клиента с доменом NIS. Буквы "yp" в ее названии произошли от "yellow pages," поскольку каталоги NIS подобны телефонным справочникам "желтые страницы". Запускать эту службу нужно только в том случае, если ваша система использует NIS (Network Information Service) для организации доступа к пользовательским бюджетам и системным именам.

Дополнительная информация: http://www.linux-nis.org

yum-updatesd

yum-updatesd отслеживает появление обновлений программного обеспечения и рассылает извещения об этих обновлениях по электронной почте, d-bus или в виде системных сообщений, а также может произвести автоматическое обновление ПО. D-bus-сообщения принимаются утилитой "puplet" (package updater), которая информирует пользователя о наличии обновления, а также позволяет установить это обновление.

Дополнительная информация: http://linux.duke.edu/projects/yum , http://www.redhat.com/magazine/024oct06/features/fc62

Благодарю ZOOL за предоставленную информацию на сайте http://www.centrlan.ru/node/17929

Источник не указан

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

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

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

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

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

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

Что такое syslog

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

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

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

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

Уровень	Описание
emerg, panic	Состояние «паники»
alert	Состояние, требующее немедленного вмешательства
crit	Критическое состояние
err, error	Прочие ошибки работы
warning, warn	Предупреждения
notice	Сообщения, не являющиеся ошибками, но на которые следует обратить внимание
info	Информационные сообщения (нормальная работа)
debug	Отладочная информация

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

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

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

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

Источник	Описание
kern	Сообщения ядра
auth, authpriv
security	Сообщения безопасности (например, от firewall )
console	Сообщения, поступающие на консоль (/dev /console )
syslog	Собственные сообщения службы syslog
cron	Сообщения подсистемы cron
	Сообщения службы времени
	Сообщения FTP- серверов
	Сообщения подсистемы печати
mail	Сообщения почтовых служб
news	Сообщения службы новостей
uucp	Сообщения UUCP
daemon	Сообщения прочих демонов, работающих в системе
user	Сообщения пользовательских процессов
local0 – local7	Могут использоваться для различных пользовательских нужд (иногда используются и системой)

При настройке какого-либо приложения для работы со службой 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

321 ?? Ss 0:01,67 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -s

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

Настройка протоколирования осуществляется в файле /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 позволит вам существенно повысить качество протоколирования, настроив запись журнальной информации строго в соответствии со своими потребностями.

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

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

В этой статье мы рассмотрим основные части системы логирования в Linux, файлы логов, а также утилиты, с помощью которых можно посмотреть логи Linux.

Большинство файлов логов Linux находятся в папке /var/log/ Вы можете список файлов логов для вашей системы с помощью команды ls:

Rw-r--r-- 1 root root 52198 май 10 11:03 alternatives.log
drwxr-x--- 2 root root 4096 ноя 14 15:07 apache2
drwxr-xr-x 2 root root 4096 апр 25 12:31 apparmor
drwx------ 2 root root 4096 май 5 10:15 audit
-rw-r--r-- 1 root root 33100 май 10 10:33 boot.log

Ниже мы рассмотрим 20 различных файлов логов Linux, размещенных в каталоге /var/log/. Некоторых из этих логов встречаются только в определенных дистрибутивах, например, dpkg.log встречается только в системах, основанных на Debian.

/var/log/messages - содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.

/var/log/dmesg - содержит сообщения, полученные от ядра. Регистрирует много сообщений еще на этапе загрузки, в них отображается информация об аппаратных устройствах, которые инициализируются в процессе загрузки. Можно сказать это еще один лог системы Linux. Количество сообщений в логе ограничено, и когда файл будет переполнен, с каждым новым сообщением старые будут перезаписаны. Вы также можете посмотреть сообщения из этого лога с помощью команды dmseg.

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

/var/log/boot.log - Содержит информацию, которая регистрируется при загрузке системы.

/var/log/daemon.log - Включает сообщения от различных фоновых демонов

/var/log/kern.log - Тоже содержит сообщения от ядра, полезны при устранении ошибок пользовательских модулей, встроенных в ядро.

/var/log/lastlog - Отображает информацию о последней сессии всех пользователей. Это нетекстовый файл, для его просмотра необходимо использовать команду lastlog.

/var/log/maillog /var/log/mail.log - журналы сервера электронной почты, запущенного в системе.

/var/log/user.log - Информация из всех журналов на уровне пользователей.

/var/log/Xorg.x.log - Лог сообщений Х сервера.

/var/log/alternatives.log - Информация о работе программы update-alternatives. Это символические ссылки на команды или библиотеки по умолчанию.

/var/log/btmp - лог файл Linux содержит информацию о неудачных попытках входа. Для просмотра файла удобно использовать команду last -f /var/log/btmp

/var/log/cups - Все сообщения, связанные с печатью и принтерами.

/var/log/anaconda.log - все сообщения, зарегистрированные при установке сохраняются в этом файле

/var/log/yum.log - регистрирует всю информацию об установке пакетов с помощью Yum.

/var/log/cron - Всякий раз когда демон Cron запускает выполнения программы, он записывает отчет и сообщения самой программы в этом файле.

/var/log/secure - содержит информацию, относящуюся к аутентификации и авторизации. Например, SSHd регистрирует здесь все, в том числе неудачные попытки входа в систему.

/var/log/wtmp или /var/log/utmp - системные логи Linux, содержат журнал входов пользователей в систему. С помощью команды wtmp вы можете узнать кто и когда вошел в систему.

/var/log/faillog - лог системы linux, содержит неудачные попытки входа в систему. Используйте команду faillog, чтобы отобразить содержимое этого файла.

/var/log/mysqld.log - файлы логов Linux от сервера баз данных MySQL.

/var/log/httpd/ или /var/log/apache2 - лог файлы linux11 веб-сервера Apache. Логи доступа находятся в файле access_log, а ошибок в error_log

/var/log/lighttpd/ - логи linux веб-сервера lighttpd

/var/log/conman/ - файлы логов клиента ConMan,

/var/log/mail/ - в этом каталоге содержатся дополнительные логи почтового сервера

/var/log/prelink/ - Программа Prelink связывает библиотеки и исполняемые файлы, чтобы ускорить процесс их загрузки. /var/log/prelink/prelink.log содержит информацию о.so файлах, которые были изменены программой.

/var/log/audit/ - Содержит информацию, созданную демоном аудита auditd.

/var/log/setroubleshoot/ - SE Linux использует демон setroubleshootd (SE Trouble Shoot Daemon) для уведомления о проблемах с безопасностью. В этом журнале находятся сообщения этой программы.

/var/log/samba/ - содержит информацию и журналы файлового сервера Samba, который используется для подключения к общим папкам Windows.

/var/log/sa/ - Содержит.cap файлы, собранные пакетом Sysstat.

/var/log/sssd/ - Используется системным демоном безопасности, который управляет удаленным доступом к каталогам и механизмами аутентификации.

Просмотр логов в Linux

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

• zgrep
• zmore

Я не буду останавливаться подробно на каждой из этих команд, поскольку большинство из них уже подробно рассмотрены на нашем сайте. Но приведу несколько примеров. Просмотр логов Linux выполняется очень просто:

Смотрим лог /var/log/messages, с возможностью прокрутки:

less /var/log/messages

Просмотр логов Linux, в реальном времени:

tail -f /var/log/messages

Открываем лог файл dmesg:

cat /var/log/dmesg

Первые строки dmesg:

head /var/log/dmesg

Выводим только ошибки из /var/log/messages:

grep -i error /var/log/messages

Кроме того, посмотреть логи на linux можно и с помощью графических утилит. Программа System Log Viewer может быть использована для удобного просмотра и отслеживания системных журналов на ноутбуке или персональном компьютере с Linux.

Вы можете установить программу в любой системе с установленным X сервером. Также для просмотра логов может использоваться любой графический тестовый редактор.

Выводы

В каталоге /var/log вы можете найти всю необходимую информацию о работе Linux. Из сегодняшней статьи вы достаточно узнали, чтобы знать где искать, и что искать. Теперь просмотр логов в Linux не вызовет у вас проблем. Если остались вопросы, задавайте в комментариях!

Демон 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 должен прослушивать
-d	Включает режим отладки. В этом режиме демон не будет использовать системный вызов fork(2) для переключения себя в фоновый режим и будет выводить больше отладочной информации
-f файл	Этот параметр определяет альтернативный файл конфигурации
-h	По умолчанию демон не перенаправляет сообщения, которые он получает от других узлов. Этот параметр позволяет перенаправить сообщения другим хостам, которые определены
-n	Этот параметр нужен, если syslogd запускается и контролируется программой init
-р сокет	Позволяет задать другой сокет Unix вместо /dev/log
-r	Позволяет принимать сообщения из сети. Данная опция появилась в версии syslogd 1.3
-v	Выводит версию демона syslogd