Centralize Your Crontabs

Richard Hellier

This article presents a way of centralizing the administration of cron by using NIS (Network Information Service) and may be helpful for systems administrators working with a large number of systems and users and services that need local crontab entries.

The Problem

In large-scale installations, the usual approach is to make all the UNIX workstations be clones, meaning each machine is logically the same as any other. Such cloning is usually achieved by technologies such as Sun's JumpStart or HP's Instant Ignition. Installing machines this way makes them field replaceable so that if a disk or processor fails, a spare can replace the machine with no loss of data.

In my environment, we install machines using JumpStart and then apply a rule specifying no client-side tailoring. In other words, once a machine is installed, we try as hard as possible to avoid applying any customizations to it. Allowing such customizations means an additional burden in recording, backups, incorporation into DR plans, etc. However, one of the main rule breakers is the cron program since the crontab files (the "diaries") must reside on the machine where cron runs.

Restricting the use of cron (at least to non-privileged users) to a small number of machines, perhaps just one or two, can alleviate this problem. The administration of these cron servers gives more "bang for the buck" than dealing with each workstation individually. Sadly, centralizing cron in this way is, at best, a halfway house and doesn't handle cases where the presence of special devices or other constraints make a local crontab entry essential.

The Solution

The solution adopted here is to add a new NIS map, crontab.byname, to the normal set (hosts, passwd, etc). The source file for the NIS map (i.e., the file /etc/crontab.conf on the NIS master), looks like:

lonws28         root:30 7 * * * /foo/bar/somecmd
loncs50         sys:5,35 * * * * /foo/bar/othercmd
lonws59 root:0 0 * * * /usr/bin/touch /tmp/foo// \
        uucp:2 2 * * * /usr/bin/touch /tmp/baz%%5 5 \
        * * * /usr/bin/touch
/tmp/quux

Each (logical) line of the file contains all the crontab entries to be run on the machine named on the left-hand side. The right-hand side (RHS) of each line is a list of crontab entries for different users within that machine. As usual, "long" lines can be broken by escaping the newlines with a backslash character. Entries for different users are separated with the sequence %%. Although you could argue about the syntax, the one provided here works fine. The file /var/yp/Makefile is augmented in the usual way to build the crontab.byname map along with all the others.

What happens on the client side? At installation time, a shell script is installed along with an entry in root's crontab that runs the script every few minutes. When the script runs (Listing 1), it removes any existing crontab entries that came via NIS, which are easy to find since they are bracketed by the following lines:

#NISCRON-START
#NISCRON-END

Next, the script uses the ypmatch command with the hostname as the key to look up its entry in the crontab.byname map. If a match is found, the crontabs for all users appearing in the entry are updated. The same is then done using * as the key, which gives a simple way to have cron entries run on all machines.

Thereafter, placing, altering, or removing a crontab entry is simply a matter of editing /etc/crontab.conf on the NIS master, and rebuilding the NIS map. At the end of the next update interval, all the necessary updates occur. This mechanism is especially convenient for transferring a crontab entry from one machine to another or for setting up identical entries on many machines. Note that "down" machines behave correctly when they next restart.

Summary

A scheme for centralizing the administration of cron has been presented here. By using this scheme, client workstations remain "field-replaceable" while still allowing the effect of client-side tailoring because a machine replaced by a spare with the same name will automatically "inherit" the correct crontab entries. If the new machine is not able to have the same name, the entries will be "inherited" when the NIS map is updated. Although the article describes the use of NIS, other tools such as NISplus could use the same method.

Further Work

To achieve the same effect with even less overhead, it would be good if cron were to become "NIS-aware". That is, if the file /etc/nsswitch.conf included cron as one of the services that can be "vectored", then "local" crontabs could run directly from the NIS map -- well, maybe some day!

Richard Hellier has been around UNIX systems since 1976, first as a user, then a software developer, and most recently as an administrator. He is part of a team that manages the UNIX machines in the European offices of LSI Logic. He can be contacted at: rlh@lsil.com.