Issue with Sarus on PizDaint

[ChristopherBignamini]

As suggested by @jougs , I open this issue to discuss a problem with the execution of the nest-server on PizDaint with Sarus. On that machine the execution of the command

sarus run nestsim/nest:latest nest-server

generates the following output:

id: 'nest': no such user UID : 9001 perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). adduser: Only root may add a user or group to the system.

The main issue is the one reported in the last line, that refers to the execution of the adduser command currently located in the entrypoint file: with Sarus there are some limitations to the operations that can be performed inside a container. I have tried to fix the above issue for our case moving the adduser operation inside the Docker file (please see the attached .zip), basically copying an old version of the Dockerfile/entrypoint pair we were using before the inclusion of the server in the nest code, but I am not sure it is a good idea. The image built with the attached Dockerfile/entrypoint seems to work with Sarus on Daint but we would like to find a better solution and avoid to branch from the official version.

Cheers Christopher

Files.zip

[jougs]

@steffengraber: can you please have a look at this and give us a short explanation for why we need the additional user setup thingy in the first place, while the Files.zip by @ChristopherBignamini don't need that? I also seem to remember that you once told me that you ran the official NEST Docker image on Daint using Sarus, which kind of contradicts the experience described here. Many thanks!

[steffengraber]

Hi @ChristopherBignamini Thank you for bringing this up.

We do not want to run NEST as root inside Docker Containers. So, we created a separate user for it. For some of the use cases it makes sense to share files between host and container via a simple share (option -v). As soon as the user on the host system and the user in the Docker have different UIDs, there is no write access to the shared files inside the container. The idea now is to create a user at container startup with the same UID as the user on the host system. This now causes problems with Sarus on PizDaint, which, as far as I remember, wants to create a user itself. I tested this a long time ago and adjusted our docker image a little bit (only for testing).

docker pull nestsim/nest:piz-daint

In it a NEST 2.20.0 running under root now, no own user is created anymore. Maybe there is a simple solution to combine both approaches, or to improve the file exchange between host and container. I am open for suggestions.

The Dockerfile is located here: https://github.com/steffengraber/nest-docker/tree/piz-daint/src/piz-daint

[jougs]

We do not want to run NEST as root inside Docker Containers. So, we created a separate user for it.

Can you please elaborate on why we don't want to run as root?

For some of the use cases it makes sense to share files between host and container via a simple share (option -v). As soon as the user on the host system and the user in the Docker have different UIDs, there is no write access to the shared files inside the container. The idea now is to create a user at container startup with the same UID as the user on the host system.

If I understand the Docker documentation on bind mounts correctly, the bind is read-write by default. So theoretically, this scenario should work even without creating the Docker-internal nest user.

This now causes problems with Sarus on PizDaint, which, as far as I remember, wants to create a user itself.

I think the situation with Sarus is rather that it runs whatever is inside of the image with the privileges of the user on the host. As this is (usually) not root, the call to adduser fails and the official Docker does not work.

I tested this a long time ago and adjusted our docker image a little bit (only for testing).

docker pull nestsim/nest:piz-daint

In it a NEST 2.20.0 running under root now, no own user is created anymore. Maybe there is a simple solution to combine both approaches, or to improve the file exchange between host and container.

If my assumptions above are correct, this could right away be used as the official image. Would you be able to create such an image also for the current Git master? I would be keen on testing that on Piz Daint with Sarus.

[terhorstd]

As far as I understand, the adduser call in the entrypoint was thought to ease the mounting of users files into the container. It should however not be the business of the image to do user management. The outside environments have to be responsible to set up proper user mappings and choose which outside rights the inside user runs with. It would conceptually be a major security breach if the docker container can decide its own rights on the outside. Therefore any adduser call in the entrypoint and USER directive in the Dockerfile can just reduce compatibility with the host environment. The container management needs some default on the container-inside to rely on, but should handle all user mapping and permissions from the outside. So imho the USER and adduser lines should be thought through very thoroughly, and should likely just be removed.

Accordingly I close #55 as duplicate.

[steffengraber]

In the latest image oo docker hub, the user is now removed. The services like Jupyter Noteboot work. A problem could occur when data is written to the share volume in the container. But maybe the problem is not big and the data exchange on volume level is not needed. Maybe you could test the image for your applications. To then make a decision: user or no user.

[jougs]

I'm fine with the removal of the user, as this apparently did more good than harm in the past. And we can always solve any data storage problems if they should occur.

[steffengraber]

@babsey You can test the 'latest' docker now.