> > 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.