dfki-ric / docker_image_development

Scritps and Dockerfiles to support docker-based, 3D accelerated development and release of docker images
BSD 3-Clause "New" or "Revised" License
6 stars 13 forks source link

set_xserver_args find inconsistent results with DOCKER_XSERVER_TYPE=auto #92

Open pierrewillenbrockdfki opened 4 months ago

pierrewillenbrockdfki commented 4 months ago

Symptoms:

Investigation revealed that the configuration mismatches between the first exec.bash run and the automatic second run after the container has been regenerated. In the first run, DOCKER_XSERVER_TYPE=xpra was decided on, in the second run, it found DOCKER_XSERVER_TYPE=mount and the configuration for those.

I would guess that the SSH_* environment variables are not set the same in the second exec.bash run.

This has been worked around by setting DOCKER_XSERVER_TYPE=xpra in settings.sh.

planthaber commented 4 months ago

The settings are only usable on container creation (docker run), which is done in the initial call of ./exec.bash, subsequent calls are using docker start / docker exec to run code. to update the parameters the container needs to be re-created. this is why the regeneration is requested.

It could be that the ssh detection is not functioning correctly for you, can you check if $SSH_CLIENT or "$SSH_TTY" is set on the pc you are accessing by ssh?

https://github.com/dfki-ric/docker_image_development/blob/master/.docker_scripts/docker_commands.bash#L138-L140

pierrewillenbrockdfki commented 4 months ago

That commit alone is not sufficient to resolve this issue. The SSH_CLIENT and SSH_TTY are both set. I cannot upgrade to an VERSION 4 image at the moment. (But i can just remove the VERSION file changes to test commits.)

Also maybe interesting, the second (automatic) invocation runs with elevated privileges compared to the first. It can modify .container_config.txt even if one has setup permissions so the normal user cannot.

planthaber commented 4 months ago

The .container_config.txt is only modified by the scripts outside of docker, so that has nothing to do with elevated docker privileges. If the scripts are raising them, because it is reqiured for features of the settings.bach (e.g. docker in docker) there is a clear warning (not if --privileged is already in the ADDITIONAL_RUN_ARGS).