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
signature.asc
Description: OpenPGP digital signature
