Upgrading RPMs (in this case, XFree86-xfs) may cause
their UID/GID's to change unnecessarily. This might be
caused by user IDs 100<x<500.
This seems to happen because the user is first deleted w/
userdel and then added w/ adduser. I was wondering
if RPM uninstall scripts could first check which uid/gid
the user (e.g. xfs) is using, and when adding him
try to use his old UID:GID first (and if that doesn't work,
perhaps try to use whichever the algorithm decides).
This matter mainly concerns the people who use Linux in a
heterogenous Unix environment w/ shared user UID/GIDs.
Tweaking the RedHat's system UID/GID's down to like 80-100
will be much more difficult since RPM upgrades don't "honor"
these changes at all.
I think there was an open letter or something about RedHat
Linux using GIDs and UIDs >100 for system accounts. Using
something a range like 50-80 would seem pretty much safer to
me when trying to get people to use RHL in aforementioned
heterogenous Unix environments.
This should not happen. The xfs user is created before the package
gets installed, and rpm uses only symbolic names ofr files ownership.
What problem did you exactly encounter and how can we reproduce it?
There seems to be a misconception here on my part. The UID/GID change
wasn't actually caused by useradd/userdel scripts in XFree86-xfs RPM.
What really happened:
1) XFree87-xfs was installed as usual, it gets UID/GID's like 300-400
(that range seems pretty standard for RH).
2) The box is included in a site-wide password/user account
synchronizing scheme, and all UID/GID's above 100 are removed from
passwd files. To avoid the problem, I should have moved xfs account
to UID/GID below 100.
3) The RPM is upgraded and a new xfs account is created (with
non-previous UID/GID's, naturally).
Still my (and other people's) concern about using UID/GID's 100<x<500
for system configurations is IMO a valid one.