|
Please don’t take this the wrong way, but does your organization
have a set of written Policies & Procedures? They should be codified so
that all members of your staff know how you organize and maintain your servers.
I know that this is a big Duh, but this would include the use of cron. That way
everybody would know where things are and can maintain them properly. As you
said, one way is never used by the majority of your staff. One person deviated
from what the rest of the staff did. If this person could not do it any other
way, then it should have been documented and put into an Operations manual
(along with all the other cron jobs). For instance, we here use root’s
crontab almost exclusively. However, 1 process needed to be run from the
software manufacturer’s login’s crontab. This was documented and
put into the Operations manual so that Operations, and any of the Development
staff, will know what job was sending them E-Mail (E-Mails were sent to
specific people from this job letting them know the results of the job’s
execution) and why. Just a thought. Art
If you take the road less traveled, just make sure it isn't
on the critical path. (Elisabeth Hendrickson) I do not fear computers. I fear the lack of them.
(Isaac
Asimov) Walking on water and developing software from a
specification are easy if both are frozen. (Edward V Berard) If you cannot grok the overall structure of a program while
taking a shower, you are not ready to code it. (Richard Pattis) -----Original Message----- So, we have an internal debate at Puryear IT about how to best setup cronjobs. First, let's assume Linux here. Every UNIX flavor has some unique trick it likes to use, but Linux is a good example of several ways to do cronjobs. So, with most Linux installs, you have these options: 1. normal use of crontabs 2. creating a crontab-like entry in a file in /etc/cron.d/ 3. creating symlinks to your scripts in /etc/cron.hourly/, /etc/cron.daily/, etc. (I'll just say /etc/cron.daily to be short.) 4. /etc/crontab for the root user being able to run cron jobs as any user, unlike /etc/cron.d/ and /etc/cron.daily/. The question here isn't one of technical correctness (they are all correct), but one of consistency both internally and, potentially, with other people messing with cronjobs on the same box. The debate started when I logged into a server and didn't see our jobs in root's crontab or as symlink under /etc/cron.daily/. They were in /etc/cron.d/. Fine. Except I never do that. I usually use a user's crontab or /etc/cron.daily/. So, immediately, we have a internal consistency issue, which could, conceivably, cause me to create a duplicate cronjob. (Let's ignore documentation and change management.) The problem I have with /etc/cron.d/ is that most people DON'T USE IT. Sure, system scripts that come with the distro often do, but, really, how many sysadmins create their cronjobs there? Not many in my experience. Yet, there is a certain cleanness to /etc/cron.d/. :) /etc/crontab has the unique benefit of letting centralize your
cronjobs, but then you have a single file that everyone has to muck with. Yuck. Oh, and trouble.. So, what are your thoughts? How do you handle this? -- Puryear Information Technology, LLC http://www.puryear-it.com Author, "Best Practices for Managing Linux and UNIX Servers" http://www.puryear-it.com/pubs/linux-unix-best-practices Identity Management, LDAP, and Linux Integration | ||||||||||