New environment configuration file: /etc/devcontainer

[felipecrs]

A new option in devcontainer.json:

{
  "sourceEtcDevcontainer": true // defaults to true
}

This option makes the Remote - Containers extension always execute commands in the container using the following syntax:

$ docker exec ubuntu sh -c "test -f /etc/devcontainer && . /etc/devcontainer; echo 'hello world'"

Unless the user sets it to false.

This will not interfere in userEnvProbe behavior.

The /etc/devcontainer file must be a shell script compatible with Bourne Shell /bin/sh.

This would enable us to have a clean and unique environment configuration file that would work across all the users (root and non-root), and all the shells, without the caveats of /etc/profile or bash.bashrc.

So global environment variables can be set using scripts and not only through the Dockerfile's ENV statement, or the devcontainer.json's containerEnv, thus making the installation scripts easier to use since they would not require the user to manually inject some statements in the Dockerfile.

This would mainly benefit the scripts from script-library on vscode-dev-containers repository, which are used for doing common customizations on the containers. As explained here (bullet number 2).

[chrmarti]

Does "userEnvProbe" in the devcontainer.json not solve this?

[felipecrs]

I'll test it soon and let you know. Thanks.

[felipecrs]

@chrmarti Yes, this is what I was looking for, but with a caveat.

Without "userEnvProbe": "loginInteractiveShell" it does not work:

But with "userEnvProbe": "loginInteractiveShell" it works as expected:

However, I was actually looking for an option loginShell and not loginInteractiveShell, which translates to sh -l and sh -l -i respectively.

And, I'm proposing to make loginShell option as the default value instead of none. The reason is:

This would mainly benefit the scripts from script-library on vscode-dev-containers repository, which are used for doing common customizations on the containers. As explained here (bullet number 2).

This would enable us to switch from:

ARG PYTHON_VERSION="3.8.3"
ARG PYTHON_INSTALL_PATH="/usr/local/python${PYTHON_VERSION}"
ENV PIPX_HOME="/usr/local/py-utils"
ENV PATH="${PYTHON_INSTALL_PATH}/bin:${PATH}:${PIPX_HOME}/bin"

RUN bash -c "$(curl -fsSL "https://raw.githubusercontent.com/microsoft/vscode-dev-containers/master/script-library/python-debian.sh")" -- "${PYTHON_VERSION}" "${PYTHON_INSTALL_PATH}" "${PIPX_HOME}"

to:

RUN bash -c "$(curl -fsSL "https://raw.githubusercontent.com/microsoft/vscode-dev-containers/master/script-library/python-debian.sh")"

[chrmarti]

"userEnvProbe" doesn't affect the building of the Docker image. Couldn't you change your Dockerfile to use RUN bash -l -c "..." if using a login shell allows you to shorten it?

Taking this as the feature request to add "loginShell" for "userEnvProbe".

[PavelSosin-320]

Why it is better than entry-point script? Container is not multitenant. Repetitive login can create sibling processes that will be never killed by init during the termination and become ghost OS processes. This is very dangerous.

[felipecrs]

"userEnvProbe" doesn't affect the building of the Docker image. Couldn't you change your Dockerfile to use RUN bash -l -c "..." if using a login shell allows you to shorten it?

@chrmarti This is not about that, this is about setting up container wide environment not by using ENV. By the way, if someone wants to do what you said, it's better to use SHELL [ "bash", "-l", "-c" ].

Did you check my example? With "userEnvProbe": "loginInteractiveShell", VSCode process was able to find the custom Python executable even without setting the ENV PATH on the Dockerfile.

[felipecrs]

Why it is better than entry-point script?

I don't understand how this is related to the entry point script. Remember that entry point script is not run on docker exec. I actually want to assure that entry point is executed by default, but it's a totally different history.

Container is not multitenant. Repetitive login can create sibling processes that will be never killed by init during the termination and become ghost OS processes. This is very dangerous.

I use login shell in my Linux environments since ever, and I don't see anything dangerous in /etc/profile. Even if something could be found (such as starting a process), this block would probably check if there is a command already started. Such as the ssh-agent.

Also, the login environment would be only applied to the command which we are executing, it would not affect other running shells for example.

That said, do you have any reference for what you said? Or an example?

[Chuxel]

@chrmarti I'm actually a +1 on doing this by default. There's actually quite a bit of code in vscode-dev-containers that is working around this particular scenario. The big problem is scripts that must be sourced to get the path to work correctly. SDKMAN, nvm, rvm all are like this. I'm adding things the containers install to the PATH when possible, but this only covers a limited set. In the SDKMAN case there are a number of tools it can install. Worse yet, rvm throws up warnings if things are in the path and the targets are not easily predictable (e.g. the gem path). To your point, we could probably add SHELL to work around it, but I could see someone trying to create their own dev container hitting this and being confused.