Starting procs requiring specific user/UID

[Mike_316]

Hey Folks,

Have another one. We would like to use Service Guard to start a processes which are required to be started by specific users. Although setting the SUID might work, our concern is this ...

Currently, these processes are being started manually by "su -"ing to the user (note the "-" which calls the profile) and then running the command. The concern is that different admins control the different accounts, and want to be able to make changes to the profile (paths and such) which may be critical to the process being started WITHOUT having to change anything in Service Guard.

The first option that came to mind was to write a script which "su - "s to the correct user and then runs the command (SG is NOT going to be montioring any of these processes, so it can use a script to start the processes.) HOWEVER, I vaguely recall being able to tell SG to run certain commands as certain users, but I cannot find this in the manuals.

Does SG have the capability to run different commands as different users WITHIN THE SAME PACKAGE...or am I hallucinating?

Thanks!

Mike

[A. Clay Stephenson · Accepted solution]

Your startup commands can use su BUT you DO NOT WANT to use su - to load the .profile. THe problem is that the .profile almost certainly has commands that expect an interactive environment like stty, tset, tabs ... and these puppies are going to hang. The elegant way to do this is to create a file, e.g.
/usr/local/bin/myenv.sh that sets and exports any needed variables. Make sure that there are no returns or exits in this file. Next, you package scripts AND .profiles include this script using 'dot' e.g. . /usr/local/bin/myenv.sh.
That way bith the interactive and non-interactive environments have exactly the same variables and you only need to change them in one place should variables need to be revised in some way.

[Jeff Schussele]

Hi Mike,

Yes & Yes.

In the pkg control file & in the customer_defined_run_cmds function you'd put commands like:

su - user_name1 -c "/path/to/command_to_run"

su - user_name2 -c "/path/to/command_to_run2"

etc.......

We do it here all the time. Works fine.

Rgds,
Jeff

[John Poff]

Hi Mike,

We use MC/SG and we use it to start plenty of processes, mostly Oracle databases, by su'ing to the Oracle user and running a script. It makes it easier for us and our DBAs as SG su's and calls a specific script, which the DBAs own, which allows them to update and maintain the script without requiring any SG changes.

You have a control file for each package, and in that control file you have separate functions for customer defined start and stop functions. You can put most anything you can get away with in a shell script into those functions, and that is where we do things like:

su - someuser /opt/someuser/somescript

Which gives control to someuser and keeps it cleaner for everybody.


JP

[John Palmer]

Hi Mike,

This is nothing unusual, su is the way to go.

Rather than use su - though, what I recommend is that you create a script that sets up your environment and just run this as a 'dot' script in your .profile and by any script that needs it. Then any changes only need to be made in one place.

For instance your environment script is called 'app_env'. In your .profile you just place:
. app_env

In any cron or Serviceguard startup script you can have something like:
. app_env
su -c 'command'

Regards,
John

[Mike_316]

Thanks to everyone! Those were the answers I needed. We have the option of using "su - username commandname" within the SG scripts, as well as writing scripts which parse the ".profile" before starting the item.

One more clarification however, when using the option of "su - username commandname" am I correct in assuming that the "su -" functions as it does from the shell prompt...in other words if a change were made to "username"'s profile, changing the PATH for instance, that change would be reflected when the "commandname" was run. Just as if I was at a command prompt and typed "su - username " and then typed "commandname ".

Is that correct?

Thanks!

Mike

[John Poff]

Mike,

You are correct. The 'su - user' picks up the .profile for that user, so a change in the PATH in the .profile for that user would be picked up. That is part of the beauty of using it, but also part of the danger! :)

JP

[A. Clay Stephenson]

Yes, changing the user's .profile will change the su - behavior but again you really don't want to source .profile (I know that seems to be the easy way) because it is fraught with peril. If the .profile contains commands like tset and stty that can cause the .profile to hang or not work as expected. As I mentioned before the better answer is just a plain vanilla su (w/o the -) to change the user but not source the .profile. BOTH the .profile and your startup commands should source the same file which sets the environment.