Sysadmins (and lesser mortals) use cron to schedule regular jobs on servers for all sorts of tasks including backups. Since it can be a pain to log into each server to ensure that these scheduled jobs are running correctly days, weeks or even months after the jobs were first created, you can opt to receive notifications of the success or failure of these jobs by email.
In order to send emails, cron relies on sendmail. In the past, sendmail was pre-installed on (Linux) servers. Nowadays, it is not generally installed and postfix is used instead. If you don’t have postfix running locally or you need to route your emails through an alternate relay then the following information should be helpful for you.
For my recently provisioned mailserver, I am running postfix in a dockerised environment where the mail ports (25, 587 etc) are bound to the static IP of the server and not the loopback ip of 127.0.0.1
. In addition, not having postfix installed as a local service meant that no sendmail replacement using postfix was installed either. This prevents cron from being able to send emails.
Sendmail Replacement
My solution to this problem was to install msmtp which is a lightweight replacement for sendmail which can queue and forward emails to any mailserver including my containerised postfix instance.
Installation on Ubuntu is as simple as
$ sudo apt-get -y install msmtp
After installing msmtp, you need to add a configuration file for it to use; this can be a global file /etc/msmtprc
or user specific file ~/.msmtprc
for each user that needs to send email.
This configuration file allows you to define the ports and protocols to support and what other mail servers to relay emails through.
Configuring msmtp
Since I want msmtp to relay through my postfix server, I created the following entries in ~/.msmtprc
for the root account which is the account under which my server’s cron jobs run.
defaults
auth on
tls on
tls_starttls on
logfile /var/log/msmtp
# not sure I actually need the aliases entry below but added it anyway
aliases /etc/aliases
# create one of these for each mailserver you intend to relay through
account mailrelay
host mail.mydomain.com
port 587
from admin-user@mydomain.com
auth on
user admin-user@mydomain.com
password PASSWORD-FOR-THE-USER-ABOVE
account default : mailrelay
This configuration defines a default relay called mailrelay
which requires msmtp to connect to mail.mydomain.com
over the secure port 587 using the user admin-user@mydomain.com
and the (cleartext) password PASSWORD-FOR-THE-USER-ABOVE
. These settings match the email account to use for relaying (on the postfix server).
Having passwords in cleartext is never a great idea but for this setup it is good enough, as a breach requires someone to gain root access before being able to send emails from my server.
Important Make sure that the you have a matching host entry for your mailserver (eg mail.mydomain.com
) in your /etc/hosts
file.
Sending Emails from cron
In order to send emails from cron you need a MAILTO=
directive as shown in the crontab below.
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
MAILTO=admin-user@mydomain.com
# Daily backup
30 5 * * * /mailu/daily_backup 2>&1
# Weekly backup every Sunday at 6am
0 6 * * 0 /mailu/weekly_backup 2>&1
Adding the MAILTO=
directive means that you should receive an email for any job that runs with a full log from your script; regardless of whether it completed successfully or failed to execute properly.
The directive 30 5 * * * /mailu/daily_backup 2>&1
means execute the /mailu/daily_backup
script every day at 5:30AM and pipe stdout and stderr together into the body of the email.
The output from all jobs defined in the crontab will also be sent as emails unless you explicity set the output for a specific job to /dev/null
.
Wrap up
As long as you review these cron output emails regularly, you should have good insight on how the jobs on your server are working, and gain some extra peace of mind.