Whissi and others raised some points that I think you may have some views on (and I'm interested in hearing them).
On 28 Nov 2021, at 23:26, Michael Orlitzky <mjo@gentoo.org> wrote:
[sinp]
The only problem that anyone has put forth is one that does not exist.
UIDs and GIDs are still assigned dynamically in Gentoo. The number you
type in the ebuild is only a hint: it's the first number that will be
tried during the dynamic assignment. There is no limit on the number of hints, and we will never run out because a conflict is never possible, because the damned things are assigned dynamically.
Is there an actual problem?
<div class="">On 28 Nov 2021, at 23:26, Michael Orlitzky <<a href="mailto:mjo@gentoo.org" class="">mjo@gentoo.org</a>> wrote:</div><div class=""><div class="">[sinp]</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">The only problem that anyone has put forth is one that does not exist.<br class="">UIDs and GIDs are still assigned dynamically in Gentoo. The number you<br class="">type in the ebuild is only a hint: it's the first number that will be<br class="">
All,
I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting for all acct-user and acct-group packages in ::gentoo.
Here are my thoughts about it.
- As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
most of the time.
- I realize that our settings are suggestions, but the values we can
suggest are not infinite. We have run out once, and it is only a matter of
time until we do again.
- If an end user needs to care about the UID/GID, they can easily override
the settings in make.conf.
Thoughts? In particular, I want to hear from folks who disagree with me
about using -1 in the main tree for most packages.
All,
I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting for all acct-user and acct-group packages in ::gentoo.
Here are my thoughts about it.
- As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
most of the time.
- I realize that our settings are suggestions, but the values we can
suggest are not infinite. We have run out once, and it is only a matter of
time until we do again.
- If an end user needs to care about the UID/GID, they can easily override
the settings in make.conf.
In short, I don't think we should be forcing maintainers to pick a
specific UID/GID for every package that needs a user/group. Most of the
time they can set ACCT_USER_ID and ACCT_GROUP_ID to -1.
Thoughts? In particular, I want to hear from folks who disagree with me
about using -1 in the main tree for most packages.
On 29 Nov 2021, at 00:06, Michael Orlitzky <mjo@gentoo.org> wrote:
On Sun, 2021-11-28 at 23:39 +0000, Sam James wrote:
Whissi and others raised some points that I think you may have some views on >> (and I'm interested in hearing them).
I don't want to put words in his mouth, but I think Whissi takes issue
with using the package manager to manage users, period. Not
specifically with our use of a UID/GID hint.
I didn't respond to the first thread because I didn't want to pick a
fight when the correct conclusion (IMO) was already reached. In the
first thread I see only hypothetical problems raised (and a bunch of
people who didn't realize the numbers are only a hint). If any of those problems are real and solved by allowing ACCT_USER_ID=-1 in ::gentoo,
you'll have to point them out.
<div class="">On 29 Nov 2021, at 00:06, Michael Orlitzky <<a href="mailto:mjo@gentoo.org" class="">mjo@gentoo.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Sun, 2021-11-28 at 23:39 +0000, Sam James wrote:<br class=""><blockquote type="cite" class=""><br class="">Whissi and others raised some points that I think you may have some views on<br class="">(and I'm interested in hearing them).<br class=""><br class=""></blockquote><br class="">I don't want to
On Sun, 2021-11-28 at 16:31 -0600, William Hubbs wrote:
All,
I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting
for all acct-user and acct-group packages in ::gentoo.
Here are my thoughts about it.
- As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
most of the time.
- I realize that our settings are suggestions, but the values we can
suggest are not infinite. We have run out once, and it is only a matter of
time until we do again.
- If an end user needs to care about the UID/GID, they can easily override
the settings in make.conf.
In short, I don't think we should be forcing maintainers to pick a
specific UID/GID for every package that needs a user/group. Most of the time they can set ACCT_USER_ID and ACCT_GROUP_ID to -1.
Thoughts? In particular, I want to hear from folks who disagree with me about using -1 in the main tree for most packages.
Let me put this bluntly. Yes, most users don't care. However:
1) if we don't assign static UIDs/GIDs, the few users who care are gonna
be in hell having to assign them all manually. Every single one of
them, on every one of their systems.
2) if we do assign static UIDs/GIDs... what's the problem, again?
Little extra work for a few devs?
--
Best regards,
Michał Górny
On Mon, 29 Nov 2021, Alec Warner wrote:
- If Gentoo adds an acct-user/foo user, and that user already exists
on my system with the wrong UID: the eclass dies[0].
- If Gentoo adds an acct-user/foo user, with uid=12345, and that uid
is assigned to a user on my system already, the eclass dies.
- Some environments are very old, and so real users have unexpected
uids; this includes Gentoo itself.
- Gentoo (the community) used to allocate UIDs to devs in the
500-1000 range and we have 17 active developers with UIDs in that
range. So for example if we allocate one of these UIDs to an acct-*
package; that package will not be installable on woodpecker without modification because those UIDs are already taken.
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.
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?
"UM" == Ulrich Mueller <ulm@gentoo.org> writes:
Also, why would one allocate UIDs in the 500..999 range (1000 is fine, actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.
On Mon, 29 Nov 2021, Alec Warner wrote:
- If Gentoo adds an acct-user/foo user, and that user already exists
on my system with the wrong UID: the eclass dies[0].
I don't think that's correct. The eclass will just use the already
existing UID then (except for the very few acct-user packages that
define ACCT_USER_ENFORCE_ID).
- If Gentoo adds an acct-user/foo user, with uid=12345, and that uid
is assigned to a user on my system already, the eclass dies.
Similar to above, the eclass will dynamically allocate another UID that
is free.
- Some environments are very old, and so real users have unexpected
uids; this includes Gentoo itself.
- Gentoo (the community) used to allocate UIDs to devs in the
500-1000 range and we have 17 active developers with UIDs in that
range. So for example if we allocate one of these UIDs to an acct-* package; that package will not be installable on woodpecker without modification because those UIDs are already taken.
See above.
Also, why would one allocate UIDs in the 500..999 range (1000 is fine, actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.
Ulrich
On Tue, 30 Nov 2021, James Cloos wrote:
Also, why would one allocate UIDs in the 500..999 range (1000 is fine, actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999."UM" == Ulrich Mueller <ulm@gentoo.org> writes:
why do you thing gentoo is everyone's first or only dist on their
network?
or even on any given box?
forcing existing boxen to change just because a new dist is added
is also unacceptable.
for me though, it would be enough if there is something i can add to make.conf to ensure that the acct-user and acct-group builds avoid the
ranges i already use.
that may also work for others.
"UM" == Ulrich Mueller <ulm@gentoo.org> writes:
I was specifically asking about Gentoo infra there.
This is the part of this that I don't understand. If we aren't enforcing
an ID, why do we care which ID to try first? It seems to be an
unnecessary step since users can pick the IDs they want by putting
settings in make.conf.
On Tue, 30 Nov 2021, James Cloos wrote:
Also, why would one allocate UIDs in the 500..999 range (1000 is fine, actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999."UM" == Ulrich Mueller <ulm@gentoo.org> writes:
why do you thing gentoo is everyone's first or only dist on their
network?
or even on any given box?
I was specifically asking about Gentoo infra there.
forcing existing boxen to change just because a new dist is added
is also unacceptable.
for me though, it would be enough if there is something i can add to make.conf to ensure that the acct-user and acct-group builds avoid the ranges i already use.
that may also work for others.
UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always
used for dynamic allocation of system accounts. GLEP 81 hasn't really
changed anything there, except that the ebuild will now suggest an ID to
try first.
Hi,
On 2021/12/01 03:32, William Hubbs wrote:
This is the part of this that I don't understand. If we aren't enforcing
an ID, why do we care which ID to try first? It seems to be an
unnecessary step since users can pick the IDs they want by putting
settings in make.conf.
Because when running clusters of hosts it's useful to have the UIDs for "system" users match. Yes, I know this won't match in a multi-distro
setup, but at least for those of us with clusters consisting only of
Gentoo hosts it will *usually* match. Changing these are possible, but
a nuisance, so having it "just work" for the usual case is great IMHO.
If I'm not mistaken there is a setting to REQUIRE the ID, and that could
even be set from make.conf, or env/ so for those packages that we care
about that (eg, mailman running on top of glusterfs) we use that.
Kind Regards,
Jaco
This is the part of this that I don't understand. If we aren't enforcing
an ID, why do we care which ID to try first? It seems to be an
unnecessary step since users can pick the IDs they want by putting
settings in make.conf.
On Tue, Nov 30, 2021 at 10:16 PM Jaco Kroon <jaco@uls.co.za> wrote:In this case none. So no need for centralized database otherwise.
Hi,So questions from my side are:
On 2021/12/01 03:32, William Hubbs wrote:
This is the part of this that I don't understand. If we aren't enforcing >>> an ID, why do we care which ID to try first? It seems to be anBecause when running clusters of hosts it's useful to have the UIDs for
unnecessary step since users can pick the IDs they want by putting
settings in make.conf.
"system" users match. Yes, I know this won't match in a multi-distro
setup, but at least for those of us with clusters consisting only of
Gentoo hosts it will *usually* match. Changing these are possible, but
a nuisance, so having it "just work" for the usual case is great IMHO.
Does your cluster not have human users?
Do the userids for the human users also not have to match between
hosts in the cluster?
So questions from my side are:
Does your cluster not have human users?
Do the userids for the human users also not have to match between
hosts in the cluster?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 16:21:53 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,615 |
| Messages: | 6,121,086 |