No News Might Be Bad News, Here’s How to Keep An Eye On Your Cloud Servers

Last week I told you how someone had a bad scare when they realized that a backup job had failed for almost a year, but they didn’t realize this because the error reports were not being relayed to a responsible person.

Here’s how to fix this!

In any Unix-family operating system, like the Linux systems commonly used on IaaS cloud services like Amazon EC2, Rackspace and others, jobs are scheduled with the cron daemon.

If you haven’t set up a scheduled job before, it can be a little confusing. You use the crontab command with the -e (for Edit) option. That throws you into an editor session, where you are editing a simple configuration file.

Pro Tip: Open a second command prompt window at the same time, so you can read the manual page for crontab in one window while editing in the other window.

Let’s say that you want to run a backup script every night at 3 AM, and run a script that checks your file systems to see if any are getting too full at 6 AM every business day. Something like this would do the trick, assuming you already have the scripts written. Notice that this crontab file starts with a handy comment block:

# Fields are:
#   minute
#   hour
#   day-of-month
#   month
#   day-of-week (0-7, Sunday is 0 or 7)
#   command
0 3 *   * * /usr/local/bin/run-backup
0 6 * 1-5 * /usr/local/bin/check-file-systems

In order to do things like backup file systems, you will have to configure the above as root.

Here is where things often go wrong.

After the first struggle of writing (and debugging!) those scripts, and then the struggle to get the crontab entry correct, many people are glad that the job is over and move on.

But the job is not yet finished.

All output of cron jobs, including error messages, is mailed to the job’s owner. That means that it will be delivered to root on that machine. But it probably never occurs to you to become root on that cloud server and run the mail command.

Edit the file /etc/aliases (which some distributions store as /etc/mail/aliases), and notice what it does. Mail to a bunch of system-type accounts is directed to root.

Go down to the bottom of the file and add something that looks like this. The ec2-user account exists on the Amazon Linux image, change and add to this list as appropriate:

## Relay mail to a responsible person
root:       yourlogin@yourcompany.com
ec2-user:   yourlogin@yourcompany.com

Then run the command newaliases to rebuild the mail alias database from the human-friendly file you just edited. Now verify that cron job output appears in your mailbox!

Pro Tip: Schedule a cron job for 5 minutes from now running:
echo 'This is a test.'

In Learning Tree’s Cloud Security Essentials course we discuss how IaaS cloud services offer a better chance of achieving compliance, as you retain control and visibility. You have to do some tedious system administration work, but you receive evidence that the neccesary work is happening.

Bob Cromwell

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.