thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net said:
That's the point : Fixed uid/gid is often a good thing, I have
many setups
where a bunch of redundant servers access the same nfs share, and I'm in
trouble when I install packages on those servers which create a user with a
non fixed uid, and one gets say 201 and the other 202...
I'm really grateful to know I can expect apache to be uid 48
everywhere, for
instance.
I think there are two cases: standalone machines, and machines that share data.
For standalone machines, the only trouble is when they are re-installed or
upgraded. If the old passwd file can still be read, the problem is easy to
solve: just reuse the old UIDs. When the old passwd file is damaged: you are
in trouble anyway: the user probably created a few accounts which contain
files, and those accounts will need to be hand-recreated with the proper UID
anyway... Having fixed UIDs helps some, but not that much.
For machines that share data, IMHO the proper way is to put all accounts with
distributed files in a UID management thing like LDAP or NIS. It doesn't buy
you much that a few of those UIDs are fixed. Plus, people running such setups
are supposed to be pretty knowledgeable about managing a local UID database.
I'm still of the opinion that fixed UIDs don't solve much, and are not easy to
manage.
In a way, it seems things might be a bit simpler if a username->UID
mapping was stored somewhere in the filesystem, at mount/fsck/umount time...
Ah well, just daydreaming I guess :)
Cheers,
Christian