[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SAGE] crontabs vs /etc/cron.[daily,hourly,*] vs. /etc/cron.d/

In our environments that have not yet been transitioned to better centralised batch control tools (we're working towards eventually eliminating cron entirely), we have 'generic' user accounts that are accessible only via sudo that contain cron jobs for specific application areas. This gives us user-level security (users can't run jobs as root or any other user) and accountability (sudo logs tell us who's messing with the generic accounts) while still being able to delegate responsibility to application teams. It does mean that applications support people can (and occasionally do) mess up a crontab, but it doesn't happen often because they're generally careful - and know that we have the logs. :-)
Individual users can create crontabs of their own on many of the shared-resource machines in the Engineering environment, but not on most of the Corporate servers. They can also create them on their desktops or laptops. These policies are getting tighter over time.
'System' crons still run either from root's crontab or the /etc/cron* directories, depending on the OS.
It's a compromise that generally works for the thousands of servers and tens of thousands of desktops/laptops that run Unix/Linux in our environment. Eventually eliminating cron on all of the servers in the data centres is our goal to provide better reliability, control, monitoring, and accountability.
Desktops aren't such an issue for us and may stay with cron, but that will be an issue for our desktop services and OS support people to decide. 

- Richard


Adam Moskowitz wrote:

"Gary Richardson" <gary.richardson@xxxxxxxxx> wrote:

I think the per user crontabs should be avoided. . . . I'm sure we've all
had instances where critical crontabs stop running after an account is
disabled when an employee leaves.


While I tend to agree that, for "operational" processes, user crontabs
should be avoided, I do not agree with Gary's reasoning. Having a critical
process run out of an individual user's crontab is bad, this is not a
technical problem and does not require a technical solution. In other
words, even if user crontabs are available, don't use them for
operational processes, document that such use is prohibited, and enforce
this via managerial means.

In situations where even sysadmins shouldn't be running cron jobs on
production systems then there's probably no good reason for even
providing user crontabs. However, in lots of other situations, giving
users (sysadmins and others) access to cron for their personal use is
often a valuable thing. I don't think this should be prohibited simply
because some people abuse the mechanism.

In other words, abuse should not dictate (or deny) use.

AdamM