> 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@lists.fedoraproject.org >> <mailto:389-users@lists.fedoraproject.org> >> To unsubscribe send an email to 389-users-leave@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@lists.fedoraproject.org > <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > <mailto:389-users-le...@lists.fedoraproject.org>
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
