Best way to reset server environment variables? #2458

ikotlova · 1 decade ago

Hello,

I am running QB server on CentOS 6.3 under local system account. I.e. RUN_AS_USER is not set in server.sh. As a result I cannot affect QB server environment variables: updating /etc/profile, /etc/profile.d/quickbuild.sh, /root/.profile, ... does not work. The PATH environment variable needs to be reset and include /opt/bullseye/bin location. What would be the best way to do it?

Alternatively I could set BULLSEYE_HOME user attribute and then use it in the code. But that would need updating the code for every Bullseye invocation.

Thanks!
Irina

replies 25
views 8099
stars 0

robinshen ADMIN · 1 decade ago

Please edit server start script (/etc/init.d/quickbuild, or other variations depending on your system) to add the environment to see if it works?

ikotlova · 1 decade ago

Putting the code into server.sh certainly works. However I'd like avoiding doing so as the additional code will not survive QuickBuild upgrade.

robinshen ADMIN · 1 decade ago

Can you please test if running as a normal user works?

ikotlova · 1 decade ago

Robin,

If QuickBuild server is started under a certain user then /etc/profile is run before the service starts. That way it is possible to reset environment variables, for ex. 'export PATH=/opt/bullseye/bin location:$PATH'.

If RUN_AS_USER is not set in server.sh, then QuickBuild server is started under local system account and PATH environment variable cannot be reset. Of course, I can set new system attributes. But cannot reset PATH, right?

Anyway, it seems like setting new system attribute is the way to go. And then using the attribute in the code instead of relying on the PATH.

Thanks,
Irina

robinshen ADMIN · 1 decade ago

I am not familiar with CentOS and QB relies on a third party product (JSW) to install it as a service. I am not sure if this problem also happens for other processes running as service with local system account, if you believe this is a bug specific to QB, please let me now and we will go ahead to file a bug report for JSW.

ikotlova · 1 decade ago

I am investigating another thing on Mac OS X 10.8 (Mountain Lion) and see similar environment variable problem.

Here is the setup:
Needed environment variables are set in /etc/launchd.conf
setenv BULLSEYE_HOME /opt/bullseye/bin
setenv BUILDDRIVE /Builds

<QB_agent>/bin/agent.sh has the setting:
RUN_AS_USER=qbuser

If QB build agent is started normally - non-console; then the mentioned above environment variables are seen on the System Attributes tab.

If QB build agent is started in console mode (nothing is changed, just run 'agent.sh console' instead of 'agent.sh start'); then the environment variables are not seen on the System Attributes tab. The PATH also does not show additional paths from /etc/paths.d.

I don't know if this is OS problem or QB problem, but the issue is that I cannot easily switch between non-console mode and console mode - the environment is lost. I tried updating /etc/profile; .profile, ... In the shell the variables exist, but QB build agent does not pick them up. Of course, the problem is resolvable - I can define all those variables on User Attributes tab. But, the PATH env. variable cannot be redefined on User Attributes. And it is just inconvenient.

On Mac OS X 10.6 (Snow Leopard) I am running QB build agent (the same version 5.0.29) in console mode under 'root' - and all environment variable set in /etc/launchd.conf shows up on System Attribute tab. My expectation is that the behavior should be consistent on all Mac OS X flavors.

As for CentOS - we don't have earlier OS boxes with QB build agent, so I cannot say that this is the case. But it seems that the same issue is present.

Most likely, newer Unix platforms changed their behavior. Would it be possible for QuickBuild build agent to adapt to this change?

Thank you,
Irina

robinshen ADMIN · 1 decade ago

Thanks for the info. We will verify this issue and report to JSW if necessary.

steveluo ADMIN · 1 decade ago

On Mac platform, you can keep the environments by:
1. set environment variables in /etc/launchd.conf (just like what you have done)
2. if you want to do some test, login with qbuser (same user as what you defined for RUN_AS_USER), and in the console, no matter you run agent.sh console or agent.sh start, the environment variables should be the same

