Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

[Thomas Deutschmann]

Hi,

On 2021-01-04 04:18, Michael Orlitzky wrote:
> It would be nice if this was well-supported by the official way of
> modifying system users/groups; that is, by using an overlay with
> modified user/group ebuilds.

No, this doesn't work:

1) It's conflicting with the goals other have. See Mike's first reply to 
my patch proposal:

> So the main problem I see with doing this is that it becomes
> impossible to reliably make changes to a user in later ebuild
> revisions.

He is obviously looking for a way to allow maintainers to change users 
afterwards. But if we tell people, "If you need customization, fork the 
user/group ebuild in your overlay" we will disconnect these users from 
future changes.


2) Thank you for outlining the process how to make changes to users 
using the new acct-* way. It's a nice 'hack'. But it is an own, new way, 
which makes Gentoo special, unique. And this creates additional problems:

This maybe work for your local system. In environments where everything 
is Gentoo and everyone knows Gentoo. But in today's world you are using 
configuration management tools like Ansible, Puppet, Saltstack, Chef...

People who are not necessarily familiar with every implementation detail 
must be able to write configurations (recipes) and the used tool is 
supposed to take care of the differences. In the end, in the ideal 
world, you are just looking at your code describing a state the system 
should have.

But this doesn't work if you make Gentoo so special that you will break 
most tools, will require adjustments or special Gentoo support just for 
stuff Gentoo is doing differently and like everyone else.

Don't get me wrong here: Yes, these tools already have to implement USE 
flags for example which are unique for Gentoo. But stuff like user 
management isn't or should *not*.

When you will get LPIC certification one can expect that you have some 
basic knowledge in Linux stuff allowing you to do common tasks on all 
different Linux systems. Now there comes Gentoo where you aren't allowed 
to use standard Linux tools like 'usermod' when deploying another 
service if you don't want to risk that your service will go down when 
following best practice and do regular world upgrades. Really?


3) More important, the idea of forking acct-* packages whenever you need 
to make modifications don't scale. Like I already outlined in February 
2020, you cannot create overlays for each different user configuration:

I.e. using memcached/redis: You grant permission to socket via group. So 
you put other services belonging to that application you are deploying 
into your user running the key value store. Do you really expect that 
one would create multiple overlays per application using one of these 
services? How would you maintain hundreds of overlays? How would you 
keep track that each box will use the correct overlay to get the 
specific customized acct-* package? How do you deal with scenarios where 
you don't just deploy single instances?

Again, I understand the acct-* fork idea. But I think we have to admit 
that this will only work for the local system or small environments.

For any professional environment this won't work nor scale.


4) Yet we have to talk about the idea in general that it is really not a 
good idea to automatically make changes to the user if you run the risk 
of overwriting changes explicitly made by the system administrator.

It's one thing that multiple local users will get removed from portage 
group when you remerge acct-user/portage, but if you kill services 
because package maintainers are pushing their vision of how to run the 
package, it's not.


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