Pre-define a user id

[robertbeal]

Configure the radicale user to a set user id (2999) rather than letting it default to 1000.

This gives hosts the option of creating a user (with id 2999) on the host, so that file/folder ownership can match up between host and container.

[Loader23]

I would prefer the option to change it per command rather than hardcode it in the dockerfile. -e USER_ID=0 \ -e GROUP_ID=0 \ Like other Docker apps allow it :-)

[robertbeal]

That's a slightly different concept but one that can be done in addition to this PR. This PR is merely not defaulting the UID to 1000.

Changing the UID and GID upon running the container means you can't run it in --read-only mode as it involves editing /etc/passwd. So while it's more convenient, it's less secure (especially from a production perspective).

It however can be done as a seperate feature to this PR. Using the shadow package and usermod the UID can be changed upon starting the container.

Offering multiple ways of running the container is probably best as it caters to everyone's needs.

[tomsquest]

Hey @robertbeal I (finally) understood what you means with that thing about the shadow pkg and the image run readonly !

I gave a shot at another implementation. What we want is :

"As an Administrator hosting services, I want to run the Radicale image as a user of my host system to solve the volume permission problem. For that, I have to build the image myself with the uid and gui defined".

sudo addgroup --gid 5001 radicale
sudo adduser --shell /bin/false --disabled-password --gid 5001 --uid 5000 --no-create-home radicale

# Then build the image
docker build -t radicale --build-arg=UID=5000 --build-arg=GID=5001 .

(Currently it defaults to uid/gid 1000 (which is another debate, wether uid=0, 1000 and 2999) ;-) )

Another possible solution could be with ONBUILD but I did not play with it.

[robertbeal]

The main problem with building is that you either have to do so on your own environment (and push the image to your own registry so that prod can access it) or you build on your production environment (which isn't ideal either). It means dealing with source code and git pulls etc... and you have to manage updating it all so more responsibility is put on the consumer.

However... it'd be good to offer that option for people that wish to do that. And if they don't want to, then they get whatever the default is.

On my prod system I simply create a user with a matching id. It's not that inconvenient and I would make a separate user for radicale regardless out of good practise. It's as simple as:

sudo useradd --system --shell /bin/false --uid 2999 radicale

[Loader23]

Iam using Docker with QNAP. I don't even have the option to change the uid on creation. And I might change it later via SSH but don't know what sideeffects that may have. Also, building seems not to work (thats why I asked for a config volume :-) ) I have to rely on the docker pull command or I simply can not use it. At least not without alot of effort to get it running somehow.

[tomsquest]

FYI I just merged the Config-volume feature, #8 This should be as latest soon.

[tomsquest]

@robertbeal you're absolutely right for user 2999. I will update this PR after updating with master. I will add some documentation too.

[tomsquest]

I pushed branch user-id (damn, same as yours @robertbeal ). I will make a PR to supersede this one. See: #11

[tomsquest]

@Loader23 this changes won't affect your way of using this container, as you seems to run as root and the use case here is for matching files created in the container with an owner on the host.

[robertbeal]

Nice, just saw all the changes. I'll close this as it's already done!