[Freeipa-users] minimum UIDs and GIDs

[Simo Sorce]

On Thu, 2008-10-09 at 20:33 +0100, Nick Gresham wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simo Sorce wrote:
> > On Wed, 2008-10-08 at 16:26 +0100, Nick Gresham wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi,
> >>
> >> I'm a systems administrator at the University of Manchester currently
> >> trialling FreeIPA as an authentication solution for a group of
> >> workstations and HPC machines.
> >>
> >> Generally speaking, I am very impressed, but I was wondering if there
> >> would be a way of setting minimum values for UIDs and GIDs of new users
> >> and groups respectively, so as to keep IPA-generated values from
> >> colliding with pre-existing accounts on machines that we are trying to
> >> make into FreeIPA clients?
> > 
> > Yes, currently it requires a change in the dna plugin configuration.
> > 
> > You can change the attribute 'dnaNextValue' in these 2 ldap entries:
> > cn=Accounts,cn=Posix,cn=ipa-dna,cn=plugins,cn=config
> > cn=Groups,cn=Posix,cn=ipa-dna,cn=plugins,cn=config
> > 
> > You can do that online using the 'cn=Directory Manager' ldap user.
> > 
> > Simo.
> > 
> 
> Many thanks: that worked!
> 
> In case anyone gets stumped by the command needed to access and edit the
> 'plugins' part of the dirsrv tree (as I initially was), for the record,
> I used:
> 
> ldapvi -D "cn=Directory Manager" -b cn=ipa-dna,cn=plugins,cn=config
> 
> I'm assuming that one needs to do this on all replica servers: is that
> correct?

Technically in v1 each replica should be changed so that they have
assigned no overlapping ranges, so given 3 masters you should probably
change config options to reach something like the following
configuration:

A) dnaNextValue: 100000
   dnaMaxValue: 199999

B) dnaNextValue: 200000
   dnaMaxValue: 299999

C) dnaNextValue: 300000
   dnaMaxValue: 399999

This will make 100% sure there is absolutely no chance 2 concurring*
"adduser" operations on 2 different masters will end up creating 2
different users with the same UIDs as each master will use its own pool.

Of course if the same master is always used to create user accounts or
manipulate them there is no risk as internally each master guarantees
the uniqueness of the ids released.

Simo.

*Can also be caused by a temporary pause in replication