On Thu, 2006-03-09 at 08:13 +0100, Christian.Iseli@xxxxxxxx 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
