Crontab

[Roy Schauwecker]

Relative newbie here, so be gentle.

Management has decided that they want to take crontab away from the general population. Basically they want to lock it down to get a better handle on the usage. If a developer wants to create a crontab entry, they would be forced to submit a request describing the entry and then be granted temporary access to an ID in order to make their crontab entry. various groups within the organization would have a specific ID and all entries would then be made using this ID. I'm the lucky guy that gets to figure our how to implement this.

This is basically what I have in my head regarding this process.

1)remove IDs from cron.allow
2)create new common group IDs for users
3)consolidate existing crontab files under this common ID
4)Users submits request for a password to the account.
5)Password is reset when completed.

Any coments on this are greatly appreciated. Is this the best method of acheiving the goal? What about security and permissions?...any recommendations? I've read other forum entries mentioning "batch processing" software being used(Maestro, Autosys, Control -m). Any recommendations there?

Side note: As a newbie system administrator, I just wanted to let you know that this forum is absolutely outstanding. It's the first place that I come to look for answers. Great job!

[Patrick Wallek]

I don't particularly like this idea.

Are all the jobs that are going to be run going to run from these ID's only? IE, are you going to have an ora_cron id that will have to run jobs as the oracle id? If so, how are you planning on doing that? There really is not an easy way to go about it. You would have a hard time doing an 'su - oracle' from the ora_cron user since it would ask you for a password. I guess you dould utilize something like expect to get around this.

If you are really this concerned about, I would look into using something like Maestro (now IBM Tivoli Workload Scheduler or TWS) or Autosys.

With TWS, when you define a job and it's schedule, you can specify what user that job should run as. You also can keep control on who can set up jobs, monitor the jobs, etc. TWS has a fairly nice java interface that you can install on a PC to monitor jobs, set up jobs, etc.

Something like Maestro / TWS would be my preferred route for this. I think it would be really difficult for you if you tried to use cron.

[James R. Ferguson]

Hi:

If you're stuck with this dictate, don't forget to consider the 'at' and 'batch' commands too.

Users are permitted to use 'at' and 'batch' when their user name appears in '/usr/lib/cron/at.allow'. If this file does not exist, then users can use 'at' and 'batch' if their names don't appear in '/usr/lib/cron/at.deny'. If neither file exists, only root is allowed to submit jobs. If only an empty 'at.deny' exists, then all users can use 'at' and 'batch'.

Regards!

...JRF...

[Kent Ostby]

I'm not sure how exactly you are using the term "Group ID" in this context, but just to clarify that cron is based on users in the /etc/password file not groups listed in the /etc/group file.

So if you have a team of engineers for the database, you'd have to add a user called "dbteam" to /etc/password not just create a group in /etc/group that they could belong to.

The issues listed by some other responders related to how having new IDs might effect the complexity and running of the scripts as well (e.g. having to su - to the oracle user).

Best regards,

Kent M. Ostby

[Mark Greene_1]

The first thing I would do is go back and tell Management that Unix is not Windows, and you cannot administrate them the same way.

The short answer is that you have two options for doing this: create a "generic" user ID that is really SUID 0, and in effect, root. This is not exactly secure, and may or may not play well with your software or database applications.

The second option is to install sudo and create a special account which has permission via sudo to run specific commands and scripts as root. The catch here being that this is not just limited to running these commands and scripts via cron, so you need extra security on this ID (like not allowing remote logins and not sharing the password).

What your management really wants is Change Control. Implementing it way down the stream at the batch scheduler level is going to be problematic and counterproductive.

Good luck with it

mark

[Roy Schauwecker]

Thanks for the replies. Yes, It looks like I will be making it so. I'm still trying to convince them that some scheduling software would be the way to go. After reviewing the existing cron jobs and the associated IDs, it may not be as ugly as first feared. They appear to have been using a common ID in each of the different departments. I was worried about many, many different IDs. They've taken care of the consolidation issue by using the common ID. It really has turned into little more than changing their password and granting them access as needed. Of course, that could be the beginning of an entirely new nightmare.

James, thanks for the heads up on 'at' & 'batch'.

Best Regards,

Roy

[Michael Tully · Accepted solution]

Just as a suggestion. I would make sure that these particular user ID's are tied just a little, making them 'su' accounts only. That way there is an entry in the /var/adm/su.log and /var/adm/syslog/syslog.log file so you can trace who has actually signed in, if there are boo boo's.