Table of Contents for

Linux Essentials for Cybersecurity, First Edition

Chapter 16 Common Automation Tasks

After exploring crontab and scripting in Chapter 14, “Crontab and At,” and Chapter 15, “Scripting,” you now have the tools to automate! Most likely you are now thinking “OK, but what will I automate?” This chapter explores some common automation use cases and provides demonstration scripts and crontab entries.

After reading this chapter and completing the exercises, you will be able to do the following:

Plan common automation tasks

Exploring Scripts that Already Exist on Your System

To start, there is some good news: you have many examples of Linux automation already available on your system that you can use to model your own solutions. You just need to know where to look.

The /etc/cron.* Directories

Recall in Chapter 14 that several directories contain scripts that are run on a regular schedule:

•     /etc/cron.hourly: Contains programs that will be executed once per hour

•     /etc/cron.daily: Contains programs that will be executed once per day

•     /etc/cron.weekly: Contains programs that will be executed once per week

•     /etc/cron.monthly: Contains programs that will be executed once per month

This means that on your system you already have examples of automation. What exactly you have in these directories will depend on what software you have installed. For example, consider the following output from a Fedora system:

[root@onecoursesource cron.daily]# ls -l
total 20
-rwxr-xr-x 1 root root 180 Aug  1  2012 logrotate
-rwxr-xr-x 1 root root 618 Nov 13  2014 man-db.cron
-rwxr-x--- 1 root root 192 Aug  3  2013 mlocate

These three scripts perform specific tasks that are designed to promote the health and security of the distribution. What do these do? To determine that, you just need to read the scripts.

logrotate

Review the logrotate script (note that the nl command displays a file with a number at the beginning of each line):

[root@onecoursesource cron.daily]#nl -ba logrotate
     1  #!/bin/sh
     2
     3  /usr/sbin/logrotate /etc/logrotate.conf
     4  EXITVALUE=$?
     5  if [ $EXITVALUE != 0 ]; then
     6      /usr/bin/logger -t logrotate "ALERT exited abnormally
     7  fi
     8  exit 0

From Line 1, you can tell this is a BASH script (/bin/sh is a symbolic link to /bin/bash).

Line 3 is executing the /usr/sbin/logrotate program. To determine what sort of program this is, use the file command:

[root@onecoursesource cron.daily]#file /usr/sbin/logrotate
/usr/sbin/logrotate: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=21ac008a2855900ed1819a1fb6c551c54a84a49f, stripped

Since the output of the file command does not indicate that this is a text file, you should not look at it directly. However, given that it is located in the /usr/sbin directory, it likely has a man page. After executing man logrotate, you can see that this command’s function “… rotates, compresses, and mails system logs,” and if you look at the SYNOPSIS section of the man page, you will discover that the argument to the logrotate command is its configuration file:

logrotate [-dv] [-f|--force] [-s|--state file] config_file ..

Note that we will discuss the logrotate command in more depth in Chapter 25, “System Logging,” when we discuss system logs. The purpose of this discussion is to gather ideas of what sort of automation processes can be created to better service the system. The first paragraph of the DESCRIPTION of the man page provides an excellent reason for this command to be executed daily:

“logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large.”

But what about the rest of the script? Line 4 introduces something new that you have not learned about BASH scripting yet: when a command or program finishes execution, it will return an exit status value to the calling program. This is a numeric value that is 0 if the command executed successfully and a positive value if the command failed. This exit status value is stored in the $? variable.

Line 4 stores this value in a new variable called EXITVALUE, and line 5 contains code that you should already understand from topics that were discussed in Chapter 15. The if statement determines if the EXITVALUE is not 0, and if it is not 0, then the logger command will execute. What does the logger command do?

Again, consult the man page: “logger makes entries in the system log.” So, if the logrotate command fails, then the logger utility will create an entry about this failure.

Line 8 just exits the script with a “success” return value of 0.

man-db.cron

This script is a bit larger, so not every line will be examined, and the grep command is used to filter out comment lines and blank lines:

[root@onecoursesource cron.daily]#grep -v "^#" man-db.cron | grep -v "^$" | nl
     1  if [ -e /etc/sysconfig/man-db ]; then
     2      . /etc/sysconfig/man-db
     3  fi
     4  if [ "$CRON" = "no" ]; then
     5     exit 0
     6  fi
     7  renice +19 -p $$ >/dev/null 2>&1
     8  ionice -c3 -p $$ >/dev/null 2>&1
     9  LOCKFILE=/var/lock/man-db.lock
    10  [[ -f $LOCKFILE ]] && exit 0
    11  trap "{ rm -f $LOCKFILE ; exit 0; }" EXIT
    12  touch $LOCKFILE
    13  mandb $OPTS
    14  exit 0

Lines 1–3 make use of a feature called sourcing. If the /etc/sysconfig/man-db file exists, it is executed as if the code from that file was embedded within this script. This is typically used to import variables from an external file.

Lines 4–12 perform some setup tasks that are necessary for the command on Line 13 to run correctly. Most of these lines are straightforward (Line 9 creates a variable, Line 12 creates a file, and so on). Some commands, like the renice command, will be covered in later chapters.

Line 13 is the heart of this script. According to the man page, the mandb command (described as %mandb% in the man page) performs the following:

