1 |
On Mon, 2021-11-29 at 05:05 +0000, Sam James wrote: |
2 |
> |
3 |
> What I wish we had done (and there's still time to do, albeit belated -- |
4 |
> it's still useful for the remaining big bits like Apache and nginx) is |
5 |
> write a news item explaining the implications and linked to a page |
6 |
> like https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration <https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration> |
7 |
> (which ConiKost created after we discussed how to inform users better) |
8 |
> that explains how to work around/express their preferences/give their own hints. |
9 |
> |
10 |
|
11 |
I agree, and there's still room to improve the user interface as well. |
12 |
For example, I run postfix on all of my machines. A few of them also |
13 |
need to run OpenDKIM, and need the postfix user to be a member of a |
14 |
group that is shared with OpenDKIM, to access a socket. |
15 |
|
16 |
To best integrate with the PM, the solution to this problem is to |
17 |
override acct-user/postfix in an overlay. Ok, no problem. But since the |
18 |
additional group should be optional, it needs to be controlled by a USE |
19 |
flag if you want to use the same ebuild across your entire |
20 |
organization. The implementation details make this a bit ugly: |
21 |
|
22 |
RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )" |
23 |
|
24 |
pkg_setup() { |
25 |
if use dkimsocket; then |
26 |
ACCT_USER_GROUPS+=( dkimsocket ) |
27 |
fi |
28 |
} |
29 |
|
30 |
The extra noise is necessary because "dkimsocket" needs to be added to |
31 |
two arrays, and that can't be done declaratively at the moment. It |
32 |
would be a nice UI improvement if the best solution was less of a |
33 |
headache. |
34 |
|
35 |
|
36 |
|
37 |
> Sorry, I should've been explicit. The main thing I'd like to understand better |
38 |
> from your POV is: |
39 |
> |
40 |
> this isn't new, but you're quite clear you feel that the UID/GID range limitations |
41 |
> are completely arbitrary and without merit(?). |
42 |
> |
43 |
> Whissi essentially says the opposite: https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450 <https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450>. |
44 |
> |
45 |
> I'd like to understand if this is just a result of beliefs about what the PM should/shouldn't do |
46 |
> or if there's genuine problems with continuing to extend the range? |
47 |
|
48 |
Using the rest of the system range (500-999) should pose no problems |
49 |
for anyone, since that's exactly what the old user.eclass will do. I |
50 |
also see no problem with 60001+. I'm skeptical that any daemons have |
51 |
those ranges hard-coded; and even if they do, they're buggy and we |
52 |
shouldn't handicap the distribution over it. |
53 |
|
54 |
More fundamentally, the "user" and "system" limits themselves not |
55 |
written in stone: they are written in login.defs, and are only hints |
56 |
for a few standard tools. Software should not be guessing at them. I |
57 |
think we should try to keep things as consistent as possible with other |
58 |
distributions, operating systems, and standards -- but if it comes down |
59 |
to it, the numbers in the acct-* ebuilds are only suggestions, and it |
60 |
doesn't hurt anything in the long run to suggest a number that might |
61 |
already be taken because login.defs allowed useradd to take it in the |
62 |
past. |