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.b