Red Hat Bugzilla – Bug 451116
make sure master, replica uses different sequence of numbers.
Last modified: 2015-01-04 18:32:47 EST
on a master-replica setup, the configuration is not by RANGE yet. looks like
they are both starting off with the same number.
On the master, I did ipa-adduser s1 (got 16724). did ipa-moduser to 16728. did
ipa-adduser s2 (got 16732).
on the replica, I did ipa-adduser t1 (got 16724). 16724 is not used. so good.
But looks like they both are not returning any type of gaps in between them.
david - to note this in release notes
My take on this:
In an MR setup, if you create a user on the master and then another on the
replica, there's every chance that they will end up with the same userid if no
replication has occurred inbetween times. Is this what's happening? If not could
somebody explain it a bit better?
I don't know what "the configuration is not by RANGE yet" means.
From a customer's perspective, what's their "workaround"? Do they just need to
be aware that this can occur and to double-check userids, or to force a
replication before they start creating new users? How can they "make sure the
master and replica use a different sequence of numbers"?
Added to release notes.
davido - ignore comment#3.
the following is from simo's email.
Writing on the train so I can't update 451116 but here is some explanation.
The way dna solves the problem of creating unique uids across multiple masters
is by making sure each master choose from a different pool of IDs.
The initial solution Pete coded was fixed into a scheme that let you define the
number of masters (default 4) and then simply skip N masters IDs every new
allocation. This solution left huge holes in case all allcoations were happening
against a single master (3/4th of IDs were wasted). It also required to change
the starting ID so that (baseID + N masters) resulted in a different number on
We never ended up making the code to automatically change the base ID when
creating a replica so all masters were basically allocating from the same pool.
Even worst the original plugin didn't check if the ID was already in use at
least locally so duplicates were the norm.
I modified the plugin to work both this way or to simply increase monotonically
and always check for duplicates before assigning any ID.
What we still miss although is to change the configuration on replicas so that
each replica assigns IDs from a different range.
Right now all servers try to assign IDs starting from 1101 up to 1,000,000,000.
What customers need to do until we fix this in the replica installation code is
to change the dna plugin configuration on replicas to use a different set of
ranges before starting using it.
What users need to do is to do an ldapmodify to change the plugin configuration
so that on the second replica 1,000,000,001-2,000,000,000 is used and on the 3rd
2,000,000,001-3,000,000,000 is used, and so on.
(Note if customer is still using some incredibly old operating system that
accept only 16bit uids, customer will have to change uids manually to fit it
after user creation, good chances are these system are so old they do not
support ldap anyway, so we do not care in the default case)
The entries to change are these so far:
the attributes to change are:
This is an example ldif to use to change the first replica installed:
These can only be change ad Directory Manager, so the following command might be
used provided the above ldif is save in a file called dna.ldif
ldapmodify -x -D "cn=Directory Manager" -W -f dna.ldif
This command must be executed ONLY on the first replica, we do not want to
change all replicas (or even the master) to the same ranges, each replica needs
We are also not required to jump million by million, admins can choose how to
best distribute ranges of IDs across replicas. The only thing admins must know,
although, is that once one master's dnaNextValue reaches the dnaMaxValue value,
that master will stop servicing new IDs and user/group creation may fail. To fix
this all is needed is to assign a new free range to the server that depleted the
ID space. Although given that it is highly unlikely any installation will really
create millions of users, depletion of IDs MUST make an admin check if something
is wrong in their procedures and is using too many IDs, or some such.
updated release notes with background and update procedure.
What is the DS team recommendation on configuring the DNA Plugin to handle this gracefully?
If I'm understanding the issue correctly, you need to configure DNA to automatically transfer ranges between masters. This capability was added to Directory Server in 8.1 I believe. There is some high level info in this on the DNA design page:
The configuration is also documented in the RHDS 8.1 Administrator's Guide:
The actual ranges you choose don't really matter from a Directory Server perspective. The key thing is to ensure that they don't overlap.