The startup script sets a couple variables, so as long as those are set, I think you could run the /usr/nsh/br/blappserv directly as bladmin, as it's called in the startup script.
or you could use sudo and grant your admins the ability to just run the start/stop on the script...
or you could allow this access via nsh so the admins could run something like "nexec
sh -c "/etc/init.d/blappserv start"
or, in the tools | infrastructure management menu in the bladelogic gui, starting from 7.6 and up you can restart the services that way.
I think the first option would suit our needs best (not needing to provide root access or setup sudo)
Sudo will be the next best route if for some reason we cannot get them to run correctly using the bladmin account.
The last two options work except in cases where we have database changes that require downtime and all the app servers will be unavailable.
These are the variables that are set at the beginning of the startup script:
Is there any reason that bladmin wouldn't be able to set these to its own environment? Or are you saying these need to be set to root's environment (global)?
the issue w/ #1 will be you need to remove or re-work the install scripts so they can only run as bladmin (otherwise you'll wreck your permissions if you accidentially start it as root).
bladmin can set them in their own env, but you may have to do that in the .bash_profile or something if it's not already.
if you can do sudo that would be alot better since it means less hacking up of the application...
Are you saying that there would be a problem using the startup scripts if root owned the process? Even if the scripts still allow world execute access after root runs it (accidentally)?
These are how the permissions are setup with root running the scripts now:
-rwxr-xr-x 1 root root 3793 Apr 25 2009 blappserv
-rwxr-xr-x 1 root root 3796 Apr 25 2009 blprocserv
Looks like bladmin would "theoretically" still be able to run these scripts even if root ran it by accident. Or am I missing something?
There's 2 sets of startup scripts:
if you run the 2nd ones as root, your file permissions will get messed up and you won't be able to start the app as bladmin w/o some fixing. so those are the ones to not run as root...
Ok, I just re-read your option 1 and realized you said to run bladmin directly from the /usr/nsh/br directory. It looks like the /etc/init.d script sets up the app server to write to the console logs. If I do startup directly from /usr/nsh/br, will the logs still get written?
no, you will need to take that whole su - bladmin -c from the init script and run that as bladmin.
Is there any reason that we couldn't run the /etc/init.d scripts as bladmin (if it has execute perms)? This way we could ensure the right variables are set and we're still using the default script?
i think it would work, though make sure that whatever is getting written as root by the init script can be written to by bladmin.
I tested this in our dev/test environment. I changed the ownership of all files in /usr/nsh to bladmin and had to modify the init script to remove the su into bladmin, and then started them up with the bladmin account. Everything so far seems to be working as expected. Thanks for your help...!