Change default username to something generically impersonal

[sammy-hughes]

To make using this in a professional capacity a tad easier, could the images published to the docker hub carry an impersonal username for the default user? Making this a build-arg would also be cool. It's just one less point of friction for using this at work.

The user for the images currently available on docker hub is "jovyan". Something like "gopher" or "notebook" would be less concerning if I or someone else had to shell into the instance or mount user-space files.

Making the username a build-arg, while not certainly feasible, might also be a pleasant touch for contextualizing the application to different spaces and conventions. It's easy enough to clone, modify, build, and push to my workplace's private image repo, contextualized as needed, but it would be nice to have that bit be hands-off, assuming that's viable.

[janpfeifer]

hi @sammy-hughes ,

Thanks for bringing this to my attention.

So the jovyan user relates to the meaning of 'jovian', or "relative to Jupyter", see wikipaedia article. The user name is actually inherited from the Jupyter Notebook docker, they use jovyan there. Does knowing the name origin lightens the friction on your side ?

As you mentioned ideally I would create a Dockerfile where the username is configurable. Since the Jupyter base docker I use as source for GoNB has a hardcoded username, I would probably have to recreate their dockerfile in a new one. Let me take a stab at it later ... it could be a good thing, since I could add more testing tools (the Docker image as is doesn't allow running the full tests, because it lacks some packages).

If you don't mind me asking: does the fact that GoNB repository is still in my personal github account ("github.com/janpfeifer") create a similar issue for your work environment ? Would it help if I relocated the project to an account dedicated to a project instead ? -- I also maintain github.com/gomlx.

cheers

[oderwat]

@janpfeifer maybe a stupid question, but can't we just rename a users home when building? We build a lot of images that we use on top of existing ones but modify them by adding or changing stuff. We use Earthly for "everything" now and this even lets us compose images from multiple sources into one (or more) final images or other packages we deploy.

[janpfeifer]

hey @oderwat , my unix/linux sys-admin skills are a bit rusty, but I wonder if sudo usermod -l will do the job, or if there are files (.bashrc, Jupyter, etc.) that have the username hardcoded ... it's a good question. That would be the first thing I would try.

Btw, any suggestions for the "standard" user name ?

I intend to make it a variable, so it's easy for someone to re-create the docker width a different user name.

[oderwat]

@janpfeifer I think it is good practice to reference the users in their scripts through $HOME or ~. Because if not, you would need to change the names in the scripts. Besides that you need to make sure that the permissions are all changed to the new user for files outside the home directory (I believe there are none).

For the name, I somehow also thought it is your private username at home ;-)

I usually use anon for something like that. Not sure if people would like that (some will). Maybe just jupyter, gonb, default or user?

[sammy-hughes]

I totally forgot to look in on this. I did think it was a personal username, but yeah, that makes sense. I guess, I just trusted the jupyter images and haven't dived into them the same way as with GoNB.

And yeah, like @oderwat says, the variable $HOME already exists and refers to the user's home directory.

In the meantime, @oderwat's suggestion of renaming the user would also apply to my use of the image as well. I would be concerned about environment variables such as $PATH or $GOPATH being invalidated, but otherwise it's pretty doable.

[janpfeifer]

So, looking around -- the documentation in Docker is so ambiguous 😞 -- it seems that the FROM clause can only use pre-built (like compiled) images, so even though Jupyter's Dockerfile configures the user name as an ARG, it cannot be changed if I use FROM jupyter/base-notebook.

Indeed GoNB's Dockerfile already uses environment variables for HOME and USER, so nothing is hard-coded to "jovyan" (except in the comments/examples).

Let me try renaming the user, maybe more luck there.

[janpfeifer]

Renaming the user in GoNB's Dockerfile (see below) kind-of-work, if I start the generated docker with bash and manually start jupyter lab.

But the Jupyter startup script actually hardcodes the user "jovyan", so the default executing the docker doesn't work. I need to investigate a bit more.

Dockerfile changes:

# "jovyan" is the user name used by `jupyter/base-notebook`.
# If it is changed, it requires renaming the user and moving its home directory.
ARG USERNAME=jovyan

# Update apt and install basic utils
USER root
RUN <<EOF
  if [[ "${USERNAME}" != ${NB_USER} ]] ; then
    usermod -d /home/$USERNAME -l $USERNAME -m $NB_USER
  fi
EOF

[janpfeifer]

Just an update: last week after looking a bit more, I realized that the jovyan user name only shows up in the docker instruction (docker run -it --rm -p 8888:8888 -v "${PWD}":/home/jovyan/work janpfeifer/gonb_jupyterlab:latest) -- let me know if you see it anywhere else.

With that in mind, in the docker I created a directory /notebooks (we could change the name), and I changed the default running command to docker run -it --rm -p 8888:8888 -v "${PWD}":/notebooks/host janpfeifer/gonb_jupyterlab:latest -- completely by-stepping the username.

What do you think ?

cheers

[sammy-hughes]

That's fantastic.

Specifically the use case for me is mounting one or more workbooks, with some secondary scripts into a container as part of a docker-compose that would also be creating local simulation replicas to represent parts of a production system. This meant that the user as the default mount-point stood out.

I do really like what you proposed, though.

[janpfeifer]

Cool! Then that is solved. Thanks again @sammy-hughes for bringing this up.

Closing the issue then.