non fedora-usermgmt user creation

[Ralf Corsepius]

On Thu, 2006-03-09 at 08:13 +0100, Christian.Iseli at licr.org wrote:
> Enrico Scholz said:
> > alternatives is already used by fedora-usermgmt. But I do not see how
> > this help to install the fedora-usermgmt bits without a Requires:
> > fedora-usermgmt.
> 
> I think we are still not talking exactly about the same thing...
> 
> Let me try to rephrase:
>  1. there are packages (both in FC and FE) that need to create UIDs

I question this wrt. certain details:

a) I question the need to specify "uids by numbers" in general, unless
there are predefined/preallocated uid-ranges, because in a networked
environment each network admin will apply his own strategy/convention of
grouping such uids.

Therefore any assumption on "reserved uids" must inevitably clash
somewhere.

b) I question the need for rpms to use fixed uid-numbers.
rpms always are installed locally and don't have any knowledge about
uids/accounts in a network. Therefore, installing rpms which add uids
will always require additional effort in a network to propagate those
uids/ids into the network.

[Actually it requires to add those uids to the networked uid/id database
before installing the package - This is beyond the scope of rpm]

c) Many packages probably don't need any package specific account,
probably even less will require a fixed numeric uid. Many of those who
really need one, probably actually would be satisfied with an arbitrary,
ordinary user account and do neither need a fix uid nor a reserved one.

>  2. some admins would like to have those UIDs created in a
>     predictable/defined way
Here the question is: locally or network-wide?

For local installation, you never need a predictable uid, all you need
is predictable id within a certain range of uids (You need an id "httpd"
with uid < 100, but there is not need to fix it to a particular uid).

For a network wide installation, you'd need to have network-wide
consistent uid/ids. This doesn't necessarily mean using fixed ids, it
only means you'll have to have a way to propagate those uid/ids into
your network. Allocating a range of uids/ids is the most simplistic and
primitive way, but there are others (Note: you'd also have to reserve
ids (user names), otherwise they are candidates for clashes, too).

>  3. you propose an add-on/wrapper package that allows to do this, but
>     it is non-transparent: packages that want to use your mechanism
>     must have a Require for fedora-adduser.  Thus the packager makes
>     the decision, not the admin
This is what I consider one fundamental flaw in Enrico's approach. He
tries to dictate what admins consider their task.

>  4. when an admin decides to use your mechanism, part of the packages
>     installed will still not be right because all FC and some FE
>     packages do not have the Require mentioned in step 3, and some
>     packagers adamantly refuse to add it
What could be done is to implement fedora-usermgmt as a wrapper to
useradd/etc. which remapping certain useradd calls by mapping requested
uids/ids from a built-in lookup table.

>  5. no consensus is emerging that point 3 is the right thing to do
> 
> What I think some other persons and I are proposing is that you change
> the fedora-usermgmt package to be a complete, transparent replacement
> for useradd (shadow-utils package).  That way, when an admin decides
> to install your package, he knows all the packages he later installs
> will obey the policy he decided to apply when he configured the
> necessary bits in your package.  Packagers then no longer need to
> worry whether to Require useradd or fedora-useradd.  I think that
> would make everyone happy... (maybe famous last words too :-) )
ACK.

Ralf