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 it
> 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 (14.23.1.1), 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
> of uid=NewValue,….
>
> 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:
M1 M2
T0 Add E1
T1 Add E2
To make this easier, let's call the "E1" and "E2". They are the same
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:
uid=adamss+nsUniqueId=...
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
survives.
* 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
> for:
>
> dn:cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>
> 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,
> Sergei
>
> > 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 ->
> > M1).
> >
> > Then on both, there is an agreement object, something like:
> >
> > cn=ExampleAgreement,cn=replica,cn=dc=example\,dc=com,cn=mapping
> > tree,cn=config
> >
> > 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
> > same
> > DN, but different attributes like:
> >
> > uid=user,ou=People,....
> > ...
> > description: m1
> >
> > uid=user,ou=People,....
> > ...
> > 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,
> > but
> > I'm glad you are researching this so thoroughly,
>
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
> rg
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
