Что означает такая строка конфигурационного файла etc syslog d mail warning var log mail

Обновлено: 04.07.2024

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

Данное руководство рассматривает различные части механизма журналирования Linux.

Примечание: Команды данного руководства были протестированы на простых установках CentOS 6.4, Ubuntu 12 и Debian 7.

Стандартные логи

По умолчанию журналы в Linux хранятся в /var/log.

Для просмотра списка журналов, находящихся в данном каталоге, используйте команду ls -l /var/log.

В системе CentOS это выглядит так:

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

В каталоге /var/log находится несколько общих журналов:

wtmp
utmp
dmesg
messages
maillog или mail.log
spooler
auth.log или secure

Файлы wtmp и utmp отслеживают пользователей, вошедших и покинувших систему. Содержимое данных журналов нельзя читать с помощью простой команды «cat», для этого есть специальные команды, с которыми теперь нужно ознакомиться.

Чтобы узнать, кто в текущий момент находится на сервере Linux, нужно использовать команду «who». Она извлекает информацию из /var/run/utmp (в CentOS и Debian) или из /run/utmp (в Ubuntu).

Это пример ее работы в CentOS:

Команда «sysadmin» выводит историю входа пользователей:

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

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

Результат имеет примерно такой вид:

reboot system boot 2.6.32-358.el6.x Mon Dec 9 10:27 - 10:47 (00:19)
reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:37 - 10:47 (2+18:10)
reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:28 - 16:36 (00:08) reboot system boot 2.6.32-358.el6.x Fri Dec 6 11:06 - 16:36 (05:29)
reboot system boot 2.6.32-358.el6.x Mon Dec 2 17:00 - 16:36 (3+23:36)
reboot system boot 2.6.32-358.el6.x Fri Nov 29 16:01 - 16:36 (7+00:34)
reboot system boot 2.6.32-358.el6.x Fri Nov 29 15:43 - 16:36 (7+00:53)
.
.
wtmp begins Fri Nov 15 16:11:54 2013

Чтобы узнать время последнего входа в систему, используйте lastlog:

Результат на CentOS выглядит примерно так:

Username Port From Latest
root tty1 Mon Dec 9 10:44:30 +1100 2013
bin **Never logged in**
daemon **Never logged in**
adm **Never logged in**
lp **Never logged in**
sync **Never logged in**
shutdown **Never logged in**
halt **Never logged in**
mail **Never logged in**
uucp **Never logged in**
operator **Never logged in**
games **Never logged in**
gopher **Never logged in**
ftp **Never logged in**
nobody **Never logged in**
vcsa **Never logged in**
saslauth **Never logged in**
postfix **Never logged in**
sshd **Never logged in**
sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31:50 +1100 2013
dbus **Never logged in**
joeblog pts/2 10.0.2.2 Mon Dec 9 10:39:24 +1100 2013

Для просмотра содержимого текстовых журналов можно использовать команды «cat», «head» или «tail».

В приведенном ниже примере просматриваются последние 10 строк журнала /var/log/messages на Debian:

$ sudo tail /var/log/messages

Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP filters: protocol multicast
Dec 16 01:21:08 debian kernel: [ 9.648220] Bridge firewalling registered
Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO (Voice Link) ver 0.6
Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO socket layer initialized
Dec 16 01:21:08 debian kernel: [ 9.832215] lp: driver loaded but no devices found
Dec 16 01:21:08 debian kernel: [ 9.868897] ppdev: user-space parallel port driver
Dec 16 01:21:11 debian kernel: [ 12.748833] [drm] Initialized drm 1.1.0 20060810
Dec 16 01:21:11 debian kernel: [ 12.754412] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11
Dec 16 01:21:11 debian kernel: [ 12.754412] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0

Демон rsyslog

Конфигурационный файл rsyslog

Демон rsyslog получает конфигурации из файла «rsyslog.conf», который находится в каталоге /etc.

Этот файл можно найти в rsyslog.d/50-default.conf в Ubuntu.

Под двумя частями строк подразумеваются селектор и действие (selector и action). Они разделяются пробельным символом.

Вот отрывок из файла rsyslog.conf на CentOS:

Чтобы понять, что все это значит, нужно рассмотреть типы объектов, которые распознает Linux:

