[Documentation] Document running Workbench under Software Collections
Our Python SDK RPM is currently built to work with Red Hat's Python 2.7 Software Collection. This means that in order to have the Python tools in your environment, you have to activate the Software Collection with
scl python27 enable [command].
Workbench needs to be able to run
arv-get, so it needs the Software Collection activated this way. Figure out the best way to configure nginx to run the Workbench Passenger application inside the Software Collection environment, and document that in the Workbench install guide.
#1 Updated by Brett Smith over 4 years ago
Investigated so far:
- The Software Collection includes a shell script at
/opt/rh/python27/enablethat makes the necessary changes to all the right environment variables.
- The Passenger documentation says apps are invoked from bash, so it should be possible to source this file from a bashrc to make the right thing happen.
- I tried to do that in one deployment (editing the bashrc of the user running the Passenger app process) and was not successful. I also tried to use
passenger_env_varto hardcode all the relevant environment variables to use the Software Collection, and didn't have luck with that either. However, I was moving fast, so it's very possible I made some simple mistake, and either of these approaches are still workable.
#5 Updated by Brett Smith over 4 years ago
6940-workbench-centos-install-wip is up for review.
The Nginx setup instructions had to move up to keep the install guide working in order. See the commit message for details.
Explanation for how this works: if passenger_load_shell_envvars is on (the default), and the user's shell in bash, Passenger invokes the application via
bash -l -c. They recommend putting environment variables in .bashrc, but on Red Hat, at least, that seems wrong: quoting the bash man page, "When bash is invoked… as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable."
So we set the nginx user's shell to bash, and load the environment variables from
.bash_profile instead. We at least check that this is a non-interactive shell with
[[ -z $PS1 ]] (the same way Red Hat does it in
/etc/profile). I have tried to write everything in such a way that even if a Debian user runs it and ignores any errors, it will not break their configuration, which is why we check for the existence of the file before we source it. You could argue this is more likely to mask other system configuration errors on CentOS, but I suspect that case will be hard to debug no matter what we do: it's not like
source itself has great error checking, or will flag the problem for Nginx.