Feaure: support --user flag about octoprint-docker

[LongLiveCHIEF]

pip install and so is stored all over the container image

They're actually not, they're stored on a path from /opt/venv since it's a python virtual env.

Another option I am consindering is to try the dockerfile here. https://github.com/nunofgs/docker-octoprint/blob/master/alpine/Dockerfile this uses alpine and the supervisord and allows a bunch of configure-ability, like user etc at launch time (similar to the editing the Entrypoint)

This is the same technique our current images use. I'll be adding alpine based images as well as part of the current project phase.

Lastly I am running this as non-privileged user and for this work I had to rebuild my image with the following changes.

Nailed it! That's how we are going to recommend this image being used going forward!

The problem is that things like --user flag and the linuxserver images PUID env vars, is that they both start from a base assumption that the docker image and process it contains is run by root as default.

Unfortunately, octoprint won't run if it detects it is being started as a root user, so we can't use the simple --user flags to get this behavior.

However, if all you're looking to do is save the image state after running plugin installs, then you should just run docker commit octoprint myoctoprint.

You don't have to go through the trouble of creating your own Dockerfile.

I'll be working on the docs and probably doing an accompanying video on them this weekend. I get the feeling based on your comments that you're actually making this way harder that it is, and that if you wait until the docs are updated and video is published you will be able to see that.

I'm trying to rush responses just to keep up contact and let everyone know I'm working on it, but that means I'm not getting time to think about the best way to say things so that they can be universally understood.

[vajonam]

No worries I will wait for the video / docs and see if doesn't sort out my issues.

[appleimperio]

Someone manage to do this. I need the pid and uid environments since my files are on a NFS share and I have other octoprints not running on docker. I have a mix of files ones owned by root others by pi or is there a way to do this that the folders created by octoprint dockers are owned by pi? thanks

[gaetancollaud]

All PR are welcome, but I think this is already done.

https://github.com/OctoPrint/docker/blob/master/Dockerfile#L48-L49

[hakan42]

I believe that is not fully what vajonam intended. To have the feature fully nicely, it would be good if the UID / GID could be injected at runtime. For example, see the images over at linuxserver.io:

https://hub.docker.com/r/linuxserver/mariadb

[vajonam]

Yes that is what I am talking about similar to linuxserver.io

…

On Wed, Mar 25, 2020 at 4:45 PM Hakan Tandogan ***@***.***> wrote: I believe that is not fully what vajonam intended. To have the feature fully nicely, it would be good if the UID / GID could be injected at runtime. For example, see the images over at linuxserver.io: https://hub.docker.com/r/linuxserver/mariadb — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFHNJZ4HQAYTA7FK5BCKDRJJUOZANCNFSM4LTVG42Q> .

[LongLiveCHIEF]

Good news! This is actually supported in the images we published a few days ago!

First, you should be aware that LinuxServer.io's PUID and GUID were implemented prior to docker's support of the --user flag in docker run. A note from their own docs on understanding puid and pgid:

We are aware that recent versions of the Docker engine have introduced the --user flag. Our images are not yet compatible with this, so we recommend continuing usage of PUID and PGID.

This is going to be related to #10, in that the nature of this application and docker don't really go hand in hand. The only reason you would need to use the --user flag is if you were running plugin installs from the octoprint interface. That is not, however, the way docker is meant to work. However, I've documented 3 techniques below that are just as quick easy as PUID/PGID with linuxserver, and are native to docker.

Best Practice (recommended)

The truly best approach is to use our images as base images, and install plugins in RUN pip install plugin-name commands in your own dockerfiles, enabling rootless running of your final image.

Alternative to building a Dockerfile of your own

The alternative to the approach above is to spin up the octoprint image, run the plugin installation from the interface, and then use the docker commit command to save your unique version of the container as a launchable image, (which you will not run as root by default)

Because octoprint will not run as root, we are forced to use the USER command in the final build stage, and that makes --user a no go.

Native PUID/PGID with docker

There is however, a supported option if you truly want host to container ownership and editing control of config files. I will describe that here below, and will make this a documenation issue so that this gets added to the docs for the README.

What you'll want to do is enable "userns-remap": "<your system username>" in your /etc/docker/daemon.json file, then restart the docker daemon.

You'll then want to run a usermod command to add the uid of 1000 as a subuid for your user. (this uid is used in octoprint container, and the standard uid used for rootless container images compatible with secure docker swarms and secure k8s clusters)

run the following commands in the order given below before you start the octoprint container, and you'll be good to go:

The way to do that is to run the commands in the order below:

$ username=$(whoami)
$ uid=$(id -u "$username")
$ gid=$(id -g "$username")
$ lastuid=$(( uid + 65536 ))
$ lastgid=$(( gid + 65536 ))

$ sudo usermod --add-subuids "$uid"-"$lastuid" "$username"
$ sudo usermod --add-subgids "$gid"-"$lastgid" "$username"

This will have an identical effect to the PUID and PGID from linuxserver images.

[LongLiveCHIEF]

The only reason you would need to use the --user flag is if you were running plugin installs from the octoprint interface. That is not, however, the way docker is meant to work.

Actually I mispoke slightly. You wouldn't need to use the --user flag for this. There's really no reason to pass a user to this image unless you intend to edit files mapped into a container volume. I'd argue there's no reason to do this with this application, but my stance is always "don't make unilateral decisions on behalf of your users", so I intend to support and document best practices for doing that anyways if that is something you desire.

