Re: [gentoo-dev] RFC: Userkit.eclass

[Alan McKinnon]

On 29/11/2016 23:49, William L. Thomson Jr. wrote:
> On Tuesday, November 29, 2016 10:40:20 AM EST Michael Mol wrote:
>>
>>
>> Highly detailed lists like that--used as a broad standard--are a bad idea.
>> They represent a single synchronization point that everyone must adhere to.
>
> That is a statement based on opinion. You say it is a bad idea. I say it is
> necessary and needed. Otherwise wrt to Gentoo ebuilds can stomp on each other.
> Using same GID or UID in more than one ebuild causing problems. There has to
> be something know so others do not use ones others are already.

Why would you end up with duplicated UIDs and GIDs? The only real ways
that can happen is
- ebuild "edits" passwd and group directly using echo/sed and the like.
- ebuild runs useradd|groupadd specifying the uid/gid as arguments

Both of which are silly. Just use useradd/groupadd without uid/gid
arguments. The utility will make sure the uid/gids are non-duplicate,
and ensure they are <1000 or whatever for system accounts

>
>> That means that every prospective adjustment to the list requires active
>> maintenance. That means that for every new daemon someone writes, they have
>> to go through an admissions process. For every contentious fork of a
>> project, you risk conflict over who the designated contact for the
>> assignment should be.
>
> If they package such in Gentoo someone is making a call as to what UID and GID
> should be used. If you think about it from packaging said new daemon in
> Gentoo, it is a MUST.

How do you intend to MAKE devs follow it? More eternal bike-shedding?

> If it does not exist, should it be entirely random from the packager
> perspective? What if they use a GID/UID specific to them and not others.
>
> There has to be some standard some consistency in Gentoo.

Who cares what the uid/gid is? There's a range of about 950 to chose
from. The way to ensure a filesystem object has the correct owner and
group is by using chown/chgrp.

Except for a few cases out on left field (like nfs shares - a problem
that nfs must fix) you don't really care what the uid/gid is, as long as
it's not duplicated. The thing you care about is the NAME

>
>> It adds a large bureaucratic load on everyone. Every itch some developer
>> thinks about scratching has to be weighed against engaging with some
>> process- laden entity. Maybe they'll participate, but they likely won't.
>
> Gentoo shines at bureaucratic load. That may be one of the only things Gentoo
> is really good at, needless bureaucratic loads that just slow things down and
> fracture the community, exherbo, funtoo, and likely others...
>
> This is not needless bureaucracy , this is necessary.

This is a joke right?

>> Have you watched the IANA ports assignment registry over the years? Consider
>> how many services and tools you've seen that *don't* respect it.
>
> Yes, how often to ports < 1024 change? Hardly ever.... Proving the exact point
> why this is needed. People can change them themselves but 99% of the time its
> to some other port > 1024.
>
> Why is there IANA port assignment registry in the first place? Likely for a
> similar reason.

It's so that things like browsers, email tools and the like can drop
:<port> for the most part and be reasonably sure stuffs will still work.

Of the 65535 +-1 possible port numbers, only the first 1024 are truly
important, and of those less than about a quarter are in common use
(wild guess).

The next 10,000 or so are not standards by any means, just a list of
stuff that happens to have been seen in the wild. Apps can and do pick
any old port they feel like - witness the several things that will use
5000 out the box. Is this a problem? Not really, as very very few
machines out there will install two apps both trying to use port 5000 by
default.

The top 45,000 - well that's a free-for-all. Mostly only used as source
ports used by apps trying to contact other apps, and not by listeners.

When looked at IANA port assignments in this light, it really does seem
to be a case of the minimum necessary bureaucracy to make things mostly
nicely most of the time, and not at all a case of bureaucracy to
standardize things as you seem to be arguing.

>
>> All of this is why we use identity management tools like LDAP in the first
>> place. Heck, it's why we have passwd and group files for mapping names to
>> ids and didn't simply hardcode system IDs decades ago.
>
> LDAP typical manages user accounts not system. If the LDAP server is not
> reachable you would make a system completely nonfunctional if it relied on
> LDAP for system accounts.
>
> Also needed from a file sharing stand point of view if sharing parts of a
> system across others. You need consistent GID/UID mappings or things like NFS
> will have lots of problems.

NFS is an edge case. Maybe edge is not the best possible adjective here,
but it certainly isn't the one killer app that requires the whole
uid/gid scheme needing to be locked down.

People running into NFS uid/gid problems can figure out their own ways
to deal with it, (and that doesn't always imply mapping everything to
root plus norootsquash...)

> Package a few things in Gentoo that need a UID and/or GID and you will start
> to understand the problem from a operating system packager perspective.

I have packaged a few things in Gentoo (privately only), and written
more shell installers, puppet manifests, ansible playbooks and user
account deployers than I care to recall; I've never run into this
problem that I couldn't solve trivially - usually by just knowing the
username|groupname and looking up the corresponding uid/gid. Really,
it's just data mapping and we have tools to do the lookup real fast.

-- 
Alan McKinnon
alan.mckinnon@×××××.com