Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Thomas Deutschmann]

On 2019-12-26 14:42, Michael Orlitzky wrote:
> So before you push this, I would figure out what you want the Jenkins
> user to look like on your machine, and add an -r1 of acct-user/jenkins
> in a local overlay that configures it how you want. At that point, you
> can drop the usermod calls from your configuration management tools.
>
> For the benefit of those other users, it would be extra nice if you
> could document how to do all that. I recently had to do the same thing
> for OpenDKIM, because the old instructions that were gave were being
> wiped out on upgrades and reinstalls:
>
>   https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way
>
> Then if the home directory is only needed by people who are going to be
> overriding the acct-user ebuild anyway, you might as well leave
> ACCT_USER_HOME at the default and let people set it in their overlays.

Now, after reading the wiki for OpenDKIM I am more concerned than
before: We are also changing groups?!

Let me show you an example:
System has www-servers/nginx installed which created nginx user+group
via user eclass.

Now let's say I have a custom application for which I created user+group
"myapp".

I add nginx user to myapp group to allow nginx to access files from
myapp to serve application.

My current understanding is that during www-servers/nginx migration to
GLEP-81, i.e. when www-servers/nginx ebuild will pull in acct-user/nginx
and acct-group/nginx for the first time, the acct-* thing will do

  local groups=${ACCT_USER_GROUPS[*]}
  esetgroups "${ACCT_USER_NAME}" "${groups// /,}"

which would remove nginx from myapp group to match ACCT_USER_GROUPS set
in acct-*/nginx ebuild which would break my application server. Does
that really happen?

And would I really have to create my own acct-*/nginx user+group ebuild
to mirror my myapp use case? In other words: Thanks to GLEP 81, in
Gentoo, you can no longer use known default Linux utilities like usermod
to maintain your system and make changes to users/groups created by
packages, instead you will always have to 'fork' involved acct-*/<user>
package and adjust for your needs?

Things like

https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
https://docs.ansible.com/ansible/latest/modules/user_module.html

which are commonly used to apply configurations can't be used anymore?!

Which will become funny if you are maintaining multiple systems: On one
system you have said "myapp", but on another system you would have a
second application named "myapp2". So you cannot even share repositories
between your systems anymore or would have to ensure somehow that system
A which acts as application server for "myapp" will only get
acct-*/<user>-<numeric-identifier-for-myapp-cfg> and system B which will
act as application server for "myapp2" will get
acct-*/<user>-<numerc-identifier-for-another-myapp2-cfg> instead?! Not
to mention what will happen if you get a third system which will be able
to run multiple nginx instances, one for myapp and one for myapp2... ;]


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5