Жаропонижающие средства для детей назначаются педиатром. Но бывают ситуации неотложной помощи при лихорадке, когда ребенку нужно дать лекарство немедленно. Тогда родители берут на себя ответственность и применяют жаропонижающие препараты. Что разрешено давать детям грудного возраста? Чем можно сбить температуру у детей постарше? Какие лекарства самые безопасные?
Системные администраторы, да и обычные пользователи Linux, часто должны смотреть лог файлы для устранения неполадок. На самом деле, это первое, что должен сделать любой сисадмин при возникновении любой ошибки в системе.
Сама операционная система Linux и работающие приложения генерируют различные типы сообщений, которые регистрируются в различных файлах журналов. В Linux используются специальное программное обеспечение, файлы и директории для хранения лог файлов. Знание в каких файлах находятся логи каких программ поможет вам сэкономить время и быстрее решить проблему.
В этой статье мы рассмотрим основные части системы логирования в Linux, файлы логов, а также утилиты, с помощью которых можно посмотреть логи Linux.
Большинство файлов логов Linux находятся в папке /var/log/ Вы можете список файлов логов для вашей системы с помощью команды ls:
Rw-r--r-- 1 root root 52198 май 10 11:03 alternatives.log
drwxr-x--- 2 root root 4096 ноя 14 15:07 apache2
drwxr-xr-x 2 root root 4096 апр 25 12:31 apparmor
drwx------ 2 root root 4096 май 5 10:15 audit
-rw-r--r-- 1 root root 33100 май 10 10:33 boot.log
Ниже мы рассмотрим 20 различных файлов логов Linux, размещенных в каталоге /var/log/. Некоторых из этих логов встречаются только в определенных дистрибутивах, например, dpkg.log встречается только в системах, основанных на Debian.
/var/log/messages - содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.
/var/log/dmesg - содержит сообщения, полученные от ядра. Регистрирует много сообщений еще на этапе загрузки, в них отображается информация об аппаратных устройствах, которые инициализируются в процессе загрузки. Можно сказать это еще один лог системы Linux. Количество сообщений в логе ограничено, и когда файл будет переполнен, с каждым новым сообщением старые будут перезаписаны. Вы также можете посмотреть сообщения из этого лога с помощью команды dmseg.
/var/log/auth.log - содержит информацию об авторизации пользователей в системе, включая пользовательские логины и механизмы аутентификации, которые были использованы.
/var/log/boot.log - Содержит информацию, которая регистрируется при загрузке системы.
/var/log/daemon.log - Включает сообщения от различных фоновых демонов
/var/log/kern.log - Тоже содержит сообщения от ядра, полезны при устранении ошибок пользовательских модулей, встроенных в ядро.
/var/log/lastlog - Отображает информацию о последней сессии всех пользователей. Это нетекстовый файл, для его просмотра необходимо использовать команду lastlog.
/var/log/maillog /var/log/mail.log - журналы сервера электронной почты, запущенного в системе.
/var/log/user.log - Информация из всех журналов на уровне пользователей.
/var/log/Xorg.x.log - Лог сообщений Х сервера.
/var/log/alternatives.log - Информация о работе программы update-alternatives. Это символические ссылки на команды или библиотеки по умолчанию.
/var/log/btmp - лог файл Linux содержит информацию о неудачных попытках входа. Для просмотра файла удобно использовать команду last -f /var/log/btmp
/var/log/cups - Все сообщения, связанные с печатью и принтерами.
/var/log/anaconda.log - все сообщения, зарегистрированные при установке сохраняются в этом файле
/var/log/yum.log - регистрирует всю информацию об установке пакетов с помощью Yum.
/var/log/cron - Всякий раз когда демон Cron запускает выполнения программы, он записывает отчет и сообщения самой программы в этом файле.
/var/log/secure - содержит информацию, относящуюся к аутентификации и авторизации. Например, SSHd регистрирует здесь все, в том числе неудачные попытки входа в систему.
/var/log/wtmp или /var/log/utmp - системные логи Linux, содержат журнал входов пользователей в систему. С помощью команды wtmp вы можете узнать кто и когда вошел в систему.
/var/log/faillog - лог системы linux, содержит неудачные попытки входа в систему. Используйте команду faillog, чтобы отобразить содержимое этого файла.
/var/log/mysqld.log - файлы логов Linux от сервера баз данных MySQL.
/var/log/httpd/ или /var/log/apache2 - лог файлы linux11 веб-сервера Apache. Логи доступа находятся в файле access_log, а ошибок в error_log
/var/log/lighttpd/ - логи linux веб-сервера lighttpd
/var/log/conman/ - файлы логов клиента ConMan,
/var/log/mail/ - в этом каталоге содержатся дополнительные логи почтового сервера
/var/log/prelink/ - Программа Prelink связывает библиотеки и исполняемые файлы, чтобы ускорить процесс их загрузки. /var/log/prelink/prelink.log содержит информацию о.so файлах, которые были изменены программой.
/var/log/audit/ - Содержит информацию, созданную демоном аудита auditd.
/var/log/setroubleshoot/ - SE Linux использует демон setroubleshootd (SE Trouble Shoot Daemon) для уведомления о проблемах с безопасностью. В этом журнале находятся сообщения этой программы.
/var/log/samba/ - содержит информацию и журналы файлового сервера Samba, который используется для подключения к общим папкам Windows.
/var/log/sa/ - Содержит.cap файлы, собранные пакетом Sysstat.
/var/log/sssd/ - Используется системным демоном безопасности, который управляет удаленным доступом к каталогам и механизмами аутентификации.
Просмотр логов в Linux
Чтобы посмотреть логи на Linux удобно использовать несколько утилит командной строки Linux. Это может быть любой текстовый редактор, или специальная утилита. Скорее всего, вам понадобятся права суперпользователя для того чтобы посмотреть логи в Linux. Вот команды, которые чаще всего используются для этих целей:
- zgrep
- zmore
Я не буду останавливаться подробно на каждой из этих команд, поскольку большинство из них уже подробно рассмотрены на нашем сайте. Но приведу несколько примеров. Просмотр логов Linux выполняется очень просто:
Смотрим лог /var/log/messages, с возможностью прокрутки:
less /var/log/messages
Просмотр логов Linux, в реальном времени:
tail -f /var/log/messages
Открываем лог файл dmesg:
cat /var/log/dmesg
Первые строки dmesg:
head /var/log/dmesg
Выводим только ошибки из /var/log/messages:
grep -i error /var/log/messages
Кроме того, посмотреть логи на linux можно и с помощью графических утилит. Программа System Log Viewer может быть использована для удобного просмотра и отслеживания системных журналов на ноутбуке или персональном компьютере с Linux.
Вы можете установить программу в любой системе с установленным X сервером. Также для просмотра логов может использоваться любой графический тестовый редактор.
Выводы
В каталоге /var/log вы можете найти всю необходимую информацию о работе Linux. Из сегодняшней статьи вы достаточно узнали, чтобы знать где искать, и что искать. Теперь просмотр логов в Linux не вызовет у вас проблем. Если остались вопросы, задавайте в комментариях!
Список распространенных UNIX/LINUX демонов, в ОС Windows называются службами, которые могут использоваться в разных UNIX/LINUX модификациях. Имена UNIX/LINUX демонов в окончании часто содержат букву d как сокращение от англ. daemon. Проверить запущен ли процесс/демон можно командой top или ps aux .
Ниже представлен список имён самых распространенных демонов и их краткое описание. Приведённый ниже список UNIX/LINUX демонов не является полным/исчерпывающим и в вашей UNIX/LINUX системе один, все или несколько из них могут быть в наличии или же отсутствовать в зависимости от версии/типа/модификации/конфигурации вашей UNIX/LINUX системы и установленного на ней ПО.
| Процесс/Демон | Описание процесса/демона |
| auditd | auditd - это компонент аудита Linux систем. Ведёт протокол аудита на диске, который можно просмотреть с помощью комманд ausearch и aureport. Команда auditctl даёт возможность настроить правила для аудита. Более того, при старте загружаются правила содержащиеся в файле /etc/audit.rules. Некоторые же параметры самого демона можно настроить в файле auditd.conf. |
| acpid | acpid (ACPI event daemon) - демон для реакции на ACPI события, например, реакция на нажатие кнопки питания или закрытия крышки ноутбука. Управление питанием и взаимодействие Linux с BIOS через ACPI (Advanced Configuration and Power Interface) и APM. Режимы "засыпания" ACPI: S1 - все спит, CPU в режиме минимальной активности; S3 - "Suspend to RAM" - все засыпает, CPU отключается; S4 - "Suspend to Disk" дамп состояния сохраняется на диск, система отключается, после включения работа системы восстанавливается с прежнего места; S5 - программное выключение питания. http://acpid.sourceforge.net/ |
| atd | выполняет очередь заданий at(1) |
| autofs | Формат таблицы автомонтирования. Таблицами (map-файлами) автомонтирования могут являться файлы, либо таблицы NIS, на которые ссылается основная (master) таблица автомонтирования (см. auto.master(5)). В таблицах описывается расположение файловых систем, которые автоматически подмонтируются к базовым точкам монтирования (задаваемых в файле auto.master). Здесь описывается формат таблицы sun, для другого формата (например, hesiod) этот документ не применим. Таблицы можно редактировать `на лету" -- эти изменения будут учтены при следующей операции с данной таблицей. Однако это не относится к основной таблице auto.master! |
| biod | Работает совместно с удаленным nfsd для разрешения клиентских запросов NFS. |
| certmonger | Демон certmonger отслеживает и проверяет сертификаты на истечение срока их действия, и опционально может обновить сертификаты с помощью CA. Он может управлять всем процессом регистрации от генерации ключа до регистрации и обновления. |
| cgconfig | Этот скрипт запускает утилиту cgconfigparser, которая анализирует и настраивает the control group filesystem (cgroup). Для анализа используется конфигурационный файл /etc/cgconfig.conf и определённые в нём параметры. |
| cgred | Демон управляющий правилами cgroup:) |
| cpufreq | Скрипт подгружаюет модули ядра для управления частотой процессора. |
| cpuspeed | Изменяет частоту ЦПУ с целью экономии энергии. Многие современные ноутбуки и настольные ПК поддерживают эту технологию. Его могут использовать пользователи с процессорами Pentium-M, Centrino, AMD PowerNow, Transmetta, Intel SpeedStep, Athlon-64, Athlon-X2, Intel Core 2. Пользователям ноутбуков этот демон рекомендуется оставить включенным. Выключите этот демон, если нужно чтобы CPU использовал фиксированную величину частот. |
| crond | |
| cupsd | Сервер работы с печатью. Как доступ к удаленным принтерам, доступ к локальным, доступ извне к локальным. |
| dbus | Система межпроцессного взаимодействия (Более широкий аналог CORBA и DCOP ) |
| dbus-daemon | Демон для работы с шиной данных |
| dhcpd | Демон динамического определения конфигурации TCP/IP для клиентов. |
| dnsmasq | Демон, кэширующий DNS имена и предоставляющий DHCP-сервер. |
| earlysyslog | Запуск демона syslog, обеспечивает ведение логов. |
| earlyxdm | Запуск X-сервера |
| esound | Демон звука, с поддержкой удаленного доступа к звуковой карте |
| esd | Звуковой сервер для оконного менеджера Enlightenment и среды GNOME. ESD смешивает звуковые потоки нескольких одновременно выполняемых программ и выводит получающийся поток на звуковую плату. Принадлежит пакету esound . |
| fam | FAM (File Alteration Monitor ) - монитор изменения файлов. Демон FAM используется окружениями рабочего стола, такими как GNOME, Xfce и KDE для отслеживания и отображения изменений, вносимых в файловую систему. Входит в состав пакета fam. Имеет описание на wiki.archlinux.org . |
| fancontrol | Контроль скорости вращения кулера CPU. Входит в состав lm_sensors. |
| fbset | Скрипт, необходимый для работы фреймбуфера. Настраивает его работу, в том числе подгружает модули ядра. |
| festival | Демон, дающий возможность работать программам по чтению текстов. |
| fingerd | Обеспечивает сетевой интерфейс для протокола finger, для использования команды finger. |
| firstboot | Сервис специфичный только для Fedora. Запускается только один раз после установки для после инсталяционной настройки (задание пароля root, добавление пользователей и прочее). Может быть выключен после установки системы. |
| ftpd | Служба для передачи файлов по FTP протоколу. |
| functions | Один из системных скриптов инициализации Arch Linux. В нём описаны функции переопределяющие значения используемые при загрузке в runlevel 3. Скрипт используется только, если пользователь использует runlevel 5. Входит в состав initscripts. |
| gpm | Cервер мыши для консоли и xterm. Содержится в одноимённом пакете. |
| gpsd | Интерфейс для связи с GPS оборудованием. Большая часть пользователей может выключить его. |
| haldaemon, hal | HAL расшифровывается как Hardware Abstraction Layer. Критичный сервис для сбора информации об оборудовании из разных источников. Рекомендуется оставить его включенным. |
| halt | Скрипт выключения и перезагрузки. |
| halt.local | Скрипт, команды которого должны быть выполнены до начала выключения или перезагрузки. |
| healthd | Настраивает рабочий диапазон температур материнской платы/процессора, частот вращения кулеров. Является одним из компонентов lm_sensors. |
| heimdal-kdc | Центр распределения ключей. Входит в пакет heimdal. |
| httpd | Демон Веб-сервера Apache . |
| init | Unix программа, которая порождает все остальные процессы. По умолчанию в демоне init определенно 7 уровней выполнения, на каждом из этих уровней выполняется заранее определенный набор системных служб. Уровни запуска: Более подробно про уровни запуска: less /etc/inittab |
| inetd | Прослеживает сетевые запросы. При допустимом запросе запускает фоновый процесс для обслуживания запроса. В некоторых системах используется расширенная версия - xinetd |
| iptables | Стандартный брандмауэр в Linux. Особо рекомендуется при непосредственном подключении к сети Интернет (по кабелю, DSL, T1). Не рекомендуется если дополнительно используется аппаратный фаервол (Netgear, Linksys, D-Link и пр.). |
| ip6tables | Сервис iptables работающий по IPv6 протоколу. Если вы выключили поддержку IPv6, то этот сервис должен быть отключен. В ином случае рекомендуется оставить его включенным. |
| irda | IrDA нужна для поддержки устройств, которые работают через инфракрасный порт (ноутбуки, PDA, мобильные телефоны, калькуляторы (прим. переводчика: калькуляторы? о_О ), и т.д. Большинство пользователей может выключить его. |
| irexecd | Демон для инфракрасника. Поставляется с lirc-utils. |
| irqbalance, irq_balancer | В многопроцессорных системах служит для распределения прерываний между процессорами. Пользователи не имеющие многопроцессорных компьютеров/ноутбуков, могут отключить данный демон/сервис. Включение этого сервиса на одно процессорном компьютере не даст никакого эффекта. На новых компьютерах с более чем одним процессором (Intel Core 2 Duo, AMD X2) этот сервис должен быть включен. |
| ivman | Демон отвечающий за автомонтировании устройств в системе(CD-дисков, USB-дисков и т.д.) |
| jackd, jack-audio-connection-kit | Аудио сервер |
| jexec | Обеспечивает поддержку для запуска и работы приложений на java - JAR. Будет доступен, если вы установите Java от Sun. Является необязательным и может быть отключен. |
| joystick | Скрипт подгружающий модули ядра для работы джойстика. |
| kadmind | Демон для определения учётных записей, имеющих доступ к базе данных Kerberos и их уровень доступа. Является одним из компонентов пакета heimdal. |
| kdump | kdump - display kernel trace data. The command displays the kernel trace files produced with ktrace(1) in human readable format. By default, the file ktrace.out in the current directory is displayed. |
| kbd | Настройка клавиатуры в виртуальном терминале. |
| kdm | KDM (KDE Display Manager ) - одна из программ пакета kdebase (входящего в состав KDE ), которая предоставляет возможность входа в систему посредством графического интерфейса. |
| kpasswd | Демон для смены пароля в Kerberos. Является одним из компонентов пакета heimdal. |
| ksysguardd | Демон KDE для мониторинга системы. |
| libvirtd | Демон для управления гостевыми машинами и сетями QEMU. |
| libvirt-guests | Скрипт отправляющий в спящий режим гостевые операционные системы при выключении и пробуждающий их при загрузке. |
| lircd | Демон LIRC расшифровывающий сигналы поступающие с ИК-порта. Поставляется с lirc-utils. |
| lircmd | Демон LIRC транслирующий сигналы мыши. Поставляется с lirc-utils. |
| lvm2-monitor | Демон для мониторинга LVM (Logical Volume Management). Рекомендуется если вы используете LVM, иначе оставьте его выключенным. |
| lpd | «Line Printer Daemon» - протокол служит для управления спулом печати. |
| mdadm | Демон ведущий наблюдение за MD устройствами (программным RAID в Linux). |
| mdmonitor и mdmpd | Эти два демона используются в системах хранения данных с RAID-массивами (redundant array of inexpensive/independent disks). Mdmonitor запускает, останавливает и перезапускает mdadm (multipath device monitoring and management) - программную службу мониторинга и управления RAID. Запускать эту службу нужно только в том случае, если в вашей системе имеются RAID-устройства. |
| messagebus | Сервис межпроцессного взаимодействия для Linux. Критичный компонент поскольку связан с D-BUS. Крайне рекомендуется оставить его включенным. |
| microcode_ctl, microcode.ctl | Сервис позволяющий обновлять прошивку процессора Intel (Pentium Pro, PII, Celeron, PIII, Xeon, Pentium 4 и так далее). Обновления записываются каждый раз при загрузке. Должен быть включен только если у вас процессор Intel. |
| mcelog, mcelogd | Для мониторинга аппаратных проблем в 64-разрядных сборках Linux удобно использовать пакет mcelog, анализирующий MCE (Machine Check Exception) состояние в CPU AMD и Intel, которое может указать на проблемы с памятью и с кэшем CPU, ошибки обмена данными между CPU и чипсетом материнской платы. |
| mpd | Music Player Daemon - музыкальный проигрыватель имеющий клиент-серверную архитектуру, который воспроизводит музыку из указанного каталога. |
| multipathd | Используется для мониторинга за Multi-Path устройствами, то есть накопителями, доступ к которым может осуществляться более чем одним контроллером или методом. |
| mysqld, mysql | Демон базы данных MySQL |
| nfsd | Процесс NFS операторских запросов для клиентских систем. Исторически каждый nfsd демоном поддерживает один запрос за раз, по этому запускается несколько копий. |
| netconsole | Позволяет экспортировать консоль на другую машину по сети. По умолчанию может быть выключенным. |
| netfs | Во время загрузки автоматически монтирует файловые системы доступные по сети (NFS, Samba и прочих ). Большая часть пользователей настольных ПК и/или ноутбуков могут выключить его. |
| network | Демон, отвечающий за создание и настройку локальных сетевых интерфейсов(LAN) |
| network-remotefs | То же самое, что и предыдущий, но дополнительно поднимает wireless-интерфейсы |
| nfs, nfslock | Сервисы обеспечивают работу стандартной сетевой файловой системы для ОС Unix/Linux и BSD. Если нужно открыть доступ по NFS, оставьте его включенным, иначе можно выключить. |
| nginx | nginx - веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системах. |
| nmbd | Используется Samba. Смотрите Samba ниже. |
| nscd | Демон сервера кеширующего имена и пароли используемые сервисами типа NIS, NIS+, LDAP, hesiod. Может быть выключен. |
| nslcd | local LDAP name service daemon. |
| ntpd | NTP демон, который управляет синхронизацией времени по сети. xntpd снабжён 3-й версией стандарта NTP. |
| ntpdate | |
| oddjobd | The oddjobd daemon provides the com.redhat.oddjob service on the system-wide message bus. Each facility which oddjobd provides is provided as a separate D-Bus method. |
| openntpd | Сервер и клиент для синхронизации времени. |
| openvpn | Обеспечивает безопасный метод создания VPN. Для дополнительной информации смотрите OpenVPN . Может быть отключен, если его не использует NetworkManager. |
| pcmcia | Предоставляет поддержку карт расширения стандарта pcmcia. Обычно используется только в ноутбуках. |
| pcscd | Предоставляет поддержку для кардридеров и смарт карт. Если нет кардридера или смарт-карт, то можно выключить этот сервис. Часто имеются в наличии на ноутбуках. |
| portreserve | Предотвращает доступ к реальным портам для различных RPC служб и предоставляет приоритет зарезервированным приложениям. Более детальную информацию можно найти на странице руководства man portreserve . Рекомендуется оставить включенным. |
| powerfail | Этот скрипт запускается при обнаружении сообщений от UPS |
| postfix | Программа управления почтовой системой Postfix |
| pppd | Демон протокола точка-точка (Point-to-Point Protocol Daemon) |
| ppp | Скрипт для работы с демоном pppd. |
| psacct | Управляет процессами ядра Linux. Занимается мониторингом. |
| purge-kernels | Скрипт для автоматического удаления старых ядер (настраивается в /etc/zypp.conf ) |
| quota_nld | quota netlink message daemon |
| raw | Скрипт подгружает модули raw-устройств. |
| rdisc | Демон поиска сетевого шлюза, rdisc выступает клиентом протокола поиска шлюза по ICMP. rdisc вызывается при загрузке для получения таблиц маршрутизации сети с шлюзами по умолчанию. |
| rdate | служба нужна для синхронизации компьютера с сервером времени при загрузке операционной системы. Можно отключить. |
| restorecond | Используется для восстановления контекста и наблюдения за политикой SELinux относящейся к файлам. Сервис не обязателен, но рекомендован при использовании SELinux. |
| rngd | rngd - Check and feed random data from hardware device to kernel random device. Дословно можно перевести как демон проверяющий и получающий случайные данные от аппаратных устройств для ядра случайных устройств - лихо как закручено:), random number generator daemon, по русски демон генерации случайных чисел. |
| rpcbind | Демон для управления RPC, которые используются другими сервисами (как NFS или NIS). Работает подобно portmap. Может быть отключен, если нет других сервисов, зависящих от этого. |
| rpcgssd, rpcidmapd, rpcsvcgssd | Используются NFS v4 (Network File System). Выключите, если вам не нужен NFS v4. http://ru.wikipedia.org/wiki/Network_File_System |
| rsyslog | rsyslog служит для удобного сбора и обработки системных логов и позиционирует себя как расширенный модуль syslogd для систем Unix и Linux, акцентированный на безопасности и надежности, а также обладает продвинутой многопоточностью. Rsyslog предлагает широкий круг возможностей, с которым можно ознакомится перейдя по ссылке – RSyslog features. http://www.rsyslog.com/module-Static_Docs-view-f-features.html.phtml |
| rsync | rsync (Remote Synchronization ) - программа для UNIX-подобных операционных систем, выполняющая синхронизацию каталогов и файлов в нескольких местах с минимизацией трафика, используя кодирование данных при необходимости. rsync была создана как замена для rcp и scp. Подробнее... |
| saslauthd | Демон сервера аутентификации SASL. SASL (Simple Authentication and Security Layer ) предоставляет возможность аутентификации в протоколах, основанных на удаленных соединениях. |
| samba, smbd | Демон сервера samba. |
| sendmail | Обеспечивает поддержку локального IMAP или POP3 сервиса, оставьте его включенным. Сервис может оказаться полезным для оповещения про активность различных демонов/сервисов, которые можно обеспечить посредством cron или отправки почты из РНР скриптов. |
| sensord | Демон из состава lm_sensors, собирает информацию от различных датчиков. |
| sensors | Скрипт который по необходимости подгружает нужные модули ядра для работы с lm_sensors. |
| shorewall | Скрипт для управления фаерволлом shorewall. |
| slim | Login manager для иксов. |
| smartd | Демон SMART наблюдающий за дисками. Используется для предсказания отказов работы и мониторинга дисков или проблем с жёстким диском. Обычно пользователи не нуждаются в этом демоне но, всё таки рекомендуется (особенно для серверов) оставить его включенным. |
| smb | Демон SAMBA требуется для открытия общего сетевого доступа к файлам на Linux для Windows пользователей. Должен быть включён если вы имеете в сети машины на Windows, которым требуется предоставить доступ к файлам. |
| smolt | Демон, который ежемесячно отправляет информацию с целью сбора статистики, для того чтобы помочь разработчикам. Статистика доступна всем. Пользователи, который желают помочь разработчикам должны включить этот сервис включенным. |
| snmpd, snmptrapd | Обеспечивают поддержку SNMP (Simple Network Management Protocol ), который может использоваться для управления и настройки устройств таких как сетевые хабы, серверы, принтеры, и т.д. и т.п. Может быть отключен, однако может потребоваться для запуска сервисов печати HP (hplip ). |
| squid | Демон прокси-сервера Squid . |
| sshd | Прослушивает запросы secure shell от клиентов. SSH позволяет другим пользователям войти в систему по сети с другого компьютера и запустить приложения на вашем компьютере, обычно используется для удалённого администрирования. Это может быть потенциальной угрозой для безопасности. На рабочих станциях не требующих удалённого доступа желательно выключить его. |
| sssd | SSSD (System Security Services Daemon
) позволяет обращаться к удаленным механизмам аутентификации. Таким образом стирается грань меж сетевой и локальной аутентификацией и разрешает использование различных механизмов. Информацию о пользователях передаёт база данных, которая называется доменом и может быть источником данных для удаленной аутентификации. Разрешается использование нескольких механизмов, что позволяет нескольким серверам реализовывать различные пространства имен. Полученная информация предоставляется внешним приложениям при помощи стандартных интерфейсов NSS и PAM. SSSD выполняется как набор служб, которые независят от приложений их вызывающих, а поэтому приложениям необязательно инициировать к удаленным доменам собственные подключения, а также не требуется знать о том, какой именно демон/служба используется в этот момент. Локальное кэширование информации о группах и данных идентификации позволяет независимо от источника данных (LDAP, NIS, IPA, DB, Samba и т.п. ) продолжать работу в автономном режиме, что в целом повышает производительность. SSSD может допускать использование нескольких поставщиков одного типа (например, LDAP ). |
| svnserve | Демон сервера svn. |
| sysstat | Пакет Sysstat содержит утилиты для мониторинга быстродействия системы и используемых ресурсов. |
| swapper | Копирует местный процесс в пространство swap для исправления физической страницы памяти для ядра. Также называется sched. |
| syslogd | Системный процесс записи различных системных сообщений. |
| syncd | Периодически синхронизирует с системной памятью установленные системные файлы. |
| syslog-ng | Демон ведущий системные журналы. |
| udev-post | Системный менеджер устройств, который используется udev. По умолчанию udev поддерживает многочисленное число правил, поведений и прав для устройств. С помощью этого сервиса можно безопасно управлять правилами. Рекомендуется оставить его включенным. |
| vhand | Освобождает страницы памяти для использования другими процессами. Также известен как «page stealing daemon». |
| vsftpd | vsftpd (Very Secure FTP Daemon - Очень Безопасный FTP Демон
) - FTP-сервер поддерживающий IPv6 и SSL. По умолчанию vsftpd используется во многих UNIX-подобных операционных системах, также обслуживает официальные репозитории ftp.openbsd.org, ftp.freebsd.org, ftp.debian.org, ftp.redhat.com и используется на официальном FTP-сервере ядра Linux. |
| webmin | Сервис управления системой через браузер (web-интерфейс ). |
| winbind | Сервис помогающий различать в сети имёна компьютеров под управлением Windows. Может применяться для управления учётными записями Windows с Linux аккаунтов. Обычно большинство пользователей в этом демоне не нуждается и могут оставить его выключенным. |
| wpa_supplicant | Сервис нужен для работы с беспроводными картами, которые для соединения с точками доступа (VPN или Radius серверами ) требуют WPA шифрования. Большинство пользователей могут его оставить выключенным. |
| xfsd | Обслуживает X11 шрифты для удалённых клиентов. |
| yam | служба обновления установленных в системе rpm-пакетов. Используется преимущественно в Fedora Core. |
| ypbind | Сервис служит для NIS аутентификации по сети. Если NIS аутентификация неиспользуется, то можно выключить его. |
| zvbid | Сервис, с помощью которого предоставляется доступ из V4L или V4L2 устройств к нескольким приложениям. Например карта для захвата Hauppage может использовать этот сервис, в остальных случаях его можно выключить. |
Если в приведённом выше списке UNIX/Linux демонов/служб нет работающей на вашей системе, то для получения справки о такой службе используйте man name_daemon , а если и там нет информации о работающей службе, то пишите в комментарии и мы сообща накопаем информации по такой службе и пополним приведённый здесь список UNIX/Linux демонов/служб.
Если в справке man name_daemon нет описания службы, то демон/служба может оказаться вирусом , в таком случае выполните поиск исполняемого файла whereis name_daemon и отправьте его на анализ в вирусную лабораторию - это можно сделать без установки антивируса через веб-интерфейс, например http://vms.drweb.com/online/ , http://www.esetnod32.ru/.support/scanner/ или https://www.virustotal.com/ .
Автозагрузка демонов/служб UNIX/LINUX
Ниже даны подробные инструкции по управлению автозагрузкой демонов/служб в наиболее распространённых модификациях/версиях UNIX-подобных ОС таких как CentOS Linux, Debian Linux и ОС BSD типа . В остальных же модификациях/версиях UNIX-подобных ОС управление автозагрузкой демонов/служб имеет схожий порядок, хотя может иметь некие не существенные или же вовсе радикальные отличия!
Автозагрузка демонов/служб в CentOS Linux
В CentOS уровни загрузки определены по принципу System V и расписаны в файле /etc/inittab , читаем less /etc/inittab .
Каталоги для каждого из уровней загрузки носят названия и расположены в директории /etc/rc.d .
В каждом из каталогов, который соответствует тому или иному уровню загрузки расположены шел скрипты, вернее ссылки на них, с инструкциями для запуска демона/программы/службы, а сами же шел скрипты с инструкциями для запуска демона/программы/службы расположены в каталоге /etc/rc.d/init.d
Пример скриптов управляющих запуском демона/программы/службы можно просмотреть выполнив less /etc/rc.d/init.d/mysqld или less /etc/rc.d/init.d/sshd . Обычно скрипты управляющие запуском демона/программы/службы появляются в /etc/rc.d/init.d/ и линкуются в каталоги уровней запуска после установки ПО, а их статус off/on для каждого из уровней запуска управляется утилитой chkconfig .
Какой из демонов будет запущен на различных уровнях запуска можно посмотреть командой chkconfig --list . Включить демон для автоматического запуска в какой-либо из уровней запуска можно командой chkconfig --level 345 mysqld on , а выключить chkconfig --level 345 mysqld off соответственно, chkconfig –del service_ name удалить службу, chkconfig service_name on|off включить или выключить службу на всех уровнях.
Что касается добавления скриптов в автозагрузку, то для автоматической загрузки скриптов служит /etc/rc.local , в /etc/rc.local достаточно добавить полный путь к скрипту, например: /root/scripts/script.sh или /bin/sh /root/scripts/script.sh . Если после установки ПО в /etc/rc.d/init.d/ нет скрипта управляющего автозапуском нужной программы, то строку её инициализации/запуска проще добавить в /etc/rc.local.
Для управления уровнями запуска существует утилита ntsysv, man ntsysv .
Автозагрузка демонов/служб в Debian Linux
Каталоги для каждого из уровней загрузки в Debian Linux тоже носят названия rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d но, расположены уже не в директории /etc/rc.d, а в корне каталога /etc
Шел скрипты с инструкциями для запуска демона/программы/службы, вернее символические ссылки на них расположены в каталогах /etc/rc?.d где знак? соответствует уровню загрузки, а сами же шел скрипты с инструкциями для запуска демона/программы/службы расположены в каталоге /etc/init.d . Пример такого скипта, по образцу которого можно написать свой, можно найти в файле less /etc/init.d/skeleton .
Ниже дадим пояснения служебной информации используемой в заготовке скрипта /etc/init.d/skeleton:
- Provides: Описывает предоставляемые этим скриптом объекты (арг1, агр2, ...) таким способом, что, когда скрипт запускается с аругментом start, данные объекты считаются существующими, и, следовательно, другие скрипты в init, которые требуют существование этих объектов, смогут запуститься на более поздней стадии. Обычно, можно использовать имя скрипта в качестве объекта, но так же можно использовать имя сервиса, которую он заменяет. Виртуальные объекты тут не указываются. Они определены вне скриптов init.d
- Required-Start: Задаёт объекты, которые должны существовать, чтобы запустить скрипт. При необходимости можно использовать виртуальные объекты, как описано ниже. Если объекты не указывается, то скрипт может быть запущен сразу после старта, без необходимости подключения локальных файловых систем, запуска системного журнала и т.д.
- Required-Stop: Задаёт используемые сервисом объекты, предоставляемые скриптом. Предоставляемый этим скриптом объект, должен завершиться до завершения перечисленных тут объектов, чтобы избежать конфликтов. Обычно, здесь указывают те же объекты, что и в Required-Start
- Should-Start: Задаёт объекты, которые, если существуют, должны должны быть запущены перед сервисом, предоставляемым данным скриптом. Это допускает слабые зависимости, которые не приводят сервис к ошибке, если объекты не доступны. Можно использовать при необходимости виртуальные объекты, как описано ниже.
- Should-Stop: Задаёт объекты, если существуют должны быть остановлены уже после данного сервиса. Обычно, здесь указывают те же объекты, что и в Should-Start
- Default-Start: Задаёт уровни запуска, на которых скрипт должен быть запущен (остановлен) по умолчанию. Например, если сервис должен быть запущен на только уровнях 3, 4 и 5, укажите "Default-Start: 3 4 5" и "Default-Stop: 0 1 2 6".
- Short-Description: Задаёт короткое описание действия скрипта. Ограничено одной строкой.
- Description: Задаёт более подробное описание действия скрипта. Может быть в несколько строк, в этом случае, каждая строка описания должна начинаться с символа # с последующим знаком табуляции или как минимум 2-мя символами пробела. Описание заканчивается перед линией, не совпадающим с этим условием.
- X-Start-Before, X-Stop-After: Задаёт обратные зависимости, которые значат то же, как если бы они были указаны в should-start и should-stop в пакетах, указанных тут.
Для отслеживания зависимостей важны ключевые слова provides, required- и should-. Остальные не используются. Уровни запуска используются программой по умолчанию для упорядочивания скриптов (например, insserv ) для того, чтобы отслеживать, какой из каталогов rc?.d обновлять, когда служба добавляется в первый раз, и должны отражать назначение сервиса. Вот некоторые "виртуальные" объекты:
- $local_fs - Все локальные фаловые системы подключены. Все скрипты, которые производят запись в /var/ должны зависеть от этого, если они уже не зависят от $remote_fs
- $network - низкоуровневая сеть, т.е. сетевые карты, может подразумеваться PCMCIA запущеной
- $named - Демоны, которые могут предоставлять разрешение доменных имён предполагаются запущенными. Например, DNS, NIS+ или LDAP
- $portmap - Демоны, предоставляющие сервис SunRPC/ONCRPC portmapping как указано в 1833 (если они есть)
- $remote_fs - Все файловые системы подключены. Скрипты, которые должны быть запущены во время остановки системы до того, как всем процессам будет отправлен сигнал уничтожения, должны зависеть от $remote_fs.
- $syslog - системный журнал функционирует
- $time - установленно корректное системное время, например, ntp или rdate, или RTC
- $all - Запускает скрипт как можно последним
Управление автозагрузкой демонов в Debian Linux осуществляется при помощи утилиты update-rc.d, подробно в man update-rc.d . Утилита update-rc.d не создаёт и не удаляет ничего, кроме символических ссылок в /etc/rc?.d на так званые init скрипты управляющие запуском и остановкой демона/программы/службы, которые расположены в каталоге /etc/init.d.
Если скрипт для автозапуска демона/сервиса создан вручную по шаблону /etc/init.d/skeleton , то его нужно сначала разместить в каталоге /etc/init.d, потом создать символьную ссылку на этот скрипт в каталоге /etc/rc?.d, где? - номер runlevel’а (уровень загрузки системы ). Символическая ссылка должна иметь такой вид S№№имя_скрипта , где №№ - это номер очередности запуска, если требуется оставить символическую ссылку но, скрипт временно не запускать, то символическую ссылку следует модифицировать до такого состояния K№№имя_скрипта.
Перед началом обработки любого из уровней исполнения сначала выполняются все скрипты, которые начинаются с буквы "K " (эти скрипты останавливают сервисы ), а потом выполняются все скрипты, которые начинаются с буквы "S " (эти скрипты запускают сервисы ). Двузначное число после буквы "S" или "K" указывает на порядок, в котором будут выполняются скрипты . Скрипты с меньшим номером выполняются первыми, например: S01имя_скрипта стартует первым, а S09имя_скрипта будет запущен девятым.
Для создания символьной ссылки используется программа ln -s file1 file2 , где ключ -s говорит о создании именно символьной ссылки, file1 указывает на существующий файл, а file2 имя новой ссылки но, вместо создания символических линков вручную, можно использовать утилиту update-rc.d, которая создана именно для создания символических ссылок в /etc/rc?.d на скрипты из /etc/init.d.
Синтаксис update-rc.d такой
: добавление с параметрами по умолчанию update-rc.d
Признаться update-rc.d является относительно мутной утилитой, более удобной является утилита chkconfig , которая в Debian Linux отсутствует по умолчанию. Для её установки нам нужно добавить дополнительные репозитории, желательно использовать только официальные репозитории пакетов Debian Linux , в конец списка vi /etc/apt/sources.list , пример sources.list в Debian GNU/Linux 6.0.5 _Squeeze_ - Official i386 :
# # deb cdrom:/ squeeze main deb cdrom:/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-updates, previously known as "volatile" # A network mirror was not selected during install. The following entries # are provided as examples, but you should amend them as appropriate # for your mirror of choice. # # deb http://ftp.debian.org/debian/ squeeze-updates main # deb-src http://ftp.debian.org/debian/ squeeze-updates main deb http://backports.debian.org/debian-backports squeeze-backports main deb http://ftp.debian.org/debian/ squeeze main #deb http://repo.yandex.ru/debian squeeze main contrib #deb http://mirror.yandex.ru/debian squeeze main contrib #deb http://mirror.yandex.ru/debian-multimedia/ squeeze main contrib
После чего обновить список пакетов apt-get update и выполнить установку chkconfig apt-get install chkconfig , а также как альтернативу дополнительно можно поставить sysv-rc-conf apt-get install sysv-rc-conf . Как пользоваться утилитой chkconfig было упомянуто выше, дополнительно смотрим man sysv-rc-conf и man chkconfig .
Добавляя репозитории Debian Linux следует помнить о политике программного обеспечения применяемой к каждой из областей таких как main, contrib и non-free :
- main : - пакеты из этой области являются частью полного дистрибутива Debian Linux и ни один из пакетов из области main для полноценного функционирования не требуют программного обеспечения из-за пределов этой области. Любой может свободно использовать, обмениваться, изменять и распространять пакеты из области main.
- contrib : - пакеты из этой области могут свободно распространяться, однако некоторые их зависимости могут быть не свободны.
- non-free : - содержит пакеты, которые не могут распространяться бесплатно согласно DSFG, а также пакеты из области могут содержать такие ошибки которые не учитываются при разработке и обновлении Debian Linux.
Для автозапуска прочих скриптов и программ в Debian Linux можно использовать старый-добрый /etc/rc.local.
Действиями демона 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.
Каждый из начинающих пользователей 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.
- Пер. С.Лапшанский, "Демон следит за системой"
- Денис Колисниченко,
Размещение перед именем файла символа канала (|) позволит использовать fifo (first in - first out, первый пришел - первый вышел) или именованный канал (named pipe) в качестве приемника для сообщений. Прежде чем запускать (или перезапускать) syslogd, необходимо создать fifo при помощи команды mkfifo. Иногда fifo используются для отладки.
Терминал и консоль
Терминал, такой как /dev/console.
Удаленная машина
Чтобы сообщения пересылались на другой хост, поместите перед именем хоста символ (@). Обратите внимание, что сообщения не пересылаются с принимающего хоста. (для работы данного назначения на клиенте и сервере в файле /etc/services должна быть прописана строчка syslog 514/udp , и открыт UTP-порт 514)
Список пользователей
Разделенный запятыми список пользователей, получающих сообщения (если пользователь зарегистрирован в системе). Сюда часто включается пользователь root.
Все зарегистрированные пользователи
Чтобы известить всех зарегистрированных пользователей при помощи команды wall, используйте символ звездочки (*).
Пример несложного syslog.conf:
# Все сообщения ядра выдавать на консоль. #kern.* /dev/console # Все логи уровня info или выше, кроме сообщений электронной почты, а так же # не логировать сообщения аутентификации и сообщений демона cron! *.info;mail.none;authpriv.none;cron.none /var/log/messages # Записывать в отдельный файл сообщения, содержащие конфиденциальную # информацию аутентификации, независимо от их уровня. authpriv.* /var/log/secure # Все сообщения почтовой системы тоже записывать в отдельный файл. mail.* -/var/log/maillog # Логировать сообщения планировщика в файл /var/log/cron cron.* /var/log/cron # Сообщения о чрезвычайных ситуациях должны немедленно получить # все пользователи системы *.emerg * # Сохранять сообщения новостей уровня crit и выше в отдельный файл. uucp,news.crit /var/log/spooler # Сохранять сообщения загрузки в boot.log local7.* /var/log/boot.log
Как и во многих конфигурационных файлах, синтаксис следующий:
- строки, начинающиеся с #, и пустые строки игнорируются.
- Символ * может использоваться для указания всех категорий или всех приоритетов.
- Специальное ключевое слово none указывает, что журналирование для этой категории не должно быть выполнено для этого действия.
- Дефис перед именем файла (как -/var/log/maillog в этом примере) указывает, что после каждой записи журнал не должен синхронизироваться. В случае аварии системы вы можете потерять информацию, но отключение синхронизации позволит повысить производительность.
В синтаксисе конфигурационного файла можно поставить перед приоритетом знак! , чтобы показать, что действие не должно применяться, начиная с этого уровня и выше . Подобным образом, перед приоритетом можно поставить знак = , чтобы показать, что правило применяется только к этому уровню, или != , чтобы показать, что правило применяется ко всем уровням, кроме этого. Ниже показано несколько примеров (man syslog.conf можно найти множество других примеров):
# Посылать все сообщения ядра в /var/log/kernel. # Посылать все сообщения уровня critical и higher на удаленную машину sysloger и на консоль # Посыласть все сообщения уровня info, notice и warning в /var/log/kernel-info # kern.* /var/log/kernel kern.crit @sysloger kern.crit /dev/console kern.info;kern.!err /var/log/kernel-info # Посылать все сообщения почтовой системы, кроме уровня info в /var/log/mail. mail.*;mail.!=info /var/log/mail
Я постарался максимально понятно работу syslogd показать на схеме:
Запуск демона syslogd
Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog , однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт - начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian) .
Вот некоторые возможные параметры запуска демона syslogd:
- -a /folder/socket - указание дополнительного слушающего сокета (не забудьте предварительно создать сокет)
- -d - отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал;
- -f имя-конфигурационного-файла . Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf;
- -l список-хостов - задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN - Full Qwalified Domain Name);
- -m минут - запущенный без этой опции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений;
- -p socket - задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
- -r - разрешение принимать сообщения от удаленных хостов;
- -x - запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
- -v - показать версию и закончить работу
После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid .
С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`
можно послать демону syslogd один из следующих сигналов: SIGHUP - перезапуск демона; SIGTERM - завершение работы; SIGUSR1 - включить/выключить режим отладки.
Вообще-то в системе запускаются два демона протоколирования - syslogd и klogd . Оба демона входят в состав пакета sysklogd .
Демон klogd отвечает за журналирование событий, происходящих в ядре системы . Необходимость в отдельном демоне klogd объясняется тем, что ядро не может использовать стандартную функцию syslog. Дело в том, что стандартные библиотеки С (включая ту библиотеку, в которой находится функция syslog) предназначены для использования только обычными приложениями . Поскольку ядро тоже нуждается в функциях журналирования, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро использует свой собственный механизм генерации сообщений.
Демон klogd предназначен для организации обработки этих сообщений. В принципе он может производить такую обработку полностью самостоятельно и независимо от syslogd, например, записывая эти сообщения в файл, но в большинстве случаев используется принятая по умолчанию настройка klogd, при которой все сообщения от ядра пересылаются тому же демону syslogd.
Автоматическая ротация (обновление заполненных файлов) и архивирование журналов
Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate , которая обычно выполняется демоном cron . О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.
Для определения порядка ротации и архивирования журналов используется конфигурационный файл /etc/logrotate.conf . Для разных журналов можно задать разную периодичность, например, ежедневно, еженедельно или ежемесячно, кроме того, можно регулировать количество накапливаемых поколений, а также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. Ниже показан пример файла /etc/logrotate.conf:
# сначала заданы параметры "по-умолчанию" (глобальные опции) # обновлять файлы журнала еженедельно weekly # хранить архив логов за 4 последние недели rotate 4 # создавать новый (пустой) файл после ротации (обновления) create # раскомментируйте, если желаете, чтобы сохраненные файлы сжимались #compress # включить настройки ротации из указанного каталога include /etc/logrotate.d # не хранить wtmp, или btmp -- настройки ротации данных журналов следующие: /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0664 root utmp rotate 1 } # специфичные системные журналы могут быть настроены ниже
Глобальные опции размещаются в начале файла logrotate.conf . Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.
В этом примере также содержатся специальные правила для /var/log/wtmp и /var/log/btmp (хранящие информацию о удачных и неудачных попытках входя в систему), ротация которых происходит ежемесячно. Если файлы отсутствуют, сообщение об ошибке не выдается. Создается новый файл и сохраняется только одна резервная копия.
В этом примере по достижении резервной копией последнего поколения она удаляется, поскольку не определено, что следует с ней делать.
Резервные копии журналов могут также создаваться, когда журналы достигают определенного размера, и могут быть созданы скрипты из наборов команд для выполнения до или после операции резервного копирования. Пример:
/var/log/messages { rotate 5 mail logadmin@sysloger size 100k postrotate /usr/bin/killall -HUP syslogd endscript }
В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.
Параметры , задаваемые в конфигурационном файле logrotate.conf:
- compress | nocompress (старые версии сжимаются или не сжимаются с помощью gzip)
- compresscmd (задает программу сжатия, по умолчанию - gzip)
- uncompresscmd (задает программу разжатия, по умолчанию - ungzip)
- compressext (задает суффикс для сжатых файлов)
- compressoptions (задает параметры программы сжатия; по умолчанию - "-9", т.е. максимальное сжатие для gzip)
- copytruncate | nocopytruncate (обычно старая версия переименовывается и создается новая версия журнала; при задании этого параметра logrotate копирует журнал в новый файл, а затем обрезает старый; используется, если программа, создающая журнал, не умеет его закрывать; теряются записи, сделанные в промежутке между копированием и обрезанием; а поможет ли, если создающая журнал программа вместо режима append просто пишет в файл, используя внутренний указатель?)
- create [права-доступа владелец группа] | nocreate (сразу после переименования старой версии журнала и до вызова postrotate создается новый журнал с указанными атрибутами - права доступа задаются в восьмеричном виде, как в chmod.2; если атрибуты не указаны, то берутся от старого журнала)
- daily (смена версий в серии происходит ежедневно)
- delaycompress | nodelaycompress (некоторые программы не сразу закрывают журнал, в этом случае сжатие надо отложить до следующего цикла)
- errors email (кому направлять сообщения об ошибках)
- extension суффикс (задается суффикс, добавляемый к именам файлов при ротации перед суффиксом сжатия)
- ifempty | notifempty (смена версий даже если файл пуст; действует по умолчанию)
- include имя-файла | имя-директории (текстуально подставить файл или все файлы из указанной директории; не включаются поддиректории, специальные файлы и файлы с суффиксами из списка исключений; нельзя использовать внутри секции)
- mail адрес | nomail (когда смена версий приводит к необходимости удалить старый журнал, то послать его по указанному адресу)
- mailfirst (посылать не удаляемую версию журнала, а первую)
- maillast (посылать удаляемую версию журнала; действует по умолчанию)
- missingok | nomissingok (не посылать сообщения об ошибке, если журнал отсутствует)
- monthly (смена версий происходит ежемесячно)
- olddir директория | noolddir (во время смены версий журнал перемещается в указанную директорию; д.б. на том же физическом устройстве)
- postrotate (все дальнейшие строчки до строки endscript исполняются как команды shell после процесса смены версии)
- prerotate (все дальнейшие строчки до строки endscript исполняются перед процессом смены версии)
- rotate число (сколько старых версий хранить; если 0, то ни одной)
- size байт (смена версии происходит, если размер журнала превысил указанное число; можно использовать суффиксы "k" - килобайт - и "M" - мегабайт)
- sharedscripts | nosharedscripts (выполнять команды prerotate и postrotate только один раз для всех файлов, описанных в секции)
- tabooext [+] список-суффиксов (задание списка суффиксов-исключений для include; если указан знак "плюс", то дополнение, иначе замена; по умолчанию: .rpmorig, .rpmsave, .rpmnew, ",v", .swp и "~")
- weekly (смена версий происходит еженедельно)
Изучение и мониторинг журналов
Записи в журналах обычно содержат метку времени, имя хоста, на котором выполняется описываемый процесс, и имя процесса. Просматривать журналы можно при помощи программы постраничного вывода, например, less , искать определенные записи (например, сообщения ядра от определенного демона) можно при помощи команды grep :
# less /var/log/messages
# grep "ppp" /var/log/messages | tail
Dec 17 16:34:25 proxy pppd: Connection terminated.
Dec 17 16:34:25 proxy pppd: Exit.
Dec 17 16:35:57 proxy pppd: LCP terminated by peer (^P]kV^@ Компьютер может работать не постоянно и выключаться, допустим на ночь. Поэтому в /var/log/messages записи хранятся циклически от запуска компьютера к выключению, это можно заметить по сообщениям: Дек 17 08:32:56 syslog-server syslogd 1.4-0: restart.
Дек 17 08:32:56 syslog-server syslog: запуск syslogd succeeded
Дек 17 08:32:56 syslog-server kernel: klogd 1.4-0, log source = /proc/kmsg started.
Дек 17 08:32:56 syslog-server syslog: запуск klogd succeeded
Dec 17 08:32:56 syslog-server kernel: Kernel command line:
auto BOOT_IMAGE=linux ro root=303
BOOT_FILE=/boot/vmlinuz-2.4.2-2
Dec 17 08:32:56 syslog-server kernel: Memory: 125652k/130560k available (1365k kernel code, 4200k reserved, 92k data, 236k init, 0k highmem)
Dec 17 08:32:56 syslog-server kernel: CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz stepping 02
Так же, в этом файле можно найти информацию о дисковой памяти (включая информацию о геометрии диска, структуре разделов и используемых прерываниях), информацию о периферийных устройствах, о запуске отдельных служб и сервисов, информацию о подключении файловых систем и сообщения о входе пользователей в систему, а также сообщения об ошибках. Иногда может возникать необходимость мониторинга системных журналов
с целью поиска текущих событий. Например, можно попробовать поймать редко случающееся событие в тот момент, когда оно произошло. В таком случае можно использовать команду tail
с опцией -f
для отслеживания содержимого системного журнала. Пример:
# tail -f /var/log/messages | grep syslog-server
Dec 17 16:46:09 syslog-server pppd: pptpd-logwtmp.so ip-up ppp0 maikop 94.77.0.150
Dec 17 16:46:09 syslog-server pppd: Script /etc/ppp/ip-up finished (pid 12552), status = 0x0
Dec 17 16:46:49 syslog-server pptpd: CTRL: Client 85.175.197.65 control connection started
Dec 17 16:46:49 syslog-server pptpd: CTRL: Starting call (launching pppd, opening GRE)
Dec 17 16:46:49 syslog-server pppd: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Кроме файлов-журналов, указанных в /etc/syslog.conf, существуют так же и другие файлы, например файл , который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы , имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах пользователей в систему и о всех неудачных входах пользователей в систему соответственно. Так же в каталоге /var/log/ могут находится лог-файлы таких демонов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журналам syslogd. На последок, хотелось бы сделать акцент на том, что данный протокол очень не защищен, т.к. syslog не содержит никаких средств защиты от подделок сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам посылать сообщения от имени любого хоста. Ваша локальная сеть должна быть защищена экраном от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp. Известны случаи переполнения диска ложными сообщениями. Протокол syslog и UDP не обеспечивают гарантированной доставки (сообщения могут быть потеряны при перегрузке сети или перехвачены, поврежденные сообщения удаляются без предупреждения), правильной последовательности доставки (сообщение о завершении процесса может придти раньше сообщения о его запуске), приоритетной доставки. Конфиденциальность сообщений не обеспечивается, так как они передаются открытым текстом. Если при настройке генератора сообщений указать неправильный адрес коллектора или релея, то никаких сообщений об ошибке не будет - сообщения будут удаляться (или записываться в чужой журнал). Были предложены несколько проектов улучшения протокола syslog. Например, документ RFC 3195 предлагает систему протоколирования (syslog-conn), основанную на TCP, обеспечивающую гарантированную доставку сообщений в правильной последовательности. Проект syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации специальных сообщений, содержащих цифровую подпись (signature) блока предыдущих сообщений с сохранением стандартного протокола и формата syslog и использованием UDP. Подведем небольшой итог:
В линукс есть единый демон, отвечающий за журналирование событий локальной системы и удаленных систем. Все события собираются из сокета /dev/log, порта UDP - 514, а так же от "помощника" - демона klogd, который присылает сообщения от ядра. Все собранные сообщения фильтруются демоном syslogd через правила в файле /etc/syslog.conf и в соответствии с правилами распределяются по соответствующим местам назначения. Файлы логов периодически "обрезаются". Периодичность определяет файл logrotate.conf и команда logrotate, которая запускается системным планировщиком - cron. На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью! С Уважением, Mc.Sim!
