SUMMARY 2: Allowing non-root access to RM 6.22 commands?

My sleep-deprived brain wishes to apologize to the list for being too
hasty with my summary.  sudo *will*, in fact, work here, if one
changes the permissions of the commands in question back to their
original 744 vice the 4755 that I had set them to before posting.  With
the 744 mode in place and sudo with the NOPASSWD option in /etc/sudoers,
the rmparams.lock issue goes away.

All apologies, and thanks again for the assistance.

On Mon, 27 Aug 2001, at 09:40, Todd Herr wrote:

> It appears that the answer is to change the question...
>
> Several of you suggested sudo, but that doesn't work here, because of
> the /etc/osa/locks/rmparams.lock issue mentioned below.  Also, with
> Big Brother being non-interactive, I'm not sure how to specify the
> bb user's password other than the -S option, which would require that
> the password for bb be stored in the clear in a file somewhere, methinks.
>
> However, a solution here would be that rather than change the commands
> to allow bb to run them, just run them periodically out of root's
> cron, dumping the output to readable files, and have bb parse those
> files.  It's the difference between a script that says:
>
>    $CATCH = `$COMMAND | grep $some_string`
>    if [ ! -z "$CATCH" ] ; then
>      COLOR = "red"
>    fi
>
> and one that says
>
>    $CATCH = `grep $some_string $FILE`
>    if [ ! -z "$CATCH" ] ; then
>      COLOR = "red"
>    fi
>
> Thanks to all respondents.
>
> On Mon, 27 Aug 2001, at 08:21, Todd Herr wrote:
>
> > Greetings,
> >
> > I'm trying to write some scripts for Big Brother to use to monitor some
> > A1000s that I've got in my data center.  Big Brother does not run as
> > root at my installation, and I don't wish to change that if I don't
> > have to.  This causes me a problem here, because I cannot run the
> > commands that I wish to run (lad, raidutil, and healthck) in their
> > current state, because they're all owned by bin:bin with permissions
> > of 744.
> >
> > I've tried to change permissions on these three files to 4755 (setuid,
> > although that's no my favored way of doing things), but that didn't do
> > me any good, as I got this in response:
> >
> >   No definition for parameter System_RmHomeDirectory - aborting
> >
> > System_RmHomeDirectory is a parameter defined in the rmparams file,
> > which is readable to a regular user just by cat'ing the file; however,
> > running truss on lad shows that it's trying to read the
> > /etc/osa/locks/rmparams.lock file, and *that* file is owned by
> > root:root, mode 600.  I'm concerned about changing that file's
> > permissions and ownership, as I can't find anything documented about
> > it.  It seems to get created at boot time, and since these are
> > production boxes, I don't want to monkey around with that file.
> >
> > Has anyone faced this problem before, and what have you done to solve
> > it?
> >
> > Thanks!
> >
> >
>
>

-- 
Todd Herr                                         todd@angrysunguy.com