On Wed, 2017-11-08 at 07:35 -0600, Sergei Gerasenko wrote:
Thank you, William. I currently don’t have MMR set up, but I think
should not be a hard to do. Currently, I just spun up a VM and
installed 389-ds on it. The reason why I want to simulate this is
because I don’t quite understand the technique Redhat employs to
resolve the conflict. If you look in that section (18.104.22.168), you
will see that they first rename the nsunique+uid attribute to
uid=NewValue keeping the old RDN and then delete the uid=NewValue
along with the conflict marker. The deletion is done under the new dn
I think I now understand why the rename has to happen first. Since
there are in that scenario two “adamss” users, if we just rename the
second into “new” and delete the old RDN, it will delete the first
“adamss” as well, right?
Not quite. When we have this scenario:
T0 Add E1
T1 Add E2
To make this easier, let's call the "E1" and "E2". They are the
entry, but the number denotes the server they were added on. (ie
uid=adamss for both E1 and E2)
So in this case, when we replicate the change from M2 -> M1 (and vice
versa), then what happens is we rename E2 from "uid=adamss" to:
And add the objectClass (nsTombstone)
E1 however, remains as uid=adamss, and is not altered.
So the admin then when they realise has to:
* Leave this alone. Purging will clean the E2 conflict later, so E1
* If they want to revive E2, they need to delete E1 (or move it), then
move E2 to the original RDN.
Also, and this is more of a general LDAP question, in the same
article they talk about removing dangling RUVs. They do a search
But the ldapsearch command doesn’t specify the whole path. Instead,
it’s just -b cn=config cn=replica. How does the server find replica
under mapping tree if we only specified the base of cn=config?
I'm not sure I completely understand the question sorry.
We only have one cn=replica per mapping tree entry. IE a suffix
(dc=example,dc=com), can only have one cn=replica. And that cn=replica
contains all it's RUV's in it.
When you do say:
ldapsearch -b cn=config '(cn=replica)', that's a subtree search for all
the "cn=replica" under cn=config tree, so we'll show all the replica
details for all mapping trees,
Does that help at all?
Thank you again,
> No problem. I think there is an easier way to simulate this.
> Make sure you have MMR setup (IE agreement from M1 -> M2, and M2 ->
> Then on both, there is an agreement object, something like:
> To that object on *BOTH* masters add:
> nsds5ReplicaEnabled: off
> This will pause all replication.
> Now, add your "user1" to both M1 and M2. Try to make them have the
> DN, but different attributes like:
> description: m1
> description: m2
> Next, on both masters set:
> nsds5ReplicaEnabled: on
> This will trigger a replication update. You should have conflict
> entries on your servers now :)
> Anyway, in reality, it's rare you'll ever see conflicts like this,
> I'm glad you are researching this so thoroughly,
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
Red Hat, Australia/Brisbane