Setting up email alerts for various system events

This article lists a few simple ways to learn in advance about various problems on the server, without littering your mailbox or setting up complex monitoring systems. From the category "if you are too lazy to check and tune something, then set up and check at least that."

Some of the utilities listed below can send email notifications on their own, simple shell wrappers are offered for the rest.

As a recipient, an additional local admins mailing is used, which includes the local root and external admin@example.ru. Why is local root not overridden instead?

First, by default, root can receive a lot of newsletters that help __ understand the reason for a problem that has already been discovered. They are important, but if you send all these letters to the outside, you either need to set up their filtering, or you are more likely to skip letters in their stream, allowing you to __to discover another _ unknown problem.
')
Secondly, because admins is not a standard account or group in popular Linux / Unix systems, then " grep -r admins /etc /usr/local/etc allows you to quickly determine which utilities have been configured for.

Mail Server Setup

Determining the server to use:

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

Possible options in Debian and Ubuntu: http://packages.debian.org/file:/usr/sbin/sendmail

Further, all the paths and command keys are based on Debian, except for the utilities for FreeBSD that are missing from 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

Full minimum 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

Formal advantages compared with a full MTA:

1. do not occupy space in ram,
2. easier to set up
3. less vulnerable because work with the rights of the calling user and do not accept network connections.

Actual deficiencies:

1. if at the moment of sending the letter for some reason there is no connection with the external SMTP server, or the SMTP server refused to accept it, the letter will disappear,
2. Recipient addresses are sometimes formed according to such strange rules that the SMTP server is unable to correctly determine to whom and where it should be delivered,
3. see above root @ redirection considerations

Thus, the only place where imho makes sense to use them is lightweight virtual containers, for forwarding to an SMTP server running on Host OS.

Setting up monitoring services

Turn on server

Even some such administrators will learn about such an important event as unplanned reboots by accidentally checking uptime or last. The following line above “exit” in /etc/rc.local will help you to be immediately informed about the events:

 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

Full minimum smartd.conf:
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

lm_sensors

1. Run from rc.local: /usr/local/sbin/healthd.sh &
2. Healthd.sh code:
   

    #!/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 

Other options:

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

• Uses arcconf utility ( repository with package for Debian , port for FreeBSD )
• Source text: / usr / local / sbin / aacraid-check (make sure that $ PROG inside contains the correct path to arcconf )
• Daily Linux Call via /etc/cron.daily/aacraid-check:
  

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

• Daily call under FreeBSD via / usr / local / etc / periodic / daily / aacraid-check:
  

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

Other options:

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

Intel MatrixRAID under FreeBSD

1. Run: / usr / local / etc / periodic / daily / raidcheck
2. Code:

    #!/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

Daily check of quota overflow in containers - sources.homelink.ru/openvz

PS

90% of the note is a copy-paste from the local wiki. If someone comes in handy - well. Not useful - nothing terrible ;-))