The approaches described above are idiomatic and native to docker, will be stable/supported, and are eventually the way you'll see linuxserver containers go as well. (see note at top of my last comment)

[LongLiveCHIEF]

updated formatting in my doc comment above, and will turn this issue into a documentation issue.

[hakan42]

The only misgiving I have with this way is that you can't have differing user mappings.

For example, I would like my openHAB docker images to run with UID 1003, the OctoPrint image with 1004 and the whatever-other-service image with user 1005. To my knowledge, this can only be done if we somehow pass environment variables to the docker image and the image itself does a "su" to that user before running the packaged software

This becomes especially relevant if the images are linked with volumes that keep user data which, in the best case, would map to the UID of the matching docker service.

[vajonam]

The only misgiving I have with this way is that you can't have differing user mappings.

For example, I would like my openHAB docker images to run with UID 1003, the OctoPrint image with 1004 and the whatever-other-service image with user 1005. To my knowledge, this can only be done if we somehow pass environment variables to the docker image and the image itself does a "su" to that user before running the packaged software

This becomes especially relevant if the images are linked with volumes that keep user data which, in the best case, would map to the UID of the matching docker service.

Yes agreed. I have different users that I would like to use for various users. 
just tried the userns-remap issues which changed the user and so I wasn't able to see any my older images :-).

[LongLiveCHIEF]

If you want to run octoprint as a different host user, just run it as that host user (su - whatever user). That's the whole point of the way it was built. Again, the only reason to do user-ns remapping is if you wish to edit files created by octoprint that are host:container mapped volumes.

Remember, this is the way the rest of the world is moving with image/user/security direction, as more and more solutions for container platforms require rootless images. Typically, if you wind up having to change the UID/GID of a non-root user inside the docker container, then it's an indicator there's a better approach, or that you're doing something that defeats the purpose of having a docker container to begin with.

To my knowledge, this can only be done if we somehow pass environment variables to the docker image and the image itself does a "su" to that user before running the packaged software

That's not the only way, and not even a recommended or secure way. The ENTRYPOINT command can be used to run a script that detects the uid given to start the process (which can be passed via --user flag). We could amend the ENTRYPOINT script to do a check to see if the process is being run as root or otherwise privileged user, and then use a default rootless uid/gid, otherwise use the provided uid:gid from --user.

I'm actually looking into this, but it has ramifications for python and virtualenv and pip installs.

This all gets back to the BEST and Recommended way (and also the way that follows the docker purpose and practices) is to use this image is to use it as a base image in your own Dockerfile, and install/configure octoprint in your dockerfile.

just tried the userns-remap issues which changed the user and so I wasn't able to see any my older images

The script I gave above is a convenience script that will map a range of all useable uids above the uid of the current user as subuid's. If you want to map specific subuids to uids, instead of range, you can be more judicious with the ranges given, and you can also use the --userns=someuser flag in the docker run command, to specify to use that range. You can even use the --userns=host flag if needed in other containers.

For more information, read Docker Docs - Isolate containers with a user namespace

All this might seem complicated, but the point is that you only should need this if you are doing things you shouldn't be doing in a container to begin with.

The new images are secure by default, with no additional commands or configurations needed to secure them.

If you're using different users for different processes, it's also designed to do that by default. Just switch to the other user, or create a systemd service and specify an ExecStart entry to run the container and a User entry to run it as the user you want.

Answer me this... are any of you actually editing the files octoprint is creating from your host machine?

If the answer is no, then you can do what you want, you've just been exposed to the hacky ways of doing it that came about before docker added all of those features natively. You no longer have to do anything special to get those features out of the box with your typical docker run command. The challenge is going to be to unlearn what your mental model of the old container execution context was.

[vajonam]

Answer me this... are any of you actually editing the files octoprint is creating from your host machine?

I have just started using Ocotoprint and new to the whole 3d-printing thing! So as of now I don't have much use for the plugins (will do soon). So being able to save the plugin state is nice. but I understand how the plugins work is that they are pip install and so is stored all over the container image. we can possibly install in under ~/.octoprint and they would be saved right?

Another option I am consindering is to try the dockerfile here. https://github.com/nunofgs/docker-octoprint/blob/master/alpine/Dockerfile this uses alpine and the supervisord and allows a bunch of configure-ability, like user etc at launch time (similar to the editing the Entrypoint)

Lastly I am running this as non-privileged user and for this work I had to rebuild my image with the following changes.

RUN groupadd --gid 2500 octoprint \
  && useradd --uid 1006 --gid octoprint -G dialout --shell /bin/bash --create-home octoprint

the UID/GIDS match which user (on the host) I want run this as, and -G dailout allows the app access to the /dev/ttyUSBx port.

[LongLiveCHIEF]

I'm going to re-open this one. I've been exploring ways to keep the current functionality if no --user flag is provided, but to have the entrypoint script do a chown if it detects the uid is different than 1000.

This means you'll be able to run rootless whether or not you pass a --user flag, but still allow you to pass the --user flag.

This one is going to be on the backlog as I have a few other issues planned ahead of this one, but I should get to it this upcoming weekend. (April 4th/5th)

[RyanBalfanz]

Here is another option: #22 (comment)