> We just converted to TSM 4.2.1.9 from NetBackup. We are finding that our
> group needs to be able to stop the TSM daemons and start the start up
> script, instead of always having the system admin. do this. Right now I am
> told that there is no work around for root privileges being needed to kill
> the TSM daemons. I'm wondering how other shops get around this problem? When
> our TSM server crashes, all of the clients that are getting backed up are
> getting hung schedulers and need to be bounced to resume working. The fact
> that root privileges are needed to bounce the daemons is adding on days to
> our resolution, since we have to open a problem ticket with the system
> admin. group and wait for them to bounce the daemons. We have ids on most of
> the unix servers and could do it, if the permissions allowed.
>
> Any ideas?? Do any of you have a work around for this problem? Tivoli had me
> open an enhancement request.

I either have root access or can get reasonably quick responses from
administrators on all of my site's TSM client system. If I were in your
position I would have the administrators install a perl or shell script
that would kill any running 'dsmc sched' process and start a new one.

The administrators would have to do one of two things with the script:

1.Make the script root owned, executable by your ID, and SUID.

2.Write a small (six lines or less, depending on one's white space
conventions) C program that uses the 'execv' function to run the script,
compile the program, and make the object code root owned, executable by
your ID, and SUID.

The SUID attribute causes an executable file to run with the authority of
its owner rather than the authority of the person invoking the program.
Many UNIX implementations still have an ancient bug that makes a script
with the SUID attribute a serious security exposure. If your client systems
have this bug you will need the second approach despite its additional
complexity.