Arvados

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.

Setting in .bashrc doesn't work because the nginx user's shell is not bash, which causes Passenger to invoke the child application directly.

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.

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.

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.