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.

Cron 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.