Not quite. When we have this scenario:
M1 M2
T0 Add E1
T1 Add E2
...
Thank you, William.
> 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.
Sorry I wasn’t clear. Below is the excerpt from the article. Note they are saying
“cn=replica” under “cn=config”, but the full DN is dn:
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
That is, cn=replica is not _directly_ under cn=config. Doesn’t cn=…,cn=…,cn=… imply
hierarchy? In other words, I’m confused how ldapsearch could find the replica entry if the
base was specifying just cn=config and not cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
That’s why I think I might have some conceptual misunderstanding about LDAP in general.
Thanks again.
...
List the currently defined and valid replica IDs of all masters which are replicating
databases by searching the replica configuration entries DN cn=replica under the cn=config
suffix.
Note
Consumers and read-only nodes always have the replica ID set to 65535, and
nsDS5ReplicaType: 3 signifies a master.
# ldapsearch -o ldif-wrap=no -xLLL -H
m1.example.com m2.example.com -D "cn=Directory
Manager" -W -b cn=config cn=replica nsDS5ReplicaId nsDS5ReplicaType
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaId: 1
nsDS5ReplicaType: 3
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaId: 20
nsDS5ReplicaType: 3
...
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(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
<mailto:389-users-leave@lists.fedoraproject.o>
> rg
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
<mailto:389-users-leave@lists.fedoraproject.org>