1 |
Hi, |
2 |
|
3 |
thank you for bringing this to the list. |
4 |
|
5 |
I have the same experience which is the reason why I haven't migrated |
6 |
most of my packages yet (which is not a good move because I also didn't |
7 |
post the problem to the list like I wanted *yet*, I only talked to |
8 |
people via private mail, chat or at FOSDEM about that and was working on |
9 |
a proposal I wanted to show next week when I am hopefully healthy again). |
10 |
|
11 |
In short: It was a very bad decision that acct-* stuff is *changing* |
12 |
existing stuff. This must be turned of *by default*. Maybe provide a |
13 |
setting a user can put into make.conf to opt into current, still new, |
14 |
behavior but by default, a package should never ever make changes to |
15 |
*existing* user (unless it knows for sure it was the only source |
16 |
creating that user and nothing was changed since creation which isn't |
17 |
easy to track). |
18 |
|
19 |
My example is a little bit different: |
20 |
|
21 |
Please think about all the systems which are managed using some kind |
22 |
configuration management tool (Puppet, Ansible, Salt, Chef...). It's |
23 |
really common and there's is nothing wrong to make use of usermod for |
24 |
example to alter users. All of the tools I mentioned have 'templates' |
25 |
(=ready to use scripts to set up common software) which will make use of |
26 |
things like usermod. The problem: You never expect that something in the |
27 |
OS will get rid of your changes and will revert to something the package |
28 |
manager believes should be the default. |
29 |
|
30 |
In environments where you only have to deal with Gentoo, we maybe have |
31 |
created something *new* which allows for new possibilities, see |
32 |
https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way |
33 |
|
34 |
However, this is very bad: Configuration management tools are common |
35 |
these days. While we also have systemd which helps at least to provide |
36 |
some kind of interface allowing user to set timezone, time |
37 |
sychonization, hostname and other general settings the same way across |
38 |
different distribution, configuration management tools are also an |
39 |
abstraction layer: You write 'recipes' or 'playbooks', describe 'states' |
40 |
in a general language and the used cfm tool will know all the |
41 |
implementation details. So in the end it doesn't matter if you apply |
42 |
your configuration against Debian, Fedora, RHEL or Gentoo -- the system |
43 |
you run your code against should be in the described state after all. |
44 |
That's at least the idea ;-) |
45 |
|
46 |
Thanks to the new way how we manage user in Gentoo that's no longer the |
47 |
case: Suddenly you cannot use basic tools like usermod to make changes |
48 |
to users anymore because you cannot be sure that these settings won't be |
49 |
reverted. |
50 |
|
51 |
Also, the idea to create *packages* to represent user configuration |
52 |
doesn't scale. I already outlined that issue in [1]. Simple example: |
53 |
|
54 |
You have two services (SerivceA and ServiceB) both using the same |
55 |
package (say www-servers/nginx). We are talking about something like |
56 |
'real application server'. While you can overwrite user/group via ebuild |
57 |
once, you can't do it multiple times for *different* roles. Especially |
58 |
when you have to deal with some kind of 'dynamic' stuff (see the |
59 |
Jenkins' discussion). Creating your own acct-* repository *per role* |
60 |
can't scale (aside the fact that it will be impossible to tell user, |
61 |
"Yeah... for Gentoo you just cannot use 'append user X to group sudo' |
62 |
syntax you use in your cfm tool. Instead you have to fork |
63 |
acct-group/sudo and put user into that ebuild and ensure that this |
64 |
version is installed). Also, don't forget about servers executing |
65 |
multiple roles at the same time: It's easier to describe something like |
66 |
"Make sure user X is in group Y" vs. making sure you have that single |
67 |
acct-* ebuild creating user X or group Y with everything you ever need |
68 |
right from the beginning. |
69 |
|
70 |
tl;dr |
71 |
We need to change current acct-* eclasses to not change things (i.e. not |
72 |
changing home, groups...). At least if user/group were created/modified |
73 |
outside of PM. |
74 |
|
75 |
|
76 |
See also: |
77 |
========= |
78 |
[1] |
79 |
https://archives.gentoo.org/gentoo-dev/message/05c9b211eb18012d16302194a7bc37e6 |
80 |
|
81 |
|
82 |
-- |
83 |
Regards, |
84 |
Thomas Deutschmann / Gentoo Linux Developer |
85 |
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |