Bug #6940
closed[Documentation] Document running Workbench under Software Collections
Description
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.
Updated by Brett Smith about 9 years ago
Investigated so far:
- The Software Collection includes a shell script at
/opt/rh/python27/enable
that 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_var
to 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.
Updated by Brett Smith about 9 years ago
Setting in .bashrc doesn't work because the nginx user's shell is not bash, which causes Passenger to invoke the child application directly.
Updated by Brett Smith about 9 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.
Updated by Brett Smith about 9 years ago
I should add that I tested everything by starting from a new centos:6 Docker container and following the install guide as written. At the end I had a running Workbench that could display files.
Updated by Tom Clegg about 9 years ago
Downloading just worked when I followed the instructions, so yay! and LGTM. Thanks.
Filed #7129 with some unrelated (but nearby) doc issues I ran into.
Updated by Brett Smith about 9 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:a8b431b5cfccd36995514560f965b4943ac93c6b.