Mechanism for enabling SCL packages. about s2i-python-container HOT 19 CLOSED

Confirmed that if entrypoint is meant to allow enabling of SCL, it isn't working on CentOS images either.

$ oc rsh wsgi-hello-world-1-rqiy2 python -V
Python 2.7.5
$ oc rsh wsgi-hello-world-1-rqiy2 bash -c 'python -V'
Python 2.7.8

I might also add that I think the nss_wrapper setup should be in an entry point script as well so that that activation is also done. This way when someone does oc rsh and gets a bash script, the nss_wrapper stuff behaves like it would when application is running and have equivalent environment when debugging.

This is how I described it is better done in:

• http://blog.dscpl.com.au/2015/12/unknown-user-when-running-docker.html

It works better that way.

FWIW. So far my experiments sort of showed that S2I builder wipes out any ENTRYPOINT in the base images. I need to confirm that but can't do so right now due to broken Internet.

from s2i-python-container.

Ignore this.

Is me forgetting that oc rsh or oc exec is not the same as docker run in as much as rsh and exec bypass ENTRYPOINT. Only run uses the ENTRYPOINT.

from s2i-python-container.

Does oc rsh not run a bash shell? @mfojtik @bparees?

from s2i-python-container.

@mnagy

$ oc help rsh
Open a remote shell session to a container

This command will attempt to start a shell session in the specified pod. It will default to the
first container if none is specified, and will attempt to use '/bin/bash' as the default shell.
You may pass an optional command after the pod name, which will be executed instead of a login
shell. A TTY will be automatically allocated if standard input is interactive - use -t and -T
to override.

Note, some containers may not include a shell - use 'oc exec' if you need to run commands
directly.

from s2i-python-container.

Right. So that means you need to rsh, and then start python in order to get python from SCL

from s2i-python-container.

but I thought @mfojtik 's PROMPT_COMMAND magic was supposed to setup the scl enablement for cases like this... @mfojtik ?

from s2i-python-container.

@bparees my magic is weak if rsh use something else than bash.

from s2i-python-container.

@mfojtik I would have assumed it does use bash... but likely via a /bin/sh symlink to /bin/bash, so perhaps that changes the behavior?

this is definitely an issue imho if oc rsh into our images does not scl enable the right thing.

from s2i-python-container.

@bparees I think PROMPT_COMMAND is taken into account everytime you have interactive shell that does have PS1 set. I need to check what does rsh do, maybe it invokes /bin/sh which is restricted shell that does not support PROMPT_COMMAND. Long term, we should get rid of this 'hack' and have a way to enable SCL everywhere with one simple configuration setting.

from s2i-python-container.

seems to work ok for me in the 3.4 image:

$ oc rsh django-ex-1-qenm0
bash-4.2$ python --version
Python 3.4.2

from s2i-python-container.

oc exec does not work, unsurprisingly:

$ oc exec django-ex-1-qenm0 "python --version"
exec: "python --version": executable file not found in $PATH
error: error executing remote command: Error executing command in container: Error executing in Docker Container: -1

from s2i-python-container.

so nm, i think we're ok here with a known limitation on directly running commands in the container.

from s2i-python-container.

@bparees because you invoke the binary directly, bypassing bash

from s2i-python-container.

yes i know, hence my statement of "unsurprisingly" :)

from s2i-python-container.

We could theoretically change rsh to run the command through bash -c. Not sure if that would have any risks.

from s2i-python-container.

among other things it would mean rsh would only work on images w/ bash. or would need special logic to check if bash was present.

from s2i-python-container.

Your oc exec wouldn't have worked because you quoted the full command and so it was taking it as the actual executable to run. Use:

oc exec django-ex-1-qenm0 python --version

and it would run and use system Python and not SCL Python.

The oc rsh is effectively equivalent when you give it a command:

oc rsh django-ex-1-qenm0 python --version

The only difference is that oc rsh automatically attaches the tty and stdin.

from s2i-python-container.

I ran into a few use cases where scl_enable threw me off.

1. Extending the s2i image and running python/pip results in the wrong version being used. A workaround is /bin/bash -c "python" but it's not immediately clear why this is needed.
2. It makes a lot of sense to me to use docker for local development. IMO it's far easier and more shareable than doing development with s2i images or without docker. It's actually not so hard to reuse/extend the s2i python image and use it like this however the need to explicitly run bash again threw me off initially.

IMO the ability to run commands like a "normal" docker image would make s2i more accessible - especially so for people who are already familiar with Docker.

from s2i-python-container.

@hhorak fyi.

from s2i-python-container.