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

[Michael Orlitzky]

On 12/26/19 9:41 AM, Thomas Deutschmann wrote:
>
> 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?

Yes; if we want to be able to add/remove groups in acct-user ebuilds,
then that's the only possible thing it could do.


> 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?

That's right, but you're making it sound worse than it is. You also
cannot use known default tools like rm, mv, cp, and your text editor to
change things installed by system packages, because those changes will
get overwritten the next time that the package is upgraded or
reinstalled. Now user/group management works the same way.

If you want to change something that belongs to the system, you override
and tweak the package that installs it. It's consistent, and you don't
have to tell people to install puppet/salt/etc. as a special case just
to make users work like everything else. Those were always band-aids for
the lack of a better way to do it.


>
> 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?!

You don't need them any more, there's a better way to do it.


> 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... ;]

I don't completely understand your example, but it doesn't sound like
something that should be particularly hard. Can you elaborate before I
stick my foot in my mouth?