Настройка почтовых оповещений о различных системных событиях

В этой заметке перечислены несколько простых способов заблаговременно узнать о различных проблемах на сервере, не замусоривая почтовый ящик и не настраивая сложных систем мониторинга. Из разряда «если вам лень что-то проверять и настраивать, то настройте и проверяйте хотя бы это».

Часть перечисленных ниже утилит умеет самостоятельно отправлять email-уведомления, для остальных предлагаются несложные shell-обёртки.

В качестве получателя используется дополнительная локальная рассылка admins, которая включает в себя локального root и внешнего admin@example.ru. Почему вместо этого не переопределяется локальный root?

Во-первых, root может по умолчанию принимать много информационных писем, которые помогают _понять_ причину уже _обнаруженной_ проблемы. Они важны, но если отправлять все эти письма наружу, либо потребуется настраивать их фильтрацию, либо повышается вероятность пропустить в их потоке письма, позволяющие _обнаружить_ ещё _неизвестную_ проблему.

Во-вторых, т.к. admins не является стандартным аккаунтом или группой в популярных Linux/Unix-системах, то "grep -r admins /etc /usr/local/etc позволяет быстро определять, для каких утилит настройка уже выполнена.

Настройка почтового сервера

Определение используемого сервера:

1. dpkg-query -S /usr/sbin/sendmail (Debian-based)
2. rpm -qf /usr/sbin/sendmail (RPM-based)
3. sudo netstat -ntlp | grep :25 (all Linux)
4. sockstat -4l | grep :25 (FreeBSD)

Возможные варианты в Debian и Ubuntu: http://packages.debian.org/file:/usr/sbin/sendmail

Дальше все пути и ключи команд приведены в расчёте на Debian, за исключением утилит для FreeBSD, отсутствующих в Linux.

Exim

/etc/aliases:
admins: root, admin@example.ru

Postfix

1. /etc/postfix/main.cf: virtual_alias_maps = hash:/etc/postfix/virtual
2. /etc/postfix/virtual: admins root admin@example.ru
3. cd /etc/postfix && postmap virtual && cd /etc && postalias aliases && /etc/init.d/postfix restart

Полный минимальный main.cf:

#relayhost = mx.example.ru
mynetworks_style = host
inet_interfaces = loopback-only
#inet_protocols = ipv4
virtual_alias_maps = hash:/etc/postfix/virtual

SSMTP, MSMTP, ESMTP

Формальные достоинства по сравнению с полноценным MTA:

1. не занимают места в ОЗУ,
2. проще в настройке,
3. менее уязвимы, т.к. работают с правами вызвавшего пользователя и не принимают сетевых подключений.

Фактические недостатки:

1. если в момент отправки письма по каким-то причинам нет связи с внешним SMTP-сервером, или SMTP-сервер отказался его принять, письмо пропадёт,
2. адреса получателей иногда формируются по таким странным правилам, что SMTP-сервер не в состоянии правильно определить, кому и куда её следует доставить,
3. см. выше соображения про редирект root@

Таким образом, единственное место, где imho имеет смысл их использовать — легковесные виртуальные контейнеры, для пересылки на SMTP-сервер, запущенный на Host OS.

Настройка служб мониторинга

Включение сервера

Даже о таком важном событии, как внеплановые перезагрузки, некоторые администраторы узнают, случайно проверив uptime или last. Немедленно быть в курсе событий поможет следующая строка над «exit» в /etc/rc.local:

M="Booting complete on $(hostname)."; echo $M | mail -s "$M" admins

Linux SoftRAID (mdraid)

1. /etc/mdadm/mdadm.conf: MAILADDR admins
2. /etc/init.d/mdadm restart

SMART

1. /etc/smartd.conf: DEVICESCAN ... -m admins ...
2. /etc/init.d/smartmontools restart

Полный минимальный smartd.conf:
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

lm_sensors

1. Запуск из rc.local: /usr/local/sbin/healthd.sh &
2. Код healthd.sh:
   

   #!/bin/sh
   
   test -z "$(which sensors)" && { echo "No sensors binary, exit."; exit 1; }
   
   while : ; do
   	sensors | grep -q ALARM || { sleep 15; continue; }
   	sensors | grep -q ALARM | logger -s -t "sensors" -p local0.crit
   	sensors | mail -s "Hardware Health Warning"  "admins"
   	sleep 600
   done
   

Другие варианты:

1. healthd.sh — lm-sensors.org/browser/lm-sensors/trunk/prog/daemon/healthd.sh
2. sensormon — www.lm-sensors.org/attachment/ticket/2133/sensormon
3. lm-monitor — sourceforge.net/projects/lm-monitor

Adaptec RAID

• Используется утилита arcconf (репозиторий с пакетом для Debian, порт для FreeBSD)
• Исходный текст: /usr/local/sbin/aacraid-check (убедитесь, что $PROG внутри содержит правильный путь к arcconf)
• Ежедневный вызов под Linux через /etc/cron.daily/aacraid-check:
  

  /usr/local/sbin/aacraid-check | mail -e -s "Adaptec RAID Alert on $(hostname)" admins

• Ежедневный вызов под FreeBSD через /usr/local/etc/periodic/daily/aacraid-check:
  

  /usr/local/sbin/aacraid-check | mail -E -s "Adaptec RAID Alert on $(hostname)" admins

Другие варианты:

1. quad3datwork — www.sysadmintalk.net/forums/thread-1062.html
2. aacraid-status — hwraid.le-vert.net/wiki/Adaptec#a3.3.aacraid-status

Intel MatrixRAID под FreeBSD

1. Запуск: /usr/local/etc/periodic/daily/raidcheck
2. Код:

   #!/bin/sh
   
   cd /dev
   for n in ar?; do
           test "$n" = 'ar?' && exit  # ..no ATA RAID 
           #echo "Check $n..." 
           atacontrol status $n | egrep -qv '(READY|ONLINE|subdisks:)' || continue
           atacontrol status $n | mail -s 'ATA RAID Warning' admins
           atacontrol status $n | logger -p local4.crit -t RAIDCheck -s
   done
   

OpenVZ

Ежедневная проверка переполнения квот в контейнерах – sources.homelink.ru/openvz

P.S.

На 90% заметка представляет собой копипасту из локальной wiki. Если кому-то пригодится — хорошо. Не пригодится — ничего страшного ;-))