notting(a)redhat.com (Bill Nottingham) writes:
As I'm sure you're aware of, historical Red Hat policy has
been
(watch me forget part of this):
- users are 'registered' when a package wants them, doled out
by hand, and recorded in a documentation file.
Yep; but IMO unpractically in the Fedora Project (setup is Fedora Core,
while a lot of users will be created in Extras). And because of the
limited UID-range (0-100) for such UIDs, the pigeon hole principle will
be violated.
This is currently in the setup package, uidgid file.
- users and groups are *not* deleted on package uninstall; as they're
unique, that's not a big of a deal.
| $ rpm -q --scripts postgresql-server
| postuninstall scriptlet (using /bin/sh):
| ...
| userdel postgres >/dev/null 2>&1 || :
Same for named, wnn, pvm, rpm, radvd, nscd, rpcuser, nfsnobody, xfs,
canna.
A case for bugzilla?
- users and groups are *not* reused. Even if the old package goes
away.
With dynamic creation, they *are* reused. The current 'useradd -r'
implemention uses low UIDs (<100) also, when UID 499 is in use.
As for what's doled out, the id ranges in the system are:
- 0-100 - system users
- 101-499 - reserved for local sysadmin use
- 500+ - useradd starts adding users here
Yep; braindead LSB requirements...
Obviously, limiting things to <= 100 makes things somewhat
crowded.
Currently, there are 44 UIDs and 32 GIDs free, unless I missed one.
Oh yes, I just did a 'wc' on it and come to 71 UIDs therefore. But I
would enforce that for each user a group with the same name and GID
shall be created (and vice versa). So you are coming somewhere into the
area of 70 reserved slots.
That's actually more than I thought there were, but it's
still a
number that certainly can run out in the future, depending on how big
the package list explodes.
Nearly all of my server-packages (lots are unpublished) are creating
special users so that I will need around 15-20 UIDs ;)
One issue with the proposal as mentioned:
- the IDs still will not be constant across systems; it will still run
into the filesystem sharing issue as mentioned on your dynamic user
page; if the different systems choose a different base, they'll get
different IDs
With a central configuration management (e.g. cfengine), the UID will be
unique. E.g. you can
| copy:
| ..../baseuid dest=/etc/fedora/usermgmt/baseuid ...
and all your machines will use the same base for the relative UIDs.
The administrator can set the value in baseuid accordingly the local
system policies.
The simplistic proposal is, when necessary, to simply expand
the range of 'system' users.
Wow---changing the hotloved LSB... Can become an interesting task.
Obviously, anything you do here is going to run into established
practice
somewhere,
My fedora-usermgmt package defaults in the current version to the legacy
method (ignore the semi-static UID). With 'alternative' magic, honoring
of the baseuid file can be enabled.
Enrico