Re: [gentoo-dev] Changes made by acct-* ebuilds

[Thomas Deutschmann]

Hi,

thank you for bringing this to the list.

I have the same experience which is the reason why I haven't migrated
most of my packages yet (which is not a good move because I also didn't
post the problem to the list like I wanted *yet*, I only talked to
people via private mail, chat or at FOSDEM about that and was working on
a proposal I wanted to show next week when I am hopefully healthy again).

In short: It was a very bad decision that acct-* stuff is *changing*
existing stuff. This must be turned of *by default*. Maybe provide a
setting a user can put into make.conf to opt into current, still new,
behavior but by default, a package should never ever make changes to
*existing* user (unless it knows for sure it was the only source
creating that user and nothing was changed since creation which isn't
easy to track).

My example is a little bit different:

Please think about all the systems which are managed using some kind
configuration management tool (Puppet, Ansible, Salt, Chef...). It's
really common and there's is nothing wrong to make use of usermod for
example to alter users. All of the tools I mentioned have 'templates'
(=ready to use scripts to set up common software) which will make use of
things like usermod. The problem: You never expect that something in the
OS will get rid of your changes and will revert to something the package
manager believes should be the default.

In environments where you only have to deal with Gentoo, we maybe have
created something *new* which allows for new possibilities, see
https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way

However, this is very bad: Configuration management tools are common
these days. While we also have systemd which helps at least to provide
some kind of interface allowing user to set timezone, time
sychonization, hostname and other general settings the same way across
different distribution, configuration management tools are also an
abstraction layer: You write 'recipes' or 'playbooks', describe 'states'
in a general language and the used cfm tool will know all the
implementation details. So in the end it doesn't matter if you apply
your configuration against Debian, Fedora, RHEL or Gentoo -- the system
you run your code against should be in the described state after all.
That's at least the idea ;-)

Thanks to the new way how we manage user in Gentoo that's no longer the
case: Suddenly you cannot use basic tools like usermod to make changes
to users anymore because you cannot be sure that these settings won't be
reverted.

Also, the idea to create *packages* to represent user configuration
doesn't scale. I already outlined that issue in [1]. Simple example:

You have two services (SerivceA and ServiceB) both using the same
package (say www-servers/nginx). We are talking about something like
'real application server'. While you can overwrite user/group via ebuild
once, you can't do it multiple times for *different* roles. Especially
when you have to deal with some kind of 'dynamic' stuff (see the
Jenkins' discussion). Creating your own acct-* repository *per role*
can't scale (aside the fact that it will be impossible to tell user,
"Yeah... for Gentoo you just cannot use 'append user X to group sudo'
syntax you use in your cfm tool. Instead you have to fork
acct-group/sudo and put user into that ebuild and ensure that this
version is installed). Also, don't forget about servers executing
multiple roles at the same time: It's easier to describe something like
"Make sure user X is in group Y" vs. making sure you have that single
acct-* ebuild creating user X or group Y with everything you ever need
right from the beginning.

tl;dr
We need to change current acct-* eclasses to not change things (i.e. not
changing home, groups...). At least if user/group were created/modified
outside of PM.


See also:
=========
[1]
https://archives.gentoo.org/gentoo-dev/message/05c9b211eb18012d16302194a7bc37e6


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