Демоном в 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
Источник не указан
Каждый из начинающих пользователей Linux рано или поздно встречается с какими-то проблемами в настройке и организации функционирования своей системы. И каждый из новичков почти наверняка слышал от более опытных пользователей совет: "Смотри логи". Совет-то хорош, да ведь новичку еще надо знать: что такое логи и где их искать! Вот я и попытаюсь в этой статье рассказать, что и где нужно смотреть.На программистском сленге "логами" называют протоколы работы, которые ведутся как самой операционной системой, так и самостоятельно многими программами. В качестве синонима слова "протокол" в этом смысле часто используется и слово "журнал". Существует две основных ситуации, в которых возникает необходимость анализа протокола: когда что-то в системе работает не так, как мы ожидали, (разрешение проблем), и когда появляется подозрение, что система взломана каким-то злоумышленником и надо выяснить, что именно произошло, как это было сделано, и что нужно предпринять, чтобы ликвидировать последствия вторжения.
Одним из самых известных случаев использования файлов протоколов для обнаружения вторжения злоумышленника является история поимки специалистом по компьютерной безопасности Тсуомо Шимомура знаменитого хакера Кевина Митника. Вот один абзац из статьи , описывающей, как это произошло.
"В Рождество, когда Шимомура поехал на каникулах покататься на лыжах в Неваду, кто-то (мы уже знаем, кто именно) проник в его суперзащищенный домашний компьютер в Солана Бич, Калифорния, и начал копировать его файлы - сотни засекреченных файлов. Один магистрант из Центра Суперкомпьютеров в Сан Диего, где работал Шимомура, заметил изменения в системных "журнальных" (log) файлах и быстро сообразил, что происходит. Все это оказалось возможным благодаря тому, что Шимомура установил на свой компьютер программу, автоматически копирующую "журнальные" записи на дублирующий компьютер в Сан Диего. Студент позвонил Шимомуре, и тот помчался домой, чтобы провести инвентаризацию украденного."
Я не буду рассказывать здесь всю эту историю, нам важно отметить только то, что анализ протоколов работы системы послужил основой для успеха проведенного расследования неправомерных действий. Более подробное описание того, как проводятся такие расследования, вы сможете найти в статье . Но, чтобы суметь воспользоваться результатами протоколирования, надо понимать, как создаются протоколы, где они хранятся и что из них можно извлечь. Рассмотрению всех этих вопросов и посвящена настоящая статья.
Как формируются сообщения для протокола
Начать надо с того, что при создании программ на языке С программисты имеют возможность в необходимых случаях вставить вызов специальных функций openlog, setlogmask, syslog и closelog , включенных в стандартную библиотеку языка C. Эти функции служат для посылки сообщений о тех или иных событиях при выполнении программы специальному системному демону syslogd , ведущему системный протокол. Функция openlog устанавливает связь с демоном syslogd , функция syslog формирует конкретное сообщение для записи в протокол, а функция closelog закрывает открытую связь.
Сообщения, формируемые функцией syslog , состоят из нескольких полей, разделяемых пробелами. Каждое сообщение начинается с поля PRI , которое в закодированном виде содержит информацию о категории сообщения (facility) и уровне серьезности (severity level) или приоритете (priority) сообщения.
Категория (facility) - это информация о том, к какому классу относится данное сообщение. Категория кодируется числом от 0 до 23. Существуют следующие категории (они определяются в файле /usr/include/sys/syslog.h ):
Таблица 1.
| Числовое значение | Условное обозначение | Расшифровка |
| 0 | kern | Сообщения ядра |
| 1 | user | Предназначена для разнообразных сообщений от программ пользователя.(сообщения пользовательских программ) |
| 2 | Сообщения от почтовой системы. | |
| 3 | daemon | Сообщения от тех системных демонов, которые в отличие от FTP или LPR не имеют выделенных специально для них категорий. |
| 4 | auth | Все что связано с авторизацией пользователей, вроде login и su (безопасность/права доступа) |
| 5 | syslog | Система протоколирования может протоколировать сообщения от самой себя. |
| 6 | lpr | Сообщения от системы печати. |
| 7 | news | Сообщения от сервера новостей. (Netnews, USENET) |
| 8 | uucp | Сообщения от UNIX-to-UNIX Copy Protocol. Это часть истории UNIX и вероятнее всего она вам никогда не понадобится (хотя до сих пор определенная часть почтовых сообщений доставляется через UUCP). |
| 9 | cron | Сообщения от системного планировщика. |
| 10 | authpriv | То же самое, что и auth, однако сообщения этой категории записываются в файл, который могут читать лишь некоторые пользователи (возможно, эта категория выделена потому, что принадлежащие ей сообщения могут содержать открытые пароли пользователей, которые не должны попадать на глаза посторонним людям, и следовательно файлы протоколов должны иметь соответствующие права доступа). |
| 11 | ftp | При помощи этой категории вы сможете сконфигурировать ваш FTP сервер, что бы он записывал свои действия. |
| с 12 по 15 | - | Зарезервировано для системного использования. |
| с 16 по 23 | local0 - local7 | Зарезервированные категории для использования администратором системы. Категория local7 обычно используется для сообщений, генерируемых на этапе загрузки системы. |
Категория auth имеет устаревшее наименование-синоним security , которое не рекомендуется использовать. Кроме того, существует особая категория mark (не имеющая цифрового эквивалента), которая присваивается отдельным сообщениям, формируемым самим демоном syslogd . Эта категория используется для того, что бы помещать в протокол специальные отметки через заданный интервал времени (по умолчанию каждые 20 минут), что позволяет, например, узнать с 20-ти минутной точностью, когда же завис ваш компьютер.
Отметим, что категория не имеет вообще говоря никакого отношения к имени программы, которая шлет сообщения демону syslogd . Как говорится, всякое совпадение - чистая случайность. Более того, некоторые программы могут порождать сообщения разных категорий. Например, демон telnetd в случае неудачных попыток логирования порождает сообщения категории authpriv , а в других случаях относит свои сообщения к категории daemon .
Второй параметр, на основе которого формируется значение поля PRI , - это уровень или приоритет сообщения (priority), то есть информация о степени важности сообщения. Стандартно заданы 8 уровней важности (они тоже определены в файле /usr/include/sys/syslog.h ), которые кодируются числами от 0 до 7:
Таблица 2.
| Числовое значение | Условное обозначение | Расшифровка |
| 0 | emerg (старое название PANIC) | Чрезвычайная ситуация. Система неработоспособна. |
| 1 | alert | Тревога! Требуется немедленное вмешательство. |
| 2 | crit | Критическая ошибка (критическое состояние). |
| 3 | err (старое название ERROR) | Сообщение об ошибке. |
| 4 | warning (старое название WARN) | Предупреждение. |
| 5 | notice | Информация о каком-то нормальном, но важном событии. |
| 6 | info | Информационное сообщение. |
| 7 | debug | Сообщения, формируемые в процессе отладки. |
Поле PRI сообщения образуется следующим образом: числовое значение категории умножается на 8 и складывается с числовым значением приоритета, получившееся число заключается в угловые скобки и записывается в поле.
Вслед за полем PRI в сообщение включаются следующие поля:
- TIMESTAMP - время формирования сообщения,
- HOSTNAME - имя или IP-адрес хоста в десятичной записи,
- MSG - произвольный текст сообщения - некоторая текстовая (информационная) строка в коде US-ASCII (0x20 - 0x7e).
Время (местное!) записывается в формате: Feb 13 21:12:06. Если номер дня является однозначным числом, то перед ним ставится дополнительный пробел (не 0!). Обратите внимание на отсутствие года и зоны в дате, что необходимо учесть при организации долговременного хранения файлов протокола. Для того, чтобы время в сообщении было правильным, оно должно быть синхронизовано (например, по протоколу NTP).
Имя хоста включается в сообщение с той целью, чтобы не путать сообщения от разных хостов, поскольку, как будет показано ниже, ведение протоколов может вестись на одном из выделенных компьютеров в сети. В качестве имени хоста указывается простое сетевое имя компьютера, без указания домена. Если компьютер имеет несколько интерфейсов с различными IP-адресами, то в качестве имени или адреса хоста может быть использовано любое из них.
Текст сообщения (MSG ) обычно содержит этикетку (TAG ), указывающую на программу или процесс, выдавшую это сообщение, и тело сообщения (CONTENT ). Этикетка может содержать латинские буквы и цифры. Обычно в качестве этикетки используется простое имя программы, иногда дополненное идентификатором процесса, заключенным в квадратные скобки. Тело сообщения отделяется от этикетки специальными символами - в Linux это обычно двоеточие и пробел.
Обработка сообщений демоном syslogd
Все сообщения, формируемые отдельными программами с помощью функции syslog , отправляются через сокет /dev/log системному демону syslogd , который отвечает за обработку этих сообщений. Надо сказать, что вообще-то в системе запускаются два демона протоколирования - syslogd и klogd . Оба демона входят в состав пакета sysklogd , последнюю версию которого вы можете найти на сайте .
Демон klogd отвечает за протоколирование событий, происходящих в ядре системы. Необходимость в отдельном демоне klogd объясняется тем, что ядро не может использовать стандартную функцию syslog . Дело в том, что стандартные библиотеки (включая ту библиотеку, в которой находится функция syslog ) предназначены для использования только обычными приложениями. Поскольку ядро тоже нуждается в аналогичных функциях, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро использует свой собственный механизм генерации сообщений. Демон klogd предназначен для организации обработки этих сообщений. В принципе он может производить такую обработку полностью самостоятельно и независимо от syslogd , например, записывая эти сообщения в файл, но в большинстве случаев используется принятая по умолчанию настройка klogd , при которой все сообщения от ядра пересылаются тому же демону syslogd .
Чтобы убедиться, что демоны syslogd и klogd запущены в вашей системе, выполните команду ps -ax | grep log . У меня эта команда дала следующий результат:
$ ps -ax | grep log 569 ? S 0:00 syslogd -m 0 574 ? S 0:00 klogd -x 1013 ? S 0:00 login -- kos 1191 ? S 0:00 kalarmd --login Две первые строчки как раз и сообщают, что в системе запущены демоны протоколирования.Обработка сообщений демоном syslogd состоит в том, что он постоянно отслеживает появление сообщений и сравнивает каждую пришедшую запись с правилами, которые находятся в файле /etc/syslog.conf . Каждое правило записывается в виде строки файла /etc/syslog.conf , состоящей из двух полей. Левое поле ("selector") задает один или несколько шаблонов, по которым отбираются сообщения. Шаблоны разделяются точкой с запятой (смотри приведенный ниже пример файла /etc/syslog.conf ). Правое поле ("действие") определяет порядок обработки отобранных сообщений. Поля разделены одним или несколькими пробелами или символами табуляции.
Каждый шаблон в поле "selector" имеет вид "категория.уровень" (то есть "facility.priority"). Значениями поля "категория" может служить:
- одно из перечисленных в таблице 1 условных наименований категорий,
- несколько таких наименований (в этом случае они разделяются запятыми)
- или символ * (что означает "все категории").
Значениями поля "уровень" может служить:
- одно из перечисленных в таблице 2 условных наименований уровня,
- символ * (записывать все сообщения данной категории, независимо от уровня),
- или слово none (не записывать сообщения данной категории).
Задание конкретного значения в поле "уровень" трактуется как "все значения данного уровня и выше". Если нужно записывать сообщения только одного уровня, то нужно перед задаваемым значением поставить знак равенства ("="). Если требуется записывать сообщения всех уровней, кроме указываемого, то перед наименованием уровня ставится восклицательный знак ("!"). Простановка двух этих знаков одновременно трактуется как "не записывать сообщения указанного уровня и выше".
Прописные и строчные буквы в поле "selector" не различаются. Можно также использовать числа (см. /usr/include/syslog.h). Кроме перечисленных в таблице 1 категорий можно указывать mark (регулярные временные метки) и security (устаревший синоним для auth ). Кроме перечисленных в таблице 2 значений приоритета можно использовать warn (синоним для warning ), error (синоним для err ), panic (синоним для emerg ).
Когда обнаруживается соответствие категории и уровня полученного сообщения с одним из шаблонов поля "selector" какой-то строки, syslogd обрабатывает запись в соответствии с действием, прописанным в поле "действие" данной строки.
В поле "действие" может стоять
- имя обычного файла (файла протокола), причем должен быть указан полный путь к файлу, начиная с корня "/", а если указанного файла не сущестует, syslogd создает его,
- название именованного канала (named pipe) - FIFO ; в этом случае перед именем ставится вертикальная черта ("|"), а сам канал должен быть создан перед запуском syslogd командой mkfifo ,
- указание на терминал или консоль (как на устройство: /dev/tty1),
- указание на удаленный хост (перед которым ставится символ @),
- или список пользователей (через запятую), на терминалы которых будет послано сообщение по данному правилу. Вместо списка пользователей можно поставить звездочку (*), что будет означать, что сообщения посылаются всем пользователям, работающим в данный момент в системе.
Чаще всего в поле "действие" все же стоит имя файла протокола. Причем, перед именем файла можно проставить знак минуса ("-"), что будет означать, что система может хранить файл в буфере кеша, а не сбрасывать его после записи каждого сообщения на диск. Это, конечно, ускоряет работу, особенно если в протокол записывается много больших сообщений, однако может привести к потере части сообщений при неожиданном крахе системы, то есть именно тогда, когда такие сообщения особенно нужны. В качестве устройства в поле "действие" можно указать также принтер - /dev/lp0. Такой вариант "действия" целесообразно применять в тех случаях, когда речь идет об особо важных системах. Протоколы, которые распечатаны, не могут быть стерты или изменены хакерами, так что это неплохое применение для старого матричного принтера.
Кроме строк с правилами в файле /etc/syslog.conf могут содержаться пустые строки и строки комментариев, начинающиеся символом #. Подробнее о структуре файла /etc/syslog.conf вы можете прочитать на man-страничке syslog.conf , где приведено достаточно много примеров записей правил в этом файле. Отметим, что при задании пар "категория.уровень" в файле syslog.conf нельзя использовать числовые значения, приведенные в таблицах 1 и 2, допускаются только их условные наименования.
Если сообщение соответствует шаблонам двух или более строк, оно будет обрабатываться по каждому из этих правил (т.е. обработка сообщения не прекращается при первом успехе). Это означает, что для одного сообщения может быть выполнено произвольное количество действий. Поэтому вы можете и записать сообщение в файл протокола и отправить его пользователю(лям) или на удаленный хост.
Кроме того, если в поле "selector" перечислены (через точку с запятой) несколько пар "категория.уровень", то последующие пары могут отменить действие предыдущих. Пример такой отмены вы видите в приводимом ниже листинге файла /etc/syslog.conf : в файл /var/log/messages записываются все сообщения, уровень которых равен или выше info, однако при этом пропускаются (не записываются) сообщения категорий mail, authpriv и cron.
| Листинг 1. Файл /etc/syslog.conf из системы, построенной на основе дистрибутива Red Hat Linux 7.1 (я только перевел на русский язык комментарии, содержащиеся в этом файле и выделил жирным шрифтом строки правил). |
| # Выдавать все сообщения от ядра на консоль. #kern.* /dev/console # Записывать в протокол все сообщения уровня info или выше, # кроме сообщений почтовой системы, содержащих конфиденциальную # информацию аутентификационных сообщений и сообщений демона cron. *.info;mail.none;authpriv.none;cron.none /var/log/messages # Записывать в отдельный файл сообщения, содержащие конфиденциальную # информацию аутентификации, независимо от их уровня. authpriv.* /var/log/secure # Все сообщения почтовой системы тоже записывать отдельно. mail.* /var/log/maillog # Протоколировать действия демона cron. cron.* /var/log/cron # Сообщения о чрезвычайных ситуациях должны немедленно # получить все пользователи системы *.emerg * # Сообщения от служб новостей уровня crit и выше записывать в отдельный файл. uucp,news.crit /var/log/spooler # Сообщения, выдаваемые на этапе загрузки, копировать в файл boot.log local7.* /var/log/boot.log |
Файл протокола /var/log/messages
Конечно, рассказать здесь о содержании каждой строки этого файла нет возможности. Для того, чтобы читатель мог составить представление о том, какую информацию можно найти в протоколе, приведем отдельные строки-сообщения с очень краткими комментариями.
Каждая строка в файле протокола содержит запись одного сообщения, состоящую из следующих полей сообщения, разделенных пробелами:
- дата в стандартном текстовом формате (поле TIMESTAMP из сообщения syslog ),
- имя хоста (поле HOSTNAME из сообщения syslog )
- текст сообщения (поля TAG и CONTENT из сообщения syslog )
Во-первых, стоит заметить, что если ваш компьютер не работает круглосуточно, а выключается на ночь, то в этом файле можно обнаружить записи о нескольких "рабочих циклах", начинающихся с загрузки компьютера и заканчивающихся выключением его. Начинается такой цикл с сообщения о запуске демонов протоколирования (это и понятно, до их запуска сообщения не фиксировались):
Sep 17 08:32:56 kos3 syslogd 1.4-0: restart. Сен 17 08:32:56 kos3 syslog: запуск syslogd succeeded Sep 17 08:32:56 kos3 kernel: klogd 1.4-0, log source = /proc/kmsg started. Sep 17 08:32:56 kos3 kernel: Inspecting /boot/System.map-2.4.2-2 Сен 17 08:32:56 kos3 syslog: запуск klogd succeeded
Примерно такую же структуру имеют и записи в других файлах протоколов, упоминаемых в файле /etc/syslog.conf .
Команды logger и tailf
Из предыдущего описания можно сделать вывод, что выдача всех сообщений для системных журналов должна быть заложена программистом на этапе создания программы. Это не совсем так. Пользователь тоже имеет возможность послать сообщение демону syslogd . Для этого в Linux имеется команда logger , обеспечивающая отправку сообщения из командной строки (sh, bash и др.). Она входит в состав пакета util-linux. Естественно, что в первую очередь эта команда предназначена для обеспечения возможностей протоколирования при создании пользователем разного рода скриптов оболочки. Но ее можно запустить и непосредственно из командной строки, например, для ознакомления с возможностями системы протоколирования. Формат запуска команды: logger [-isd] [-f file] [-p PRI] [-t TAG] [-u socket] Параметры командной строки имеют следующее значение:
- -i - включать в сообщение номер процесса
- -s - дублировать сообщение на stderr
- -d - использовать при отправке сообщений режим дейтаграмм (вместо обычного потокового)
- -f имя-файла - сохранять сообщение в указанном файле (по умолчанию используется /var/log/messages )
- -p facility.level - задать категорию и приоритет сообщения (по умолчанию: user.notice)
- -t TAG - задать поле TAG
- -u socket - отправлять сообщение в указанный сокет, вместо обращения к syslogd
- MSG - текст сообщения
Пошлите несколько сообщений с помощью программы logger и полюбуйтесь на результат в файле /var/log/messages (если, конечно, вы не изменили заданное по умолчанию значение).
Кстати сказать, имеется очень интересный способ просмотра сообщений,
записываемых в файл /var/log/messages
командой logger
.
Способ этот основан на использовании специальной программы tailf
.
Откройте окно терминала, получите права суперпользователя (командой su
)
и выполните в этом окне команду
tailf /var/log/messages
После этого переключитесь в другой терминал и выполните там команду
logger произвольный_текст
. Ваше сообщение тут же отобразится в том
окне, где запущена программа tailf
. То есть с помощью этой программы
администратор системы может отслеживать запись новых сообщений в протокол
в реальном режиме времени. Правда, у системного администратора вряд ли
найдется время, чтобы следить за поведением системы таким образом (разве что
в экстренных ситуациях). Поэтому для анализа протоколов разработаны специальные
программы. Но о них чуть ниже, а пока перейдем к вопросу
о том, как организовать надзор за удаленным компьютером (помните
как поймал злоумышленника Шимомура?).
Протоколирование в сети
Как было сказано, сообщения системы протоколирования могут отправляться демоном syslogd на удаленный хост. Но там его кто-то должен принять. Оказывается делает это такой же демон syslogd , запущенный на этом удаленном хосте. Точнее, syslogd на любом компьютере может прослушивать не только сокет /dev/log (принимая тем самым сообщения от местных источников), но еще и порт 514/UDP, что обеспечивает прием сообщений с других компьютеров локальной сети (и последующую запись их в локальный файл). Тем самым обеспечивается возможность создания "сервера протоколирования", что может оказаться очень удобно для системного администратора (в одном месте отслеживаются все события в сети), а также повышает безопасность сети, поскольку сообщения о проникновении хакера на один из хостов сети не могут быть тут же этим хакером удалены из протокола.
Однако, для организации такого "сетевого протоколирования" необходимо предпринять некоторые дополнительные усилия.
Во-первых, поскольку для приема и отправки сообщений по сети
используется порт 514/UDP, он должен быть доступен на обеих компьютерах
(клиенте и сервере). Для этого в файле /etc/services
на обеих
компьютерах должна присутствовать строка
syslog 514/udp
Если такая строка в /etc/services
отсутствует, syslogd
не
может ни принимать сообщения, ни отправлять их в сеть, поскольку не может
открыть UDP-порт. Если такая ситуация возникает, syslogd
немедленно
прекращает записывать какие-либо сообщения даже в локальный протокол. При
этом, как показывает команда ps
, он остается в памяти и даже
сохраняет сообщения в каких-то буферах, поскольку,
если строку "syslog 514/udp"
восстановить в файле /etc/services
на клиенте, то по крайней мере часть
"пропавших" сообщений все же появляется в протоколе (после перезапуска syslogd
).
Во-вторых, при запуске демона syslogd на сервере должна быть указана опция -r , которая обеспечивает возможность удаленного протоколирования (по умолчанию демон syslogd ждет сообщения только от локального сокета). О том, как и где задать эту опцию, будет рассказано ниже, в разделе о запуске демона syslogd .
Ну, и в-третьих, должны быть соответствующим образом
исправлены настройки в файлах /etc/syslog.conf
на обеих компьютерах.
Например, если вы хотите все сообщения перенаправить на сервер протоколирования,
необходимо на компьютере-клиенте прописать в файле /etc/syslog.conf
строку следующего вида:
*.* @hostname
Если во время старта демона syslogd
сервер окажется недоступен
(например, он в этот момент отключен от сети) или не удастся найти его по имени
(служба DNS не сработала должным образом) syslogd
осуществляет еще
10 попыток нахождения сервера и только если и после этого найти сервер не удалось,
прекращает попытки и посылает соответствующее сообщение.
Если в вашей сети имеется несколько доменов, которые обслуживаются одним сервером протоколирования, то не удивляйтесь тому, что в протоколе на сервере будут указаны полные имена клиентов (с указанием домена). Правда, при запуске syslogd можно использовать опции -s список_доменов или -l список_хостов , которые обеспечивают замену в протоколе полных имен хостов на их краткие имена (без указания домена).
Не забудьте после корректировки опций запуска и файла /etc/syslog.conf перезапустить демон, поскольку, в отличие от cron , sysklogd не перечитывает конфигурационные файлы автоматически.
Опции запуска демона syslogd
Раз уж мы коснулись в предыдущем подразделе вопроса задания параметров запуска демона syslogd , давайте рассмотрим этот вопрос подробнее. Как уже сказано, запускаются оба демона протоколирования на этапе инициализации системы, а конкретнее - посредством скрипта /etc/rc.d/init.d/syslog (для которого, как и для скриптов запуска других сервисов, создаются символьные ссылки в каталогах /etc/rc.d/rc?.d/). Однако для того, чтобы задать пераметры запуска, нет необходимости корректировать этот скрипт, потому что начиная с версии 7.2 в дистрибутиве Red Hat опции запуска обеих демонов считываются из отдельного конфигурационного файла /etc/sysconfig/syslog . Приведем краткий перечень возможных параметров для демона syslogd .Параметры запуска syslogd :
- -a socket - Задает дополнительный сокет, который будет прослушиваться демоном syslogd . Можно задать до 19 сокетов (можно и больше, но для этого надо перекомпилировать пакет). Эта опция используется в тех случаях, когда какой-то другой демон (например, ftp или http) выполняется в ограниченном окружении (делает chroot).
- -d - Отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал.
- -f имя-конфигурационного-файла Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf .
- -h По умолчанию в sysklogd запрещена передача сообщений, принятых по сети, на какой-то другой компьютер. Это сделано с той целью, чтобы не образовывались бесконечные пересылки сообщений по кольцу. Опция -h позволяет изменить обычное поведение и обеспечить передачу сообщений, принятых от удаленных хостов, далее по сети (а уж о возможном зацикливании позаботьтесь сами).
- -l список-хостов - Задает список хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN - Full Qwalified Domain Name); имена в списке разделяются двоеточием.
- -m минут Запущенный без этой опции sysklogd регулярно (через каждые 20 минут) записывает в протокол сообщения категории mark , то есть просто временные отметки. С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений, для чего надо задать нулевой интервал: -m 0 .
- -n Не уходить в фоновый режим; опция необходима в тех случаях, когда syslogd запускается и управляется процессом init .
- -p socket Задает альтернативный сокет UNIX (вместо прослушиваемого по умолчанию /dev/log ). Обратите внимание: опция -a задает дополнительные сокеты, а -p - альтернативный!
- -r Разрешить принимать сообщения от удаленных хостов. Об этом мы говорили в предыдущем разделе, поэтому подробности опускаю.
- -s список-доменов Задает список доменов, имена которых не нужно записывать в протокол вместе с именем хоста (то есть для этих доменов вместо полного доменного имени (FQDN) в протокол будут писаться только имена хостов. Имена в списке разделяются двоеточием. Имя домена, в котором расположен сервер syslogd, указывать в этом списке не требуется (его имя удаляется по умолчанию).
- -v Показать версию и закончить работу.
- -x Запретить определять имя хоста по его адресу, предотвращает deadlock при работе на одном хосте с сервером DNS.
После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid .
С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`
вы можете послать демону syslogd
один из
следующих сигналов:
- SIGHUP - перезапуск демона (реинициализация); все открытые файлы закрываются, демон стартует заново, перечитывая при этом свой конфигурационный файл.
- SIGTERM - завершение работы.
- SIGINT, SIGQUIT - если включен режим отладки (опция -d), сигналы игнорируются, в противном случае - завершение работы.
- SIGUSR1 - включить/выключить режим отладки (работает только в том случае, если демон был запущен с ключом -d).
Демон klogd имеет не меньше опций запуска, чем syslogd , однако приводить их здесь не будем, отсылая читателя к соответствующей man-страничке (пользователю не стоит заниматься настройкой klogd , лучше оставить ее в том состоянии, как она произведена разработчиками дистрибутива).
Файл dmesg и команда dmesg
Как уже говорилось, файлы протоколов, упоминаемые в файле /etc/syslog.conf обычно располагаются в каталоге /var/log и его подкаталогах. Но, если заглянуть в этот каталог, то мы обнаружим там несколько файлов, которые в /etc/syslog.conf не упоминались. Давайте рассмотрим их назначение. И начнем, пожалуй, с файла dmesg .Сначала необходимо упомянуть, что в Linux имеется команда с таким же названием. Если сравнить вывод этой команды (когда она запущена без параметров) с содержимым файла /var/log/dmesg , то обнаружится что они очень похожи, хотя и не идентичны (направьте вывод команды в файл dmesg2 и сравните файлы dmesg и dmesg2 ). Точнее, файл /var/log/dmesg один в один совпадает с началом того вывода, который мы получим по команде dmesg . Как следует из , в ядре имеется кольцевой буфер, в который записываются сообщения демона протоколирования ядра. Те сообщения, которые записываются в этот буфер в процессе загрузки, и составляют содержание файла /var/log/dmesg . По-видимому, этот файл формируется по окончанию загрузки системы.
Если вы снова посмотрите на приведенный листинг файла /etc/syslog.conf , то увидите, что все сообщения категории kern выдаются также и на консоль. Но там они быстро пробегают по экрану и вы вряд ли успеваете их прочитать и осмыслить. Зато они сохранены в файле /var/log/dmesg и тем самым доступны для неторопливого осмысления (если процесс загрузки успешно завершился). После окончания процесса загрузки запись сообщений от ядра в кольцевой буфер продолжается. Когда выполняется команда dmesg , выдается текущее состояние буфера. Поэтому вывод этой команды содержит больше сообщений, чем файл /var/log/dmesg : в выводе этой команды вы видите и те сообщения, которые ядро выдает после окончания процесса загрузки.
Все сообщения из /var/log/dmesg вы обнаружите и в файле /var/log/messages , только там они чередуются с сообщениями от других программ. Имеется только одно существенное различие: в файле dmesg время и источник сообщения (имя хоста и категория сообщения) не указываются. Хост тут всегда "местный", а начало отсчета времени определяется последней перезагрузкой компьютера.
Файлы lastlog, wtmp и utmp
Кроме файла dmesg в каталоге /var/log/ есть еще два файла, не упоминавшихся в /etc/syslog.conf , но имеющих непосредственное отношение к протоколированию - это файлы lastlog и wtmp . Но заглядывать в них так же, как мы просматривали файл /var/log/messages не имеет смысла - вы ничего не поймете. Дело в том, что информация в эти файлы записывается в особом формате, и просматривать ее надо с помощью специальных программных средств. Но сначала надо сказать несколько слов о назначении этих файлов.
Файл lastlog хранит информацию о последнем входе пользователя в систему. Не знаю, обращали ли вы внимание на то, что когда вы вводите имя и пароль пользователя, на экране появляется примерно следующее ссобщение:
Localhost login: kos Password: Last login: Wed Oct 9 19:25:53 on tty1 Эти три строки формируются утилитой login , которая после определения того, что пользователь имеет право входа в систему, обращается к файлу /var/log/lastlog , извлекает оттуда информацию о предыдущем успешном входе пользователя, выдает ее на экран, а затем обновляет запись в файле lastlog . Можно отменить вывод этого сообщения, создав пустой файл.hushlogin в своем домашнем каталоге. Однако делать этого не рекомендуется, скорее наоборот, стоит обращать особое внимание на содержание этого сообщения, чтобы не пропустить случаев, когда кто-то другой входил в систему под вашим именем.
В отличие от файла /var/log/lastlog , который содержит записи о времени последнего входа в систему каждого пользователя, в файле /var/log/wtmp запоминаются все входы и выходы пользователей в систему с момента создания этого файла. Как и в файле lastlog , записи в /var/log/wtmp делаются в специальном формате, так что просматривать их можно только с помощью специальных команд. Но, прежде чем рассказывать об этих командах, скажем, что существует еще один файл, содержащий записи о логировании пользователей - это файл /var/run/utmp . Этот файл содержит информацию о том, кто из пользователей работает в системе в данный момент.
Вот теперь можно рассказать о том, как просматривать информацию о работающих или ранее работавших в системе пользователях. Основной командой для этого является команда last . Она выводит все записи из файла /var/log/wtmp , причем указывается имя пользователя, указание на терминал, с которого работал пользователь, время входа пользователя в систему и время выхода его из системы, а также продолжительность сеанса работы пользователя в системе. В случае, если работа пользователя прервалась только из-за отключения самой системы, вместо времени выхода пользователя стоит слово "down" (по этим строкам легко определить время остановки системы). Время повторного запуска отображается отдельными строками, начинающимися словом "reboot".
Команда lastb подобна команде last , но выводит информацию о неудачных попытках входа пользователей в систему. Однако, надо отметить, что эта команда будет работать только в том случае, если существует файл /var/log/btmp . Впрочем, ни одна из рассматриваемых здесь программ не создает файлов регистрации, поэтому если какой-то из них удален, то ведение записей заканчивается.
Команда lastlog форматирует и выводит содержание файла /var/log/lastlog . Будут выведены поля имя пользователя, имя терминала, с которого вошел пользователь и время последнего входа в систему. По умолчанию (когда команда введена без параметров) элементы файла /var/log/lastlog будут выводиться в порядке номеров идентификаторов пользователей. Если указать параметр -u login-name, будет выведена только информация о времени последнего входа указанного пользователя. Указав параметр -t days, Вы получите только записи за последние days дней. Если пользователь вообще пока не заходил в систему, то вместо имени терминала и времени последнего входа будет указана строка "**Never logged in**".
При выполнении команды lastlog на медленном компьютере в некоторых случаях может возникнуть впечатление, что команда "зависла". Это происходит в силу того, даже если в системе зарегистрировано всего два пользователя (root и user), в файле /var/log/lastlog все равно отведено место для максимально возможного числа пользователей, которые могут работать в системе. Поэтому в файле /var/log/lastlog могут иметься большие промежутки между номерами идентификаторов работавших в системе пользователей. Поскольку при просмотре таких интервалов программа не выводит информацию на экран, и возникает впечатление "зависания".
Для вывода информации о том, кто работает в текущий момент в системе, используются команды w , who и users . Команда users используется тогда, когда вы хотите только знать, кто из пользователей работает в данный момент в системе, но не интересуетесь тем, с какого терминала он подключился и что делает. Если вы хотите знать, кто с какого терминала вошел в систему, используйте команду who . Эта команда выводит информацию из файла /var/run/utmp . Можно заставить ее выводить данные из файла /var/log/wtmp (или любого другого файла, для которого это имеет смысл), если указать имя этого файла в командной строке. Но в выводе вы все равно увидите только имя пользователя, указание на терминал, с которого вошел пользователь, время входа и, в случае входа с удаленного компьютера, имя этого компьютера.
Существенно больше информации выводит команда w . В ее выводе вы увидите текущее время, как долго система уже работает, сколько пользователей в данное время работает в системе и средняя загузка системы за последнюю минуту, 5 и 15 минут. Затем для каждого пользователя выводится:
Как уже говорилось, команда w выводит информацию, сохраненную в файле utmp . Между прочим, руководство man утверждает, что простые пользователи должны быть лишены права записи в файл utmp , так как многие системные программы (по каким-то необъяснимым причинам) зависят от его целостности. Вы рискуете спутать системные файлы статистики и внести изменения в системные файлы, если Вы предоставите любому пользователю возможность производить записи в файл utmp .
Файлы протоколов других программ
Кроме тех файлов, о которых мы уже рассказали, существуют и другие файлы протоколов, которые создаются отдельными программами. Наиболее характерными примерами могут служить протоколы работы демонов samba , ftpd или httpd , которые ведутся в отдельных файлах. Некоторые из этих программ создают свои протоколы в подкаталогах каталога /var/log/ , другие сохраняют протоколы в других местах. И структура этих файлов может существенно отличаться от структуры файлов, создаваемых системой syslog . Приведу для примера несколько строк из протокола сервера Apache , запущенного на моем компьютере: 192.168.36.21 - - "GET /ve/papers/new/log/ HTTP/1.1" 200 1774 "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /icons/back.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /icons/folder.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /icons/text.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /ve/papers/new/log/protok_lovim.htm HTTP/1.1" 200 46597 "http://linux/ve/papers/new/log/" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /bugtraq.css HTTP/1.1" 404 279 "http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /img/bug1.gif HTTP/1.1" 404 280 "http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /img/title.gif HTTP/1.1" 404 281 "http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" Как видите, структура этого файла протокола существенно отличается от того, что мы видели в системных протоколах.Samba-сервер, кроме основного протокола работы сервера, создает в подкаталоге /var/log/samba целый ряд файлов протоколов на разные случаи, в частности отдельные файлы для каждого из пользователей, которым разрешено использовать ресурсы, предоставляемые этим сервером. Из одного такого файла и взяты следующие две записи:
Smbd/service.c:make_connection(550) linux (192.168.36.10) connect to service public as user kos (uid=500, gid=500) (pid 1366) smbd/service.c:close_cnum(550) linux (192.168.36.10) closed connection to service public Приведенные примеры показывают, что если немного уметь читать по-английски и иметь некоторое представление о структуре записей, из файлов протоколов можно извлечь массу полезной информации. Только извлекать ее приходится из целых залежей "пустой породы" - огромных последовательных файлов протоколов, что представляет собой нетривиальную задачу. Поэтому были разработаны специальные программные средства для анализа протоколов.
Средства для обработки протоколов
Различных программ и скриптов для анализа протоколов разработано достаточно много. Я ограничусь краткой характеристикой двух таких средств: logwatch и swatch .
logwatch - это скрипт на языке Perl, входящий в стандартный дистрибутив Red Hat Linux. Как раз во время подготовки настоящей статьи на сайте разработчика (а им является Кирк Бауер) была выложена версия 4.1 этой программы .
Основная идея, заложенная в эту программу, заключается в том, что файл протокола пропускается через фильтр, который выделяет из протокола все строки (то есть сообщения), удовлетворяющие заданному критерию. Результаты отправляются по электронной почте указанному пользователю (по умолчанию - root-у). Фильтры могут быть написаны на любом языке программирования, но автор пакета предпочитает Perl. Фильтры должны быть написаны так, что читают данные с stdin и выводят результат на stdout.
Основной способ использования logwatch состоит во включении ссылки на основной скрипт (/etc/log.d/scripts/logwatch.pl ) в директорию /etc/cron.daily, что вызывает ежедневное выполнение logwatch с параметрами по умолчанию. Ссылке дают имя, которое начинается с "00" (например, 00-logwatch), чтобы скрипт запускался до logrotate.
Но можно запустить скрипт и из командной строки. Конечно, если вы не меняли параметр вывода информации, то результат его работы надо искать в почтовом ящике суперпользователя. Если же вы хотите видеть эти результаты на экране, то необходимо задать в командной строке параметр --print - выдавать отчет на stdout.
Общий формат запуска скрипта:
/etc/log.d/scripts/logwatch.pl [--detail уровень] [--logfile группа-журналов] [--service имя-сервиса] [--print] [--mailto адрес] [--save имя-файла] [--archives] [--range интервал-дат]
Параметры по умолчанию хранятся в файле /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 или имя группы журналов (можно указывать несколько групп).
Более подробную информацию о скрипте logwatch вы найдете в .
В статье описан другой скрипт для обработки файлов протоколов, который входит в состав дистрибутива Mandrake Linux. Скрипт этот называется swatch ("Simple WATCHer") и тоже написан на Perl.
Управление работой swatch осуществляется с помощью единственного конфигурационного файла, по умолчанию $HOME/.swatchrc . Этот файл содержит образцы текста (в форме регулярных выражений), которые swatch будет искать в файлах протоколов. Вслед за каждым таким образцом указывается действие, которое swatch должен предпринять в том случае, если он обнаружит текст, соответствующий шаблону.
Например, вы хотите получать предупреждение при каждой попытке атаки на ваш web-сервер методом переполнения буфера при запросе очень длинного имени файла (buffer-overflow attack). И вы знаете, что в таких случаях в файле протокола /var/apache/error.log появляется сообщение, содержащее слова "File name too long". В таком случае в ваш файл .swatchrc необходимо вставить следующее указание:
Watchfor /File name too long/ mail [email protected], subject=BufferOverflow_attempt
Я не буду приводить здесь более подробное описаие программы swatch . Ей посвящена восторженная статья , а саму программу можно найти на сайте . Хочется только отметить, и swatch , и logwatch реализуют довольно примитивный алгоритм обработки файлов протоколов, сводящийся к поиску в протоколе заданной строки символов (сигнатуры). Между тем, во-первых, наличие такой строки зачастую еще не свидетельствует о вторжении злоумышленника, а, во-вторых, грамотный злоумышленник может позаботиться о том, чтобы стереть следы свой деятельности . Еще один очевидный недостаток рассмотренных продуктов заключается в том, что они работают в "отложенном режиме", поскольку запускаются только по расписанию. А борьбу со злоумышленниками надо вести "в режиме реального времени", немедленно реагируя на попытки проникновения в систему. Поэтому в коммерческих продуктах предлагаются системы мониторинга, работающие постоянно, и реализующие "интеллектуальные" алгоритмы анализа протоколов. Эти алгоритмы основываются на статистическом анализе потока сообщений и выявлении статистически значимых отклонений системы от ее нормального поведения.
В заключение этого раздела отмечу, что на сайте SecurityLab.ru (http://www.securitylab.ru/tools/?ID=22111) приведен список ссылок на сайты различных программных средств для обработки протоколов с краткой характеристикой этих средств. Вы можете поэкспериментировать с различными программами и выбрать ту, которая вас устроит.
Ротация файлов протокола
Вы, конечно, понимаете, что если система интенсивно используется, то файлы протоколов быстро растут. Что влечет пустую трату дискового пространства. И возникает проблема "укрощения" протоколов. В Red Hat Linux эта проблема решается скриптои logrotate , который расположен в каталоге /etc/cron.daily , а, следовательно, запускается демоном cron ежедневно. Этот скрипт позволяет обрабатывать не только журналы системы syslog , но и любых других программ.Скрипт logrotate следит за ростом файлов протоколов и обеспечивает так называемую ротацию этих файлов в случае, если они превысили указанный размер (или по истечению указанного временного интервала). Ротация есть не что иное, как последовательное копирование предыдущих версий архивных файлов примерно следующим образом:
и создание нового файла messages для записи последующих сообщений.
Перечень файлов для обработки скриптом logrotate и параметры этой обработки определяются конфигурационными файлами, которых может быть несколько. Имена конфигурационных файлов задаются в командной строке запуска скрипта (о параметрах запуска см. ниже). В Red Hat Linux по умолчанию в качестве конфигурационных файлов для logrotate используется файл /etc/logrotate.conf , который может иметь примерно такой вид:
Weekly rotate 4 create compress include /etc/logrotate.d /var/log/wtmp /var/log/lastlog { monthly create 0664 root utmp rotate 1 }
Этот файл как и любой конфигурационный файл для скрипта logrotate состоит из нескольких секций. Первая секция определяет глобальные параметры (по одному на строке), задающие параметры по умолчанию для всех журналов. Следующие секции определяют локальные параметры для серии файлов протоколов. Имена этих файлов перечисляются в первой строке секции, а затем в фигурных скобках задаются локальные параметры, действующие только при обработке указанных файлов (тоже по одному параметру в строке). Имена файлов протоколов могут быть заключены в кавычки по правилам shell, если они содержат пробелы и другие специальные символы. Можно указывать несколько имен файлов или шаблонов имен файлов через пробел (шаблоны также по правилам shell). Обработка каждой секции рассматривается как единое действие. Строки, начинающиеся с символа "#" являются комментраиями. Локальные параметры имеют приоритет над глобальными.
В приведенном примере конфигурационного файла сначала описываются глобальные параметры, а затем в отдельной секции - параметры обработки файлов /var/log/wtmp и /var/log/lastlog. Кроме того, среди глобальных параметров дается ссылка на директорию /etc/logrotate.d , в которую каждый пакет записывает локальные параметры для своих журналов.
В секции глобальных параметров в первую очередь задается один из следующих параметров, определяющих критерий ротации файлов:
и параметр include , после которого может быть указано имя другого (дополнительного) конфигурационого файла или даже имя директории. В последнем случае все файлы в указанной директории, кроме подкаталогов, специальных файлов и файлов с суффиксами из списка исключений считаются конфигурационными файлами для скрипта logrotate (директиву include нельзя использовать внутри секции, задающей параметры обработки для группы файлов).
Параметр rotate число может находиться как среди глобальных, так и среди локальных параметров и определяет сколько старых версий надо хранить; если число равно 0, то архивные версии протокола не создаются.
Если задан параметр compress , то старые версии сжимаются с помощью gzip, а если указано nocompress - то не сжимаются. Параметр compresscmd позволяет указать, какая программа сжатия будет использоваться (по умолчанию - gzip), а uncompresscmd задает программу разжатия (по умолчанию - ungzip). compressoptions задает параметры программы сжатия; по умолчанию - "-9", т.е. максимальное сжатие для gzip. С помощью параметра compressext можно изменить суффикс для сжатых файлов, а параметр extension суффикс задает суффикс, добавляемый к именам файлов при ротации (перед суффиксом сжатия).
Среди ключевых слов, встречающихся в конфигурационных файлах, надо особо отметить слова postrotate и prerotate , которые служат открывающими скобками для включения в конфигурационные файлы скриптов оболочки shell. Все строки конфигурационного файла от строки postrotate до строки endscript исполняются как команды shell после процесса смены версии файла протокола. Соответственно, все строки от строки prerotate до строки endscript исполняются до выполнения ротации файлов протокола. С помощью этих скриптов можно организовать различные процедуры обработки файлов протоколов в процессе ротации.
С помощью других параметров конфигурационого файла можно переопределить права доступа к файлам протоколов (если этот параметр не задан, то используются аттрибуты старого файла протокола); указать, кому посылать сообщения об ошибках функционирования системы протоколирования; послать архивную копию журнала указанному пользователю; задать каталог, в который будут перемещаться протоколы во время смены версий (каталог должен находиться на том же физическом устройстве, что и /var/log) или задать список суффиксов-исключений для директории include . Подробное описание этих возможностей и параметров (а также тех, которые не были упомянуты) вы найдете по команде man logrotate .
Как уже было сказано, дополнительные конфигурационные файлы logrotate могут быть заданы в командной строке запуска скрипта. Можно указать произвольное число имен конфигурационных файлов или каталогов. Имена файлов и каталогов в этом списке разделяются просто пробелами. Порядок перечисления имен в списке имеет значение, поскольку параметры, указанные в следующем конфигурационном файле, перекрывают значение параметров, указанных в предыдущем файле. Порядок файлов в конфигурационной директории не определен.
Кроме того, в командной строке запуска можно указать следующие параметры:
- -d - отладочный режим, реальных изменений не производится,
- -f - производить изменения, даже если logrotate не видит необходимости - используется при изменениях в списке обрабатываемых журналов,
- man logwatch
- Mick Bauer, "Paranoid Penguin: swatch: Automated Log Monitoring for the Vigilant but Lazy"
- RFC 3164. C. Lonvick, The BSD Syslog Protocol, August 2001.
- RFC 3195. D. New, M. Rose, Reliable Delivery for syslog, November 2001.
- Пер. С.Лапшанский, "Демон следит за системой"
- Денис Колисниченко,
Действиями демона syslogd управляет файл конфигурации /etc/syslog.conf. Это простой текстовый файл, в котором пустые строки и строки со знаком # в первой позиции игнорируются. Формат файла следующий:
<селектор> <действие>.
Например,
mail.err /var/log/mail.errors
Эта строка обеспечит запись всех ошибок, связанных с доставкой почты в файл /var/log/mail.errors.
Важно:
В качестве разделителя между селектором
и действием используйте только клавишу
Как вы уже заметили, селектор записывается в составном виде. В общем виде это выглядит, как средство.уровень
К тому же в поле <селектор> может содержаться один или несколько селекторов, разделенных точкой с запятой. Селектор может содержать группу средств, разделенных запятыми. Селектор может содержать символы * и none, которые означают соответственно "все" и "ничего".
Примеры селекторов:
средство.уровень действие
средство1,средство2.уровень действие
средство1.уровень1;средство2.уровень2 действие
*.уровень действие
*.уровень;средство.none действие
Ниже в таблицах перечислены основные имена средств и уровней серьезности системы syslog.
Средство Программы, использующие его
kern Ядро системы
user Пользовательские процессы
mail Система электронной почты
daemon Системные демоны
auth Системы защиты и полномочий
lpr Система печати
news Система телеконференций
cron Демон cron
local0-7 Восемь уровней локального сообщения
syslog Внутренние сообщения системы syslog
ftp Демон ftpd
* Все вышеперечисленные средства
Уровень Значение уровня
emerg Экстренные ситуации
alert Срочные ситуации
crit Критические состояния
err Состояния ошибок
warning Предупреждения
notice Необычные состояния
Info Информационные сообщения
debug Отладочная информация
Уровни перечислены в порядке убывания. Это значит, что уровни обозначают минимальную важность, которую должно иметь сообщение, чтобы быть зарегистрированным в системе syslog.
Поле <действие> указывает, что нужно делать с поступившим сообщением.
Действие Описание
имя_файла Записать сообщение в файл на локальной машине
@имя_машины Переслать сообщение демону syslogd на указанную машину
@IP_адрес То же, только указан IP-адрем машины
пользователь1, Вывести сообщение на экраны указанных пользователей ...
пользовательN
* Вывести сообщение на экраны всех пользователей
*.emerg /dev/console
*.err;auth.notice /dev/console
*.err;auth,mail,user.info /var/log/messages
mail.err /var/log/mail.log
mail.info @192.168.0.1
Говоря о системе syslog, нужно упомянуть о команде logger, которая позволяет вносить записи в системный журнал из shell-сценариев.
Эту команду удобно использовать для проверки изменений, внесенных в файл /etc/syslog.conf.
local5.warning /var/log/local.log
и хотите проверить, работает ли она, то введите команду
# logger -p local5.warning "Local test"
Посмотрите файл /var/log/local.log. Если строчки "Local test" в нем нет, значит вы скорее всего забыли послать демону syslogd сигнал HUP.
СЕРГЕЙ СУПРУНОВ
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- серверов |
|
|
Сообщения подсистемы печати |
|
|
|
Сообщения почтовых служб |
|
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, который никогда не читал лог файлы. Операционная система и работающие приложения постоянно создают различные типы сообщений, которые регистрируются в различных файлах журналов. Умение определить нужный файл журнала и что искать в нем поможет существенно сэкономить время и быстрее устранить ошибку.
Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.
Основные лог файлы
Все файлы журналов, можно отнести к одной из следующих категорий:
- приложения;
- события;
- службы;
- системный.
Большинство же лог файлов содержится в директории /var/log .
- /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
- /var/log/auth.log или /var/log/secure - информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
- /var/log/dmesg - драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.
- /var/log/alternatives.log - Вывод программы update-alternatives , в котором находятся символические ссылки на команды или библиотеки по умолчанию.
- /var/log/anaconda.log - Записи, зарегистрированные во время установки системы.
- /var/log/audit - Записи, созданные службой аудита auditd .
- /var/log/boot.log - Информация, которая пишется при загрузке операционной системы.
- /var/log/cron - Отчет службы crond об исполняемых командах и сообщения от самих команд.
- /var/log/cups - Все, что связано с печатью и принтерами.
- /var/log/faillog - Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog .
- var/log/kern.log - Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
- /var/log/maillog/ или /var/log/mail.log - Журнал почтового сервера, используемого на ОС.
- /var/log/pm-powersave.log - Сообщения службы экономии заряда батареи.
- /var/log/samba/ - Логи файлового сервера Samba , который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
- /var/log/spooler - Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
- /var/log/Xorg.0.log - Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.
Для каждого дистрибутива будет отдельный журнал менеджера пакетов.
- /var/log/yum.log - Для программ установленных с помощью Yum в RedHat Linux.
- /var/log/emerge.log - Для ebuild -ов установленных из Portage с помощью emerge в Gentoo Linux.
- /var/log/dpkg.log - Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.
И немного бинарных журналов учета пользовательских сессий.
- /var/log/lastlog - Последняя сессия пользователей. Прочитать можно командой last .
- /var/log/tallylog - Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2 .
- /var/log/btmp - Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
- /var/log/utmp - Список входов пользователей в систему на данный момент.
- /var/log/wtmp - Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump .
И другие журналы
Так как операционная система, даже такая замечательная как Linux, сама по себе никакой ощутимой пользы не несет в себе, то скорее всего на сервере или рабочей станции будет крутится база данных, веб сервер, разнообразные приложения. Каждое приложения или служба может иметь свой собственный файл или каталог журналов событий и ошибок. Всех их естественно невозможно перечислить, лишь некоторые.
- /var/log/mysql/ - Лог базы данных MySQL.
- /var/log/httpd/ или /var/log/apache2/ - Лог веб сервера Apache, журнал доступа находится в access_log , а ошибки - в error_log .
- /var/log/lighthttpd/ - Лог веб сервера lighttpd.
В домашнем каталоге пользователя могут находится журналы графических приложений, DE.
- ~/.xsession-errors - Вывод stderr графических приложений X11.
- ~/.xfce4-session.verbose-log - Сообщения рабочего стола XFCE4.
Чем просматривать - lnav
Почти все знают об утилите less и команде tail -f . Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file> .
Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту - lnav , в расшифровке Log File Navigator.
Установка пакета как обычно одной командой.
$ aptitude install lnav #Debian/Ubuntu/LinuxMint $ yum install lnav #RedHat/CentOS $ dnf install lnav #Fedora $ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords $ yaourt -S lnav #Arch
Навигатор журналов lnav понимает ряд форматов файлов.
- Access_log веб сервера.
- CUPS page_log
- Syslog
- dpkg.log
- strace
- Произвольные записи с временными отметками
- gzip, bzip
- Журнал VMWare ESXi/vCenter
Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.
(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log
Программа умеет напрямую открывать архивный файл.
(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz
Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу . Это с моего syslog-а.
Mon May 02 20:25:00 123 normal 3 errors 0 warnings 0 marks Mon May 02 22:40:00 2 normal 0 errors 0 warnings 0 marks Mon May 02 23:25:00 10 normal 0 errors 0 warnings 0 marks Tue May 03 07:25:00 96 normal 3 errors 0 warnings 0 marks Tue May 03 23:50:00 10 normal 0 errors 0 warnings 0 marks Wed May 04 07:40:00 96 normal 3 errors 0 warnings 0 marks Wed May 04 08:30:00 2 normal 0 errors 0 warnings 0 marks Wed May 04 10:40:00 10 normal 0 errors 0 warnings 0 marks Wed May 04 11:50:00 126 normal 2 errors 1 warnings 0 marks
Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.
Селфи палки — что это и какие они бывают Лучшие приложения для селфи
Получение Root LG L70 (D325)
Как найти ролик на ютубе, если не знаешь названия
Почему упал ФПС в World of Tanks
Читы на слитки в скайриме - как получить слитки в игре