The fix-permissions script must be re-run on $HOME after various setup.

[GrahamDumpleton]

What docker image you are using?

All of the following images are affected in some way.

jupyter/base-notebook
jupyter/tensorflow-notebook
jupyter/datascience-notebook
jupyter/r-notebook
jupyter/scipy-notebook
jupyter/minimal-notebook

What is the problem?

The fix-permissions script is run on the $HOME directory once in Dockerfile for base-notebook, and in one special case in scipy-notebook. This is not enough.

The fix-permissions script needs to be run after any commands which could result in per user config or cache files being written to the home directory of the user. Because this isn't done in many cases, the per user config or cache directories are not writable to group.

For example from minimal-notebook.

 ls -las
total 40
4 drwsrwsr-x 1 jovyan     users 4096 Feb 11 10:26 .
4 drwxr-xr-x 1 root       root  4096 Feb  4 21:34 ..
4 -rw-rw-r-- 1 jovyan     users  220 Aug 31  2015 .bash_logout
4 -rw-rw-r-- 1 jovyan     users 3771 Aug 31  2015 .bashrc
4 drwxr-sr-x 3 jovyan     users 4096 Feb  4 21:34 .cache
4 drwxr-sr-x 3 jovyan     users 4096 Nov 11 04:29 .conda
4 drwx--S--- 3 1000030000 users 4096 Feb 11 10:26 .local
4 -rw-rw-r-- 1 jovyan     users  655 May 16  2017 .profile
4 drwsrwsr-x 2 jovyan     users 4096 Nov 11 04:28 work
4 drwxr-sr-x 3 jovyan     users 4096 Feb  4 21:36 .yarn

The .cache, .conda, .local and .yarn directories are not group writable, and neither would files in them.

This will cause commands to fail later which want to write to those directories if running as an assigned user ID and relying on supplemental groups set when running the image, to be able to write to them.

The fix-permissions command should be run on $HOME after all commands to install packages that use these directories. For example after conda is run, but most likely others as well.

[GrahamDumpleton]

@parente I will be starting on a PR for this tomorrow. Warn me if already done work on it.

[parente]

@GrahamDumpleton Thanks for the heads up. I've not many cycles to spare on any docker-stacks work for the past week or so, so please, have at it.

My only thought on this issue is that some of those folders created in $HOME should probably be deleted during the step that creates them if they are caching downloads (e.g., .yarn, .conda) to avoid bloating the image size.

[GrahamDumpleton]

Of interest, just removing the .cache directory, which contains packages from yarn, drops the image size as shown by docker images by 150+ MB.

Before.

REPOSITORY                                TAG                 IMAGE ID            CREATED             SIZE
172.30.1.1:5000/myproject/base-notebook   latest              c9ad57cd0f15        3 minutes ago       884MB

After.

172.30.1.1:5000/myproject/base-notebook   latest              ab80f18db161        35 seconds ago      727MB

[GrahamDumpleton]

There is a potential conflict between packages in base-notebook and what r-notebook wants. This results in:

The following packages will be DOWNGRADED:
--
  |  
  | pandoc:          2.1.1-0              conda-forge --> 2.0.0.1-0     conda-forge
  | python:          3.6.4-0              conda-forge --> 3.6.3-0       conda-forge
  | pyzmq:           17.0.0-py36_3        conda-forge --> 16.0.2-py36_0 defaults
  | readline:        7.0-0                conda-forge --> 6.2-0         conda-forge
  | sqlite:          3.20.1-2             conda-forge --> 3.13.0-1      conda-forge
  | tk:              8.6.7-0              conda-forge --> 8.5.19-2      conda-forge

If this means different versions of packages are being pulled down to replace existing ones, then it only serves to bloat out the r-notebook image size.

A separate issue should perhaps be created to investigate this and avoid downgrading of packages if possible.

[GrahamDumpleton]

The scipy-notebook also has packages being downgraded.

The following packages will be DOWNGRADED:
--
  |  
  | python:             3.6.4-0                       conda-forge --> 3.6.3-1       conda-forge
  | readline:           7.0-0                         conda-forge --> 6.2-0         conda-forge
  | sqlalchemy:         1.2.1-py36_0                  conda-forge --> 1.1.13-py36_0 conda-forge
  | sqlite:             3.20.1-2                      conda-forge --> 3.13.0-1      conda-forge
  | tk:                 8.6.7-0                       conda-forge --> 8.5.19-2      conda-forge

And some removed, which will not actually save any space.

Package plan for package removal in environment /opt/conda:
--
  |  
  | The following packages will be REMOVED:
  |  
  | pyqt: 5.6.0-py36_4 conda-forge
  | qt:   5.6.2-3      conda-forge

[GrahamDumpleton]

In scipy-notebook the directory /home/jovyan/.node-gyp can also be cleaned up.

[GrahamDumpleton]

Saving on size in scipy-notebook should be good as well. Before:

172.30.1.1:5000/myproject/scipy-notebook     latest              6a418668485d        14 minutes ago      4.65GB

and after

172.30.1.1:5000/myproject/scipy-notebook     latest              bf02406e9bb5        4 minutes ago       4.28GB

So almost 400MB on image size by docker images.

The before size is already based on the trimmed base-notebook.

[minrk]

yeah, none of the build artifacts should be left in HOME. In fact, there should be hardly anything in $HOME in all of our images (no config, no packages, etc.), so ~any file created in $HOME should be considered a bug in the line that creates it. My guess is that the majority of it is happening in the jupyterlab build step. I don't believe the fix is to run fix-permissions on $HOME, but instead delete the cached artifacts.

As for downgrades, it's likely happening because of some compatibility in downstream packages (e.g. the R kernel package linking an older libzmq to the latest pyzmq), which should generally be fixed when downstream packages update. Identifying which ones are causing this would be useful, though.

[GrahamDumpleton]

It is not entirely true that everything in $HOME should be deleted. In scipy-notebook the step taken to pre-calculate fonts stuff related to matplotlib will leave stuff under the .cache directory. So removing that is probably not a good idea. I have already taken that into consideration. Will be creating PR later today as done all the changes required.

[parente]

Fixed by #555.