> Support for a cron.d directory is a tool that can be
> used in many ways.

I have used cron.d on other UNIXen, and for package-installed cron jobs I find 
it significantly friendlier, in that it makes these jobs easily identifiable to 
the sysadmin.

As we do it now, the per-user crontabs are quite opaque.  It's easy to get a 
list of the 'logins' that have them, but the best you can do is cat the files 
and hope the entries are well documented or obvious from context.  And editing 
a single file from an installer script is always subject to failure: it's hard 
to guard from failure if somebody comes along and, in the course of manually 
editing the file, upsets the markers the [un]installer scripts are looking for.

Allowing a package to add/rm a self-contained file avoids these accidental 
editing muckups.  And with a simple standardized naming convention, the mapping 
from cron files to packages can be both unique and obvious.  This is a big win 
for the sysadmin trying to track down a mystery run-away cron job.

Some attention must be given to setting things the uid/gid to run under, and it 
might be useful to allow specification of things like the login class, and 
perhaps capsicum capabilities.  Actually, the latter two features are useful in 
the general case.  Regardless, the core idea is both sound and useful.


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to