docker: no longer chown /opt

[KrisThielemans]

At least on some systems, changing ownership of /opt/* took a long time when the container was created. Instead, we just give everyone write permissions, but do this when creating the images.

Fixes #555

[KrisThielemans]

container start-up time is now indeed very fast, while creation time is very long...

We should try to be more selective probably, and definitely not do the whole of /opt again at the end of the service image creation (where it should only have to do whatever was installed as extra in /opt/pyenv)

[KrisThielemans]

Ah well. I thought I had it fixed with my new strategy: use umask 000 when calling user_*sh. Indeed, this fixes permissions of /opt/pyenv and /opt/SIRF-SuperBuild as I expected to be read/writable for everyone:

$ ls -l /opt/
total 24
drwxr-xr-x 2 root root 4096 Jun  5 17:20 bin
drwxrwxrwx 1 root root 4096 Jun  7 21:16 ccache
lrwxrwxrwx 1 root root   25 Jun  5 17:20 cmake -> cmake-3.13.4-Linux-x86_64
drwxr-xr-x 6 root root 4096 Jun  5 17:20 cmake-3.13.4-Linux-x86_64
drwxrwxrwx 1 root root 4096 Jun  7 22:02 pyvenv
drwxrwxrwx 1 root root 4096 Jun  7 22:02 SIRF-SuperBuild

Result: image creation time same as on master, but container creation time 1 second! Yay!

Except... it doesn't work. Files in /opt/SIRF-SuperBuild/sources/SIRFand.../builds/SIRF/build(and all others) are not writable bysirfuser, and a conda install coverage` fails with a permission problem.

It seems that setting umask 000 gets ignored by same programs. Oh well.

[KrisThielemans]

So, the question is then if we can live with sirfuser not being able to write to most of /opt. Consequences

• conda install fails
• sudo conda install fails as it's not in the path (fixable)
• sudo /opt/pyvenv/bin/conda install seems to work
• pip install works
• updating the /opt/SIRF-SuperBuild would need sudo

Presumably it would be safest to chmod .../sources/SIRF/data

Of course, this would have to be documented.

It's not ideal, but shaving 10 mins of start-time isn't small...

Or is there another solution?

[paskino]

Is it not possible to use sirfuser to run some stuff, like building SuperBuild, install conda etc?

There's no reason why conda should be installed by the superuser.

[KrisThielemans]

Is it not possible to use sirfuser to run some stuff, like building SuperBuild, install conda etc?

The point is that at image build time (i.e. whatever Dockerfile does), you don't know yet what the UID:GID has to be. You could do it with 1000:1000 and hope to be lucky, but we'd still have to cope with other values.

(Note that the username/groupname don't mean anything, it's the numbers that matter).

[KrisThielemans]

Haroon Chughtai suggests

another option could be to create and grant permissions to the needed folders to a group during the build. Then when the image is pulled and run, the created user just needs to be added to that group to have the right access?

I guess this might work as:

• Dockerfile
  • create group (with crazy gid)
  • (I think) create user (with crazy uid)
  • run the user_sh as this user
• entrypoint.sh
  • add sirfuser to the above group

First check in a VM (or running docker) that the above strategy actually allows sirfuser to write to the relevant directories.

[KrisThielemans]

@paskino I've taken some of your lines in #569 and incorporated them in the "regular" stuff. I've kept @casperdcl's overall structure, but do make another user (part of users group), and make sirfuser also part of users, as suggested by Haroon. This way, we don't need to chown most files anymore. Image build time is a bit longer (as it still has to do some chown), but container build time is then very fast.

We have therefore 2 users: jovyan (builds) and sirfuser (runs and mounts /devel).

However, conda is run by jovyan, while bash (in sirf:latest) or jupyter (in service) are run by sirfuser , which could/will lead to confusion.

Note that with this set-up, it should be easy (?) to copy some of your lines at the end of the current Dockerfile for a new jupyterhub service.

I hope this was clear enough, but probably not!

[KrisThielemans]

@paskino I tried this together with #574 It seems to work quite well. Reasonably fast build time (some chown stuff still), and very fast container start-up. I see no down-sides (aside from the extra complication...).

It should also be almost ready for the jupyterhub changes.

I believe we should merge these PRs. (There's a conflict, which I'll sort out).

[KrisThielemans]

@paskino I've cleaned up the history and merged it. Let's see what the Travis build says for the generated dockers...