Ниже приведен список приоритетов по возрастанию:

Изучите следующую строку из файла:

Объекты и приоритеты могут быть связаны в несколькими способами.

Несколько объектов в одной строке нужно разделить запятой.

Несколько селекторов в одной строке также разделяются запятой.

Отмеченное звездочкой действие объединяет всех пользователей.

К примеру, об этом говорит запись в файле rsyslog.conf на CentOS:

По возможности проверьте, что говорит rsyslog.conf на других системах Linux. Вот отрывок из Debian:

Конфигурации для rsyslog могут исходить также от других пользовательских файлов. Эти файлы пользовательских конфигураций, как правило, расположены в разных каталогах в /etc/rsyslog.d. Файл rsyslog.conf включает эти каталоги, используя директиву «$IncludeConfig».

Так это выглядит в Ubuntu:

Для этого нужно будет сделать следующее:

Задать спецификацию в файле /etc/rsyslog.conf;
Перезапустить демон rsyslog;
Проверить конфигурацию с помощью утилиты «logger».

В следующем примере внесены две строки в файл rsyslog.conf на CentOS. Как видите, обе они исходят от объекта local4 и имеют разные приоритеты.

Затем нужно перезапустить сервис, чтобы обновить данные файла:

.
.
-rw------- 1 root root 0 Dec 9 11:21 local4crit.log
-rw------- 1 root root 72 Dec 9 11:22 local4info.log

Ротация лог-файлов

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

Linux использует понятие «ротации» журналов вместо их очистки или удаления. При ротации создается новый каталог, а старый переименуется и при необходимости сжимается. Таким образом, журналы имеют несколько старых версий. Эти файлы будут возвращаться в течение определенного периода времени в виде так называемых backlog-ов. Как только будет получено определенное количество backlog-ов, новая ротация удалит самый старый журнал.

Ротация выполняется при помощи утилиты «logrotate».

Конфигурационный файл logrotate

Как и rsyslog, logrotate зависит от конфигурационного файла по имени logrotate.conf, который находится в /etc.

Вот что находится в данном файле на Debian:

По умолчанию журналы ротируются еженедельно, оставляя 4 backlog-а. При запуске программы создается новый пустой журнал, а старые при необходимости будут сжаты.

Файлы wtmp и btmp являются исключениями. wtmp отслеживает вход в систему, а btmp содержит информацию о неудавшихся попытках входа. Эти журнальные файлы ротируются каждый месяц, и ошибки не возвращаются, если можно найти один из предыдущих файлов wtmp или btmp.

Пользовательские конфигурации ротации журналов содержатся в каталоге «etc/logrotate.d». также они включены в logrotate.conf с помощью директивы include. К примеру, Debian показывает такое содержание данного каталога:

$ ls -l /etc/logrotate.d
total 44
-rw-r--r-- 1 root root 173 Apr 15 2011 apt
-rw-r--r-- 1 root root 79 Aug 12 2011 aptitude
-rw-r--r-- 1 root root 135 Feb 24 2010 consolekit
-rw-r--r-- 1 root root 248 Nov 28 2011 cups
-rw-r--r-- 1 root root 232 Sep 19 2012 dpkg
-rw-r--r-- 1 root root 146 May 12 2011 exim4-base
-rw-r--r-- 1 root root 126 May 12 2011 exim4-paniclog
-rw-r--r-- 1 root root 157 Nov 16 2010 pm-utils
-rw-r--r-- 1 root root 94 Aug 8 2010 ppp
-rw-r--r-- 1 root root 515 Nov 30 2010 rsyslog
-rw-r--r-- 1 root root 114 Nov 26 2008 unattended-upgrades

Содержание rsyslog показывает, как вернуть логи в исходное состояние:

$ cat /etc/logrotate.d/rsyslog
/var/log/syslog
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
>
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
>

Как видите, файл «syslog» будет повторно инициализирован каждый день. Другие журнальные файлы ротируются каждую неделю.

Также стоит упомянуть директив postrotate. Она указывает действие, которое происходит после того, как ротация журналов завершена.

Тестирование ротации

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

Чтобы продемонстрировать, как это работает, ниже приведен неполный список журнальных файлов в каталоге /var/log на CentOS:

