On Thu, 2017-11-09 at 13:10 -0600, Sergei Gerasenko wrote: > > 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 > ... > Hey mate, I think this could really help you. I wrote a series of blog articles on starting with ldap. Start here and follow the "LDAP Guide ..." down the left. Hope it helps you understand more about the datastructure. I think it will solve your questions :) https://fy.blackhats.net.au/blog/html/pages/ldap_guide_part_1_foundatio ns.html > > > > > 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 > > > <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproje > > > ct.o <mailto:389-users-leave@lists.fedoraproject.o> > > > rg > > > > -- > > Sincerely, > > > > William Brown > > Software Engineer > > Red Hat, Australia/Brisbane > > _______________________________________________ > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject > > .org <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx> > > _______________________________________________ > 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
