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