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.
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
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
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),
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
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:
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.
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.
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: email@example.com.