“%mandb% is used to initialiseor manually update index database caches that are usually maintained by %man%. The caches contain information relevant to the current state of the manual page system and the information stored within them is used by the man-db utilities to enhance their speed and functionality.”

Why is this useful? As you add and update software to the system, new man pages are introduced. By executing this command automatically on a daily basis, the functionality of the man page is optimized.

mlocate

In Chapter 2, “Working on the Command Line,” you were introduced to the find command, which is used to search the live filesystem for files based on filename, ownership, permissions, and other file metadata. In addition to the find command is a command called locate that also looks for files:

[root@onecoursesource cron.daily]#locate motd
/etc/motd
/extract/etc/motd
/usr/lib64/security/pam_motd.so
/usr/libexec/usermin/caldera/motd
/usr/libexec/usermin/caldera/motd/images
/usr/libexec/usermin/caldera/motd/images/icon.gif
/usr/libexec/webmin/pam/pam_motd.so.pl
/usr/share/doc/pam/html/sag-pam_motd.html
/usr/share/doc/pam/txts/README.pam_motd
/usr/share/man/man8/pam_motd.8.gz

There are several differences between the find and locate commands, but the biggest difference is that the locate command doesn’t search the live filesystem, but rather searches from a database that is generated automatically daily. This makes the locate command faster than the find command because searching the live filesystem is more time consuming.

How does the database that the locate command uses generated daily? As you can probably guess by now, it is the mlocate script:

[root@onecoursesource cron.daily]#nl -ba mlocate
     1  #!/bin/sh
     2  nodevs=$(< /proc/filesystems awk '$1 == "nodev" && $2 != "rootfs" 
{ print $2 }')
     3  renice +19 -p $$ >/dev/null 2>&1
     4  ionice -c2 -n7 -p $$ >/dev/null 2>&1
     5  /usr/bin/updatedb -f "$nodevs"

Try to read this one on your own. Here are some hints:

•     You learned about the $() feature in Chapter 15.

•     The code inside $() is a bit tricky. However, you can just run Line 2 in a standard BASH shell and then look at the value of the nodevs variable.

•     The man pages will help you with the renice, ionice, and updatedb commands. It is the updatedb command that actually creates the database that is used by the locate command.

Before continuing to the next section in this chapter, consider looking for and reading more scripts in the /etc/cron.daily, /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly directories. The more you explore, the better you will understand automation.

Repositories

A repository, in coding terms, is a location where people share programs. You should consider exploring several BASH shell repositories, including the following:

•     Daniel E. Singer’s Scripts: ftp://ftp.cs.duke.edu/pub/des/scripts/INDEX.html

•     John Chambers' directory of useful tools: http://trillian.mit.edu/~jc/sh/

•     Cameron Simpson's Scripts: https://cskk.ezoshosting.com/cs/css/

•     Carlos J. G. Duarte’s Scripts: http://cgd.sdf-eu.org/a_scripts.html

Not only will exploring these repositories provide you with access to useful scripts (and not just BASH scripts), but we have found that this practice also serves to ignite your imagination to help you create your own automation scripts.

Creating Your Own Automation Scripts

The process of creating your own automation scripts may seem daunting at first, but after you take the time to explore existing examples, it will come easier to you. The following are just a few suggestions when creating your scripts:

•     Pay attention to tasks that you routinely perform. If you find yourself executing the same or a similar set of commands over and over, then automating these commands with a script makes sense.

•     Is there a command that takes a lot of time on the system? How about one that uses a lot of system resources (memory, CPU, network bandwidth, and so on)? Maybe that command should be executed via a cron or at job in the middle of the night when nobody is on the system.

•     Do you find that other users in your organization struggle with complex command-line utilities? You can create an interactive script that prompts the user to answer questions and then executes the correct command with all those complicated options for the user who runs your script.

•     Need to run a critical security audit on a regular basis? Make that audit into a script and add it to the system crontab file.

•     Are people forgetting to attend your important weekly meeting? Make a script that automatically generates a reminder email 10 minutes before the meeting.

•     Want to know who is logged into the system on Friday at 8 p.m.? Make a cron job that runs the who command and mails a message to you.

•     Forget to routinely update software on the system? Make that a cron job, and you do not need to worry about it anymore.

•     Do you regularly back up your files, or do you find yourself days in the future when realize you should have made a backup and now it is too late because the system has crashed or someone has overwritten your file? Put together a better backup policy.

Sounds like a large list of tasks, but in the big picture, this is small potatoes. The possibilities of how you can automate your system are practically endless.

Summary

Knowing how to create automated processes is just half the battle. Knowing what you should automate is the other half. In this chapter, we explored some ideas and concepts that are designed to assist you in determining what tasks you should automate on your system.

Key Terms

Exit status

sourcing

repository

Review Questions

1.    The _____ script rotates, compresses, and mails system logs.

2.    Which directories contain scripts that execute on a regular basis? (Choose two.)

a.    /etc/cron.d

b.    /etc/crond.minutely

c.    /etc/cron.daily

d.    /etc/cron.hourly

3.    Which variable is used to store the exit status of a command?

a.    $!

b.    $$

c.    $^

d.    $?

4.    The _____ command displays files, including line numbers.

5.    In coding terms, a _____ is a location where people share programs.