Enrico Scholz (enrico.scholz(a)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