I have not test on linux platform, but it may be the same case?

#10

ikotlova · 1 decade ago

Not sure what your suggestion is.

As I said: if build agent is started in console mode, then environment set in /etc/launchd.conf does not show up on System Attributes tab on Mac OS X 10.8 and is not recognized by the build. It does show up on older Macs like 10.6 and 10.7. Thus, the System Attributes behavior is different in regular mode and in console mode for Mac OS x 10.8. This complicates debugging, because it is impossible to easily switch between regular mode and console mode and have the same build environment. So, there is a regression here most likely because of OS behavior change.

In this case BULLEYE_HOME environment variable exists in regular mode (set in /etc/launchd.conf), but disappears in console mode. So, if I want to debug something in console mode temporarily, I am unable to do it as BULLSEYE_HOME is not set. I will need to set it as a User Attribute while in console mode.

The problem shows up on Mac OS X 10.8 and CentOS 6.3. The way of starting the build agent in console mode:

sudo agent.sh console

Windows platform (2008 Server) does not have this problem. While switching between regular and console mode the environment stays the same and keeps advanced system settings of the Control Panel (like BULLSEYE_HOME in this example).

Thank you,
Irina

#11

robinshen ADMIN · 1 decade ago

Under what account are you testing QB in console mode? Assume RUN_AS_USER is set to qbuser, we tested with three scenarios:
1. login as qbuser directly, now the shell itself has all environments as defined in /etc/launchd.conf, and in this case, starting QB in console mode, will also see these environments in system attributes page.
2. login as root user directly, but now root shell does not have environments already defined in /etc/launchd.conf. In this case, starting QB in console mode will NOT see those environments in systme attributes.
3. login as root user, but run "su - qbuser" to switch to qbuser, again qbuser shell does not have those environments, so running QB in console mode will not see those environemnts.

So this seems like a Mac OS behavior instead of a QB issue, after all, QB can only inherits environments from the shell.

#12

ikotlova · 1 decade ago

Thank you for the fast response, Robin. Yes, your observation is correct.

My <qbuser> account is a standard one and not an Administrator. This is a precaution not to damage the system accidentally. For ex., if there is a bad code that removes certain system file - running a build from a non-Administrator account will prevent the removal to happen.

1) Start QuickBuild build agent by logging in as another sudo-ed user (the current <qbuser> cannot sudo!), and then run

sudo agent.sh start

<qbuser> environment is preserved - I see it in the System Attributes.

2) Start QuickBuild build agent in console mode

sudo agent.sh console

<qbuser> environment is NOT preserved - neither of the settings in /etc/launchd.conf is set up in the System Attributes.

3) Start the build agent directly from <qbuser> login in a regular mode

agent.sh start

then this error pops up: Starting QuickBuild Build Agent. Detected Mac OSX and installed launchd daemon. Must be root to perform this action.

4) Start the build agent directly from <qbuser> login in console mode

agent.sh console

<qbuser> environment is preserved - I see it in the System Attributes.
------------
So, I have always been using 'sudo' method before on older Mac OSX as it worked for both regular and console mode. I did not use direct method as regular mode was unavailable because of the permissions. With Mac OSX 10.8 'sudo agent.sh console' from sude-ed account does not preserve the environment anymore. So, one should always run 'sudo agent.sh start' for the regular mode and 'agent.sh console' for the console mode.

Actually would be nice if this behavior were documented. What do you think? <img src="{SMILIES_PATH}/icon_wink.gif" alt=";-)" title="Wink" />

Take care!
Irina

#13

robinshen ADMIN · 1 decade ago

Thanks for the detailed info, Irina. Since the behavior might be different from different OS (QB supports dozens of different OS), documenting all these different behaviors might be difficult. However the rule is that as long as the shell starting QB has the environments, QB will have those in system attributes.

#14

ikotlova · 1 decade ago

