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(a)lists.fedoraproject.org
> > <mailto:389-users@lists.fedoraproject.org>
> > To unsubscribe send an email to 389-users-leave(a)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(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>
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
rg
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane