Not quite. When we have this scenario:
M1 M2
T0 Add E1
T1 Add E2
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.
cn=replica
under the cn=config
suffix.Note
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,
SergeiNo 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@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
rg
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org