Docker: Do not use user ID 1000 for jenkins

[amitsaha]

Most distros would start with 1000 for the non-root users, so use something else, say, 2000 as the user id for jenkins.

For example:

• Debian: https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2
• Fedora: https://fedoraproject.org/wiki/Features/1000SystemAccounts

Submitted a PR: https://github.com/jenkinsci/docker/pull/153

[carlossg]

why does it matter? you need to use -u with docker run anyway

[ghost]

@amitsaha ... A solution how to modify uid for your volume mounting needs.

If you are not satisfied with the default

$ docker run --name jenkins -d jenkins:1.609.3; docker exec -it jenkins id -a; docker stop jenkins; docker rm -vf jenkins
uid=1000(jenkins) gid=1000(jenkins) groups=1000(jenkins)

Then extend your own Dockerfile and use that instead.

FROM jenkinsci:1.609.3

# root is required to modify uid
USER root

RUN usermod --uid 2000 jenkins
RUN groupmod --gid 2000 jenkins
RUN chown -R jenkins:jenkins "$JENKINS_HOME" /usr/share/jenkins/ref

# restore ENTRYPOINT to startup as jenkins user
USER jenkins

[amitsaha]

@carlossg Not sure what you mean. I don't _need_ to use -u. It matters because if I decide to volume mount a host directory as /var/jenkins_home, I will also set the permissions of the host directory to be r/w by jenkins user which is user ID 1000 presently. However, on my host the first non-root user also has 1000 UID. Do you see the issue?

[carlossg]

I do not see the issue, the default is 1000 but you can run as whatever user you want, don't even need to change the Dockerfile

$ mkdir /tmp/jenkins
$ sudo chown 2000:2000 /tmp/jenkins
$ docker run -u 2000 -v /tmp/jenkins:/var/jenkins_home jenkins
Running from: /usr/share/jenkins/jenkins.war
webroot: EnvVars.masterEnvVars.get("JENKINS_HOME")

[amitsaha]

Sure. That would work. But why not set the jenkins user id to something
less controversial or worrisome?
On 11/10/2015 6:38 PM, "Carlos Sanchez" [email protected] wrote:

I do not see the issue, the default is 1000 but you can run as whatever
user you want, don't even need to change the Dockerfile

$ mkdir /tmp/jenkins
$ sudo chown 2000:2000 /tmp/jenkins
$ docker run -u 2000 -v /tmp/jenkins:/var/jenkins_home jenkins
Running from: /usr/share/jenkins/jenkins.war
webroot: EnvVars.masterEnvVars.get("JENKINS_HOME")

—
Reply to this email directly or view it on GitHub
https://github.com/jenkinsci/docker/issues/154#issuecomment-147166717.

[carlossg]

sorry, I don't see how 2000 is better than 1000 or any other randomly picked number. It has been using 1000 for a while so I wouldn't like to break existing usage without a better reason

[sgutermann]

@carlossg, doing a:

docker run -u 2000 -v /tmp/jenkins:/var/jenkins_home jenkins

does get jenkins running. Yes. Works.

However inside the container the user is then "2000" with no name. Try using one of the SSH Plugins. No matter how I twist it the keep running the gradle script through the sock and that tells me "Hey, who do you think user 2000 is?" ... just a bit different wording.

Or am I missing something obvious?

[carlossg]

what do suggest then? any user id is going to have that problem

[polarathene]

fixuid can probably work for resolving your issue. It will reassign the containers uid:gid(via a config) to the given uid:gid from the --user option, applying chmod to any files it the internal user has ownership over afaik. Should also no longer cause the issue you're experiencing with the lack of a recognized user name/home.

At least that's what I understand it to do. I haven't got around to trying it yet. I don't use this image personally, just came across it via google -> #112 .

The main issue users are experiencing I think is related to network privileges when you're no longer a system user(<1000 usually?), which prevents things like ports <1024 from being possible to bind iirc? The SSH plugin is presumably trying to bind/open something like port 22(SSH)? You could probably configure that to use a port >=1024(eg 2222), but would need to make sure that whatever connects to it uses that port number too instead of assuming 22.