Project

General

Profile

Actions

Bug #6940

closed

[Documentation] Document running Workbench under Software Collections

Added by Brett Smith about 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Documentation
Target version:
Story points:
1.0

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.


Subtasks 1 (0 open1 closed)

Task #7053: Review 6940-workbench-centos-install-wipResolvedBrett Smith08/10/2015Actions
Actions #1

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.
Actions #2

Updated by Brett Smith about 9 years ago

  • Assigned To set to Brett Smith
Actions #3

Updated by Brett Smith about 9 years ago

  • Status changed from New to In Progress
Actions #4

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.

Actions #5

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.

Actions #6

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.

Actions #7

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.

Actions #8

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.

Actions

Also available in: Atom PDF