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
