Usercreation-policy

[Bill Nottingham]

Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: 
> Ok, does this mean that the Fedora Project has a packaging guideline:
> 
> | A package MUST NOT delete users or groups in its scriptlets

We have lots of them. A few of them are even recorded somewhere. :)

> I think too, that most daemons need both a dedicated user and a dedicated
> group.

Depending on what they do, certainly.

> > Sure, there are distribution mechanisms (cfengine, rdist, rsync,
> > whatever-you-like) to keep such files in sync. It's still not
> > universially applicable (i.e., *competely* static is obviously
> > preferred.)
> 
> This is a bootstrap problem. Base-packages (Fedora Core) should have
> static UIDs. Then, the administrator can do the basuid/gid customization
> and install the Fedora Extras packages which are having the described
> semi-static UIDs.

It's still not completely portable across systems without intervention/
cooperation of some sort. I.e., out of the box, it doesn't 'just work'
right.

> > It's allowable by the draft spec:
> >
> > The system UIDs from 100 to 499 should be reserved for dynamically
> > allocation by system administrators and post install scripts using
> > useradd(1).
> 
> 'dynamically allocation' means for me, 'useradd -r' which uses a random
> free UID-slot.
> 
> Using static UIDs between 100 and 500 for Fedora Extras packages will
> break update of existing systems, since those UIDs can be assigned there
> already. So you can not simply expand the range of 'system' users.
> 
> With my baseuid approach the administrator could choose a free area and
> put a fitting value into /etc/fedora/usermgmt/baseuid before doing the
> update.

That will *still* break upgrades, as it will conflict somewhere.

Anything that requires admin intervention in the intermediary of the
upgrade transaction isn't really workable.

Bill