root batch environment controlm crontab

[Tom Geudens]

Hi,
The Situation :
Crontab is dead, long live Control-M. For good or for bad, we are now running more than 7000 batchjobs (daily) spread over 4 UnixServers. All these jobs are application based and can be executed under special users ... which have very limited environments (scriptdirectory, datadirectory ... and that's about it).

The Problem :
Management keeps nagging me about the fact that there's still several hundreds of jobs submitted from (root) crontab. Why haven't these been converted to Control-M ... I keep telling them that the main problem is that once you make root a Control-M user, about 20 people can (and will) submit whatever they want as root ... So now they've asked me to resolve this problem :-)

The Options :
1. Changing permissions on 20+ softwares so the batchjobs can be executed by the special users. I don't really want to do that ... I like to leave softwares alone.
2. Creating a jail and a root-like user within that jail. For one I haven't found any newbie information that will allow me to do that (chrooted environment ... fun, but how do I create one without bumping into every problem possible). Besides, I won't be able to reach all those softwares from within that jail, or will I ?
3. ???

All help is welcome ...
Tom Geudens

[Steven Sim Kok Leong]

Hi,

Have you tried Restricted SAM? It allows a restricted menu for commands to be executed with another user's privilege (in this case root).

To configure, execute:

# sam -r

The tougher alternative to Restricted SAM would be to write a setuid/setgid program interface.

Since SAM has this functionality built-in, I suggest using it.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Roger Baptiste]

Hi Tom,

(for once) The management is right in this case! ;-) We use controlM too and the policy is to have *all* user application and related jobs to run through controlm.
Only "system related" (i.e root related jobs, system stats gathering, performance stats, pings , dba database check etc) are allowed to run through crontab and that is taken care by adding only root/system users and oracle userid into the crontab allow file.

Now you say, there are already many jobs running through crontab and you want to move it to controlm. I presume these jobs are being
run with the respective user ids of the application owners and not as root!!
The best way to sort the mess is to involve
each application owner group in the process
of moving their cron jobs to controlm.

You can generate the list of jobs which are using crontab on each system (should be a simple vi of each file under the crontab user directory) and send it across to the user groups to identify their jobs and make plans to move it to controlm.

The process may(will) be a pain. But armed with "management" power, you can atleast weild the stick to the users to clean up the act.

<<1. Changing permissions on 20+ softwares so the batchjobs can be executed by the special users. I don't really want to do that ... I like to leave softwares alone. >>

What did you mean by this?? User jobs are run by respective userids . So, where is the need to change any permissions?

<<2. Creating a jail and a root-like user within that jail.>>

????? The idea is to have a control-m user id and that will trigger off all the jobs.
The jobs in turn will run with the respective user ids. If a user wants to schedule/submit a job, he has to give the details to the controlm admin to add it in the list.

I don't handle controlm in my site. We have a special team for that, considering the amount of jobs to be scheduled and handled.
My suggestion would be, if you are newbie, get the management to send you to a couple of days of controlm training or have a dedicated resource handling it, which would be better in the longer run.

HTH
raj

[Tom Geudens]

Hi,
I might not have been exactly clear, but they want me to run those "system related" (which would normally run from the root crontab) jobs in Control-M.
Examples (maybe bad ones but just to get the idea).
30 07 * * 1-5 /opt/prm/bin/prmconfig -k -s -M CPUCAPON >/dev/null 2>&1
00 18 * * 1-5 /opt/prm/bin/prmconfig -k -s -M CPUCAPOFF >/dev/null 2>&1
00 19 * * * /opt/OV/bin/ovstop -c cvmon cvmmon >/dev/null 2>&1
30 05 * * * /opt/OV/bin/ovstart -c cvmon cvmmon >/dev/null 2>&1

In other to run these things from Control-M I either need to use root as a Control-M user or change the permissions on the executables so that non-root Control-M users can execute them. Don't I ???

B.t.w. you may not believe this, but they've already made oracle (for an ex-DBA - and I'm one - this is a superuser as well) a Control-M user. All the backups are running in Control-M. Nobody seems to "see" the problem yet (or if they do, they keep very silent about it :-). I just want to avoid opening the root-door.

Steven, I'm taking a look at the restricted SAM options right now. As soon as I have an idea you'll get points as well ...

Tom Geudens

[Tom Geudens]

Hi Steven,
I'm probably just a little more braindead today than usual :-), but once I define a job in SAM ... and "add" it to a user with the Restricted SAM builder ... how can I then execute this job from the commandline. It does work from SAM itself, but since I have to execute it from Control-M I'll need to execute from the commandline.

Any way to do this ?
Regards,
Tom Geudens

[Steven Sim Kok Leong · Accepted solution]

Hi,

SAM only allows you to run restricted privileged programs in interactive mode from a common user account.

To run such programs in non-interactive mode from the command line, you will need to use sudo.

sudo allows you to remove the password prompt and restrict the privileged programs a common user can run.

Use visudo to edit the configuration file /etc/sudoers.

In the below configuration example, take /bin/su which has been chmod'ed to only executable by root.

# chmod u-s /bin/su
# ls -l /bin/su
-rwxr-xr-x 1 root root 18172 Sep 14 09:16 /bin/su*

In below configuration example, users defined in SYSADMIN can execute SU on all machines without a password. All sudo activities are tracked in /var/adm/syslog/sudo.log.

/etc/sudoers:
==========================================
User_Alias SYSADMIN = joe, doug
Cmnd_Alias SU = /bin/su
SYSADMIN ALL = NOPASSWD: SU
Defaults logfile=/var/adm/syslog/sudo.log, log_year
==========================================

sudo -l lists out the commands that joe can execute as root, and if defined, also other commands ran as another user on the system.

joe> sudo -l
Password:
User joe may run the following commands on this host:
(root) NOPASSWD: /bin/su

Thus, to run su from the command line,

joe> sudo su -

No password will be prompted. Since this is at the command line, you can easily integrate it in cron or Control-M. And because the commands and privileges are restricted in /etc/sudoers, other Control-M users can access only very few privileged programs through joe. They will not be able to access all privileged programs as root since root is not a Control-M user.

sudo for HP-UX can be downloaded from:

ftp://ftp.courtesan.com/pub/sudo

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Tom Geudens]

Hi,
sudo will indeed do the job.
Thanks,
Tom Geudens

[Kim Doty]

What is controlm? I am looking for an alternative to crontab - any others anyone knows of. Any benefits of control-m over cron?

Thanks!
Kim

[Tom Geudens]

Hi Kim,
BMC's Control-M is a cross platform jobscheduler. The main advantage over crontab is that you've got one central point where you schedule all the jobs for as many agents (and these agents can be on practically any platform) as you would like. Furthermore you can put relationships between jobs. Example. 1) You run an offload of data from a database on a Unixserver.
2) You ftp the data to mainframe
3) You sort the data on mainframe
4) You ftp the data to NT
5) You print the data from NT.
If you would want to do this with crontabs (and the equivalents on the other platforms) this could get tricky. Imagine that 1) fails, how would you avoid that 2) starts anyway ? Ok, that would not be impossible in crontab, but how would you avoid 3) starting :-) ? Control-M does all this work for you.

More info on www.bmc.com
Hope this helps,
Tom Geudens