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

[Michael Orlitzky <mjo@gentoo.org>]

On 1/4/21 9:46 AM, Thomas Deutschmann wrote:
> 
>> 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.

There's pretty much no reason to change a user's settings unless you've 
completely fucked them up the first time around. This is precisely why 
the original GLEP had mailing list reviews.

If a package depends on a user having e.g. a specific home directory so 
that upgrading the package requires a corresponding revision bump of the 
user, then the package is broken. I tried really hard to document this, 
and to enforce it back when we had mailing list reviews. It's all in the 
devmanual now.


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

You also can't use the standard linux tools to edit scripts in /usr/bin 
without your changes being overwritten. This is no different... some 
things need to belong to the package manager if you want package 
management to work.


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

This is literally the example I gave. Our acct-user ebuilds can be added 
to additional groups based on USE flags. Every server uses the same 
overlay/ebuilds, but different machines get different package.use files, 
pushed out by the configuration management tool.

I understand that creating an overlay with acct-user overrides will not 
be for everyone, so I have no problem with adding an escape hatch. I do 
think it should be off by default though, and that missing future 
::gentoo changes will not be a problem unless some other error has been 
committed first.