Неполное содержимое файла logrotate.conf выглядит так:

Затем запустите команду logrotate:

Заключение

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

Управление типом и подробностью журналируемой информации

Конфигурационный файл syslog.conf

Источник (он же категория) может быть следующим:

Обычный файл

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

Именованные каналы

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

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

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

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

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

* . info ; mail . none ; authpriv . none ; cron . none / var / log / messages

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подсистемой учетных записей пользуется подсистема идентификации , которая в Linux имеет модульную структуру и называется PAM (Pluggable Authentication Modules, т. е. "Подключаемые модули идентификации "). Идея PAM – в том, чтобы унифицировать и, вместе с тем, сделать более гибкими любые процедуры идентификации в системе – начиная от команды login и заканчивая доступом к файлам по протоколу, скажем, FTP. Для этого недостаточно просто написать "библиотеку идентификации " и заставить все программы ее использовать. В зависимости от того, для чего производится идентификация , условия, при которых она будет успешной, могут быть более или менее строгими, а если она прошла успешно, бывает нужно выполнить действия, связанные не с определением пользователя, а с настройкой системы.

В большинстве дистрибутивов PAM обучен схеме " .d ", и настройки каждой службы, которая использует идентификацию , лежат в отдельном файле:

В PAM определено четыре случая, требующие идентификации : auth – собственно идентификация , определение, тот ли пользователь, за кого он себя выдает, account – определение, все ли хорошо с учетной записью пользователя, password – изменение пароля в учетной записи, и session – дополнительные действия непосредственно перед или непосредственно после того, как пользователь получит доступ к затребованной услуге. Эти значения принимает первое поле любого файла настройки из pam .d , а в третьем поле записывается модуль, который проверяет какой-нибудь из аспектов идентификации . Второе поле определяет, как успех или неуспех проверки одного модуля влияет на общий успех или неуспех идентификации данного типа (например, required означает, что в случае неуспеха модуля проверка пройдена не будет). Четвертое и последующие поля отведены под параметры модуля:

Такие настройки login обнаружил Мефодий на своем компьютере. Во всех четырех случаях используется включаемый файл system-auth (к нему обращаются и другие службы), с некоторыми дополнениями. Так, во время идентификации pam_nologin.so дополнительно проверяет, не запрещено ли пользователям регистрироваться вообще (как это бывает за несколько минут до перезагрузки системы), а перед входом в систему и после выхода из нее pam_console.so выполняет описанную в лекции 6 "передачу прав на владение устройствами" (и, соответственно, лишение пользователя этих прав).

Каталог /etc/ pam .d – замечательный пример того, как профиль определяет поведение системы. В частности, четыре первых строки из system-auth показывают, что в этом дистрибутиве используется не просто "теневой" файл паролей, а схема TCB , описанная в лекции 6. (Как уже известно Мефодию, в этой схеме вместо общего для всех /etc/shadow задействованы файлы вида /etc/ tcb /входное_имя/shadow , причем права доступа к ним устроены таким образом, чтобы при выполнении команды passwd можно было обойтись без подмены пользовательского идентификатора на суперпользовательский).

Подсистема системных журналов

Все события, о которых сообщается syslogd , подразделяются горизонтально – по типу службы (facility), с которой это событие произошло, и вертикально – по степени его важности (priority). Типов событий насчитывается около двадцати (среди них auth , daemon , kern , mail и т. п., а также восемь неименованных, от local0 до local7 ). Степеней важности всего восемь, по возрастанию: debug , info , notice , warning , err , crit , alert и emerg . Таким образом, каждое событие определяется парой значений, например, mail.err означает для syslogd событие, связанное с почтой, притом важности, не меньшей err . Из таких пар (с возможной заменой типа или важности на "*", что означает "любые", или none, что означает "никакие") составляется конфигурационный файл /etc/syslog.conf :

Управление типом и подробностью журналируемой информации

Конфигурационный файл syslog.conf

Источник (он же категория) может быть следующим:

Обычный файл

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

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

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

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

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

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

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

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

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

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

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

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

Далее в файле протокола можно обнаружить версию ядра, параметры его запуска, информацию о типе процессора и объеме ОЗУ:

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

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

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

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

Читайте также: