Dave Brown wrote:
I can see 2 ways to resolve the issue from a Fedora development perspective.
1. Similar to the suggestion you have put forward below - Change UID_MAX
to say 40,000 and change GID_MIN to 40,001. That will stop uids and gids
from colliding and is a pretty easy solution to implement from a change
perspective. Raises a problem tho that what UID will the 39,501th user
have? We cant just increase the UID_MAX as there'll be groups using the
numbers above 40,000 and we'll run into the same problem as we're having
now. Chances are you'll be using NIS or LDAP if you've got this many
users but its probably not good practice to be assuming the user
management practices of the masses.
2. Change the useradd / luseradd code to find the lowest unique uid /
gid combination when creating any new user. This is harder to implement
because it involves rewriting the underlying code of useradd but it is a
more complete and scalable solution because you can change the UID, GID
MIN, MAX values to whatever and it'll still work and users will always
have their uid equal to their gid. I tend to favaour this solution
because of it's completeness and scalability.
Robin / Others - what do you think? Depending on the general consensus
I'll probably submit a feature enhancement request.
In response to Tim and Justin - you'd hope that the CLI and GUI tools
doing the same thing would be using the same underlying code / library
to achieve it so there is consistency across the 2 tools but it looks
like theyre not :o(
Thanks all for your responses.
Dave,
Interesting.
I played with the GID_MIN last night and I found something interesting.
If I use groupadd, it works. If I use the system-config-users tool
and click on add group, it doesn't work. The group added is the next
available GID. If the GID_MIN is set for 5000, I still ended up with
a GID of 524. Thus the GUI tool isn't working as expected. This is a
bug as I see it.
Now to solve the problem of collision, how about having the groups
work from max to min? If GID_MAX is 60,000 and GID_MIN is 40,000,
then the first group used is 60,000. The next would be 59,999, etc.
This would expand the range between possible collision points even
further. If the underlying code is going to be changed, this may be a
better way to go.
Using the reverse method for groups would even remove the necessity to
set GID_MIN unless there are 40,000 unique groups which I find really
impossible.
Hope this helps.
