Another Way of Centralizing and Customizing Crontabs

YiHua Philip Sheng

The article "Centralizing Your Crontabs", by Richard Hellier (Sys Admin, November 2001) presented a useful tip for UNIX systems administrators. However, the technique was bit complicated because it involved making an extra NIS map. In this article, I will introduce a simpler method to centralize the management of crontabs without losing customization ability, and I will also provide case examples of utilizing this method.

Why Centralize the Management of Crontabs?

cron is a UNIX facility originally designed to allow users to schedule repetitive tasks, such as file back up, syslog management, etc. If managed well, it also can be used to schedule one-time tasks, such as applying patches or deploying software. Centralized crontabs could let UNIX systems administrators quickly and efficiently broadcast system changes to all client computers.

The Method

In my environment, I use Solaris Jumpstart to install all client computers. In Jumpstart, everything is pre-configured before installation (e.g., hostname, IP address, disk partitioning). Furthermore, Jumpstart lets you customize installation by using rules, begin scripts, and finish scripts. With Jumpstart, a sys admin can quickly and simultaneously install hundreds of client computers without losing customization flexibility.

I wrote a Jumpstart finish script to automatically append the following two lines into the crontab of the user root (/var/spool/cron/crontabs/root) at the end of client installation:

0    1 * * * /nfs/client_daily.sh
0,30 * * * * /nfs/client_30.sh

The /nfs is a network file system (NFS) shared out by a file server and mounted by every client computer. Note that there must be such a NFS in your environment for this method. However, you don't have to use Jumpstart to modify the root's default crontab. If you install your client computer manually or interactively, you may append the two lines above to the root's crontab manually after the installation by issuing the crontab -e root command.

The two lines added to root's crontab of all client computers provide centralized crontab management. The first line tells the client computer (where the crontab resides) to run a Bourne shell script file called client_daily.sh, which is located at the central network file system /nfs, every day at 1:00 am. The second line tells the client computer to run another Bourne shell script, client_30.sh (located at /nfs), every 30 minutes.

Initially, if you don't have anything needing to be pushed to client computers, the two Bourne shell scripts, /nfs/client_daily.sh and /nfs/client_30.sh, are blank. Later, when you need to change something on all or some client computers, you can modify either script file to broadcast the changes to client computers, depending on how urgent your change is. The next section gives two case examples of utilizing these Bourne shell script files.

Example 1

The first example will change syslog.conf and restart syslog.d on all client computers (all client computers use the same syslog.conf file).

1. Copy syslog.conf from a client computer to /nfs/syslog.conf to use it as a sample for modification.

2. Make the necessary changes to /nfs/syslog.conf according to your new logging policy.

3. I would like the change to be effective as soon as possible, so I put the following lines into /nfs/client_30.sh, which will run every half hour on every client computer:

#!/bin/sh
##################
#Copy syslog.conf
##################
cp /nfs/syslog.conf /etc/syslog.conf
/etc/init.d/syslog stop
/etc/init.d/syslog start

4. At the next nearest hour or half hour, all client computers should have run /nfs/client_30.sh at that time interval. If any of the above commands output messages to a standard output device (it is the screen by default), the output messages would be sent as an email to root on the client computer running the script. In my environment, I route all local root email to my own working email account through email aliasing so I can receive the output of the cron jobs on all client computers.

5. Delete the lines just added to /nfs/client_30.sh after they run so they won't run again.

Example 2

Almost all UNIX vendors release patches from time to time. Centralized crontab management can simplify system patching. I use Solaris 8 in this example.

1. Download the patches and untar them into a directory under /nfs.

2. Set the permission on directory patches to be readable to everyone.

3. Create a text file called list, under the directory /nfs/patches, which includes all the patch IDs you are going to apply, one patch ID per line.

4. I would like to patch the system in the night when most systems and networks are idle, so I put the following line into /nfs/client_daily.sh (instead of /nfs/client_30.sh), which will be run at 1:00 am every day:

#!/bin/sh
#################
#Install patches
#################
/usr/sbin/patchadd -M /nfs/patches list

5. Delete the lines just added to /nfs/client_daily.sh on the next day so they won't run again. The patchadd command generates output. Those output messages are sent to the client root as an email. If you route all local root email to your own working email account via email aliasing, you will be able to see whether those patches are successfully applied to all your client computers.

Customization

The case examples above assume that all client computers need the same change, so each of them runs the same script file. However, you may want to make one kind of change to some of the client computers, and a different change to other computers, so you must customize the cron job. You can easily accomplish this customization through the two Bourne script files. The following is an example of how to customize /nfs/client_daily.sh:

#!/bin/sh
####################
#Customized Version
####################
HOST_NAME='uname -n'
case "$HOST_NAME" in
  eng1 | eng2)
put commands for computer eng1 and eng2 here...
    ;;
  market*)
put commands for computers whose hostname starts with market here...
    ;;
  *)
put commands for all other computers here...
;;
esac

Conclusion

Many similar tasks can be done through crontab, such as installation of application software, upgrading or updating certain binaries, and so forth. You could even put a "reboot" command at the end of those Bourne shell scripts, if needed. You also could add commands in the crontab of the user root on the file server, which shares out /nfs system. This would automatically delete or rename either of those two Bourne shell script files so that you don't have to manually delete them after they run.

You should test the commands that you are going to put in /nfs/client_daily.sh or /nfs/client_30.sh. Testing will ensure that the commands in the script file work as you expected. The security issue could be severe if the permission on those two Bourne shell script files is not set properly. Only the root of the file server that shares out the /nfs should have write permission to it.

YiHua Philip Sheng has a Master's of Computer Science and has been in the computer industry for more than ten years. He worked as a university faculty member, a programmer, and the Vice President for Technology of a computer technology consulting company. He is currently working for the Computer Science Department of a university as the UNIX, Windows, Oracle, Web, and Network administrator while pursuing his Ph.D. in MIS.