> 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. --lyndon _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
