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.
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
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.
The first example will change syslog.conf and restart syslog.d
on all client computers (all client computers use the same syslog.conf
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:
cp /nfs/syslog.conf /etc/syslog.conf
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
5. Delete the lines just added to /nfs/client_30.sh after
they run so they won't run again.
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
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:
/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.
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:
case "$HOST_NAME" in
eng1 | eng2)
put commands for computer eng1 and eng2 here...
put commands for computers whose hostname starts with market here...
put commands for all other computers here...
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.