Introduce abuild-common account like it is on linux #6827
Conversation
… implementations Note: the UID and GID 399 were chosen to stay compatible with SUSE Open Build System (OBS) standard account since workers in a big build farm tend to share networked resources and benefit from having same IDs. On IPS side, there potentially may be a collision with existing user account on the system where this package is installed (although the probability is low, assuming that build workers are deployed in zones or other deployments doctored for the purpose), and pkg(5) feature in OpenIndiana/pkg5#90 addresses it by ensuring that such a collision, if it ever happens, does not automatically introduce a problem into a system.
|
As commented above, at least initially it is not in the dependencies because not all users/deployments would have a worker on same machine/zone/... as the Jenkins controller instance (and potentially might have someone else defined there at these ID numbers). Although for "least surprise" might make sense to have these account known on any CI-related systems, if only to preclude someone else grabbing the numbers. |
|
FWIW, as discussed in IRC a couple of months ago, but not in this PR in particular, we might want to bump the lowest ID for (new) end-user deployments to be 1000 or 1001 for consistency with modern Linux and BSD distros, and so have more IDs that we can dedicate to system service accounts. For some time there would be an issue of legacy deployments that do have lower-numbered users, but at least such situations would not proliferate then. |
I agree. Can you make a PR for that? |
I am not sure really :) From that IRC discussion it seemed that part of the numbering choice (non-system starts from 100) may be buried in tools, e.g. illumos-gate code, although it is possible that some or all of that is tunable with files in CC @jclulow @citrus-it @ptribble and others welcome :-) But also, worth noting that this question is separate from the merits (and merge) of this PR :) |
|
Regarding UID/GID starting from 1000+, moved that bit to discussion #6833 Closer to this PR, IIRC there was a suggestion to start populating reserved service IDs from roughly top of the range (with an offset for people who already did locally), so say from 950 down to 200, which would last us some years. For this particular "abuild:399" mapping, it is proposed for compatibility with existing build systems where illumos-based systems can participate or have other roles, as noted above. |
|
@AndWac Any opinions against? Otherwise I'll merge tomorrow. |
Toasterson
changed the title
The original use-case for this was to allow easier and standardized setup of automated builders with:
Jenkins worker (as SSH Build Agent) on same system as the Jenkins controller instance, so build processes run with separate account and privileges than the server which manages the builds.
Jenkins Swarm worker (PR pending) that runs as a service in some system prepared for the builds - probably scratch or persistent zones, or vagrant-like OVAs that people can run and contribute compute resources to a shared project, or something similar. Such services need to run as some system account and have a more urgent need to have the account defined systemically.
Notably, this idea was planned though not productized since early work on the packaging and SMF for Jenkins in OpenIndiana, so we only defined the
jenkinsaccount for the controller server instance (which insecurely can be used on the same system to run builds too, and semi-insecurely on other systems/zones - depending on the level of filesystem sharing).Recent community work added another use-case with #6824 - that one also needs some account for the builder to run as; could as well be a standardized account we propose for our users and ourselves.
Note1: the particular UID and GID numbers "399" and the name "abuild" were chosen to stay compatible with SUSE Open Build System (OBS) standard account since workers in a big build farm tend to share networked resources and benefit from having same IDs, and my original use-case was just that :)
Note2: This
abuildaccount is not a use-case constrained to Jenkins builds, but to any automated build setups. Could be OBS, buildbot or some other scripts for that matter. Same situation as our commonwebservdaccount being shared by apache, nginx, tomcat and others. Actually, as of this PR, this package is not forced as a prerequisite for Jenkins-Core (server) installations and secure setup of workers is left to the end-users. It is a prerequisite for Jenkins Swarm package in #6828 though.On IPS side, there potentially may be a collision with existing user account on the system where this package is installed (although the probability is low, assuming that build workers are deployed in zones or other deployments doctored for the purpose), and pkg(5) feature in OpenIndiana/pkg5#90 addresses it by ensuring that such a collision, if it ever happens, does not automatically introduce a problem into an existing system.