UID_MIN & GID_MIN changed

[Simo Sorce]

On Tue, 2011-05-24 at 10:45 -0700, John Reiser wrote:
> On 05/24/2011 09:20 AM, Simo Sorce wrote:
> > On Tue, 2011-05-24 at 08:25 -0700, Toshio Kuratomi wrote:
> 
> >> * This could potentially break sites that are currently using the
> >> 500-1000 UID range and rely on the order of allocation of UIDs for
> >> their users on new machines matching with the UIDs on old machines.
> >> (For instance, NFS UIDs on filesystems matching between a box
> >> installed with RHEL5 and a box that gets newly installed with F16).
> 
> > You need to force UIDs in that case anyway, and if you are not using
> > something like NIS or LDAP then you have to mange that manually anyways,
> > so I wouldn't make that a stopper for this very welcome change.
> 
> No, you don't need to force them.  ID 500 and up is the long-standing
> default, so entering a small list of users [and particularly the _first_
> user] in the same order will produce matching UID+GID on multiple machines,
> even without NIS, LDAP, or "management".

Relying on a replay is quite fragile anyways, I don't think we really
need to cater for that case.
If you want to create the same user on multiple systems you really
either sync /etc/passwd file from a "master" machine or you adduser
specifying the uid and gid explicitly, anything else works by accident
already and is not something we really need to care about.

> Changing the floor to 1000 will create extra manual work for such users
> who add a new system.  Also, the change won't produce any net benefit
> for users with NIS/LDAP/etc if they already have IDs in [500, 1000).
> They will continue to use those IDs.

The change will not cause any issue to these users either so it's not a
big deal. After all in most cases anyone setting up an LDAP server has
chosen already saner defaults and decided to allocate user with IDs
higher then 1000 so to not conflict with local user on potential debian
based clients.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York