'However the rule is that as long as the shell starting QB has the environments, QB will have those in system attributes.'
This statement is incorrect for 'root' login which is the most common situation. The environment is not preserved for QuickBuild build agent running in console mode. This happens on newer Unix OS: Mac OSX 10.8 and CentOS 6.3. It is, indeed worth mentioning in the Doc. Thanks.

#15

ikotlova · 1 decade ago

<img src="{SMILIES_PATH}/icon_neutral.gif" alt=":|" title="Neutral" /> Besides for the console mode still there is a problem. The environment is different if the build agent is started manually from the shell as opposed to started automatically upon reboot through /Library/LaunchDaemons/org.tanukisoftware.wrappers.quickbuild.plist. For instance, these variables are set in the console started from the shell but missing in the console started upon reboot:

Apple_PubSub_Socket_Render	/tmp/launch-jVBcjF/Render
Apple_Ubiquity_Message	/tmp/launch-5QcJvz/Apple_Ubiquity_Message

The behavior is also different: 'security unlock-keychain' command works for the first one and does not work for the second one. This, indeed caused us some pain until we figured the cause.

#16

robinshen ADMIN · 1 decade ago

Whenever you start QB in console mode, it will ignore RUN_AS_USER setting, and get started under your current login and will be using your current shell environment. Where are you defining below envs?
Apple_PubSub_Socket_Render /tmp/launch-jVBcjF/Render
Apple_Ubiquity_Message /tmp/launch-5QcJvz/Apple_Ubiquity_Message

#17

ikotlova · 1 decade ago

I am not defining those Apple variables. They are set in the shell under <qbuser> login. QB console mode started from <qbuser> has them.

Please advise how to start QB build agent in console mode automatically from <qbuser> login after a reboot with full <qbuser> environment. Here is the current content of /Library/LaunchDaemons/org.tanukisoftware.wrappers.quickbuild.plist which does not inherit full shell environment and does not work:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>org.tanukisoftware.wrapper.quickbuild</string>
        <key>ProgramArguments</key>
        <array>
            <string>/Builds/QuickBuild/buildagent/bin/./agent.sh</string>
            <string>console</string>
        </array>
        <key>OnDemand</key>
        <true/>
        <key>RunAtLoad</key>
        <true/>
        <key>UserName</key>
        <string>qbuser</string>
    </dict>
</plist>

#18

robinshen ADMIN · 1 decade ago

Console mode should not be started automatically as it have to attach to the console. QB running in service mode should take all environments just the same as other Mac services, if not, it is a bug and we can report to JSW for fixing.

#19

ikotlova · 1 decade ago

Robin, I filed the problem: http://track.pmease.com/browse/QB-1803. Thanks for your assistance.

#20

robinshen ADMIN · 1 decade ago

Is the environment variable "SECURITYSESSIONID" defined in "/etc/launchd.conf"? If yes, I think it is a Mac issue rather a QB issue, as environment variables there can not be picked up by normal user, that is, even if you write a simple Mac service, it will behave like this.

#21

ikotlova · 1 decade ago

Environment variable "SECURITYSESSIONID" is not defined in "/etc/launchd.conf". However it is defined in the shell.

#22

robinshen ADMIN · 1 decade ago

How do you define it in shell?

#23

ikotlova · 1 decade ago

I did not define it in the shell manually. I installed Apple code signing certificate under this OS user. Other OS users don't have it. It is necessary to run QB service under this OS user for code signing to succeed.

#24

robinshen ADMIN · 1 decade ago

Will check with JSW support to see if they have any idea.

#25

limor · 1 decade ago

Hi
I used 'sudo agent.sh start' and now the external scriptד that I run vi QB can successfully use the environment variables, like: $HOME. But I encounter in another problem - when I specify environment variables for command execution in ‘Build > Shell/Batch Command’ step the script doesn't recognize the environment variables that I send. I log in the agent machine with quickbuild user. Is there a solution for that issue?

#26

limor · 1 decade ago

Apparently it is not because I ran the agent.sh with sudo. I resolved it by running the script with 'sudo -E'.