1:33 p.m.
Hi,
I was going through RedHat’s documentation on naming conflicts. Here’s what it says at the
beginning
(https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
<https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...>):
14.23.1. Solving Naming Conflicts
When two entries are created with the same DN on different servers, the automatic conflict
resolution procedure during replication renames the last entry created, including the
entry's unique identifier in the DN. Every directory entry includes a unique
identifier given by the operational attribute nsuniqueid. When a naming conflict occurs,
this unique ID is appended to the non-unique DN.
<>
What I don’t understand is how conflicts can happen at all if the last one wins?
Also, they are talking about solutions to the conflicts and specifically renaming the user
that has nsuniqueid prepended. Does that assume that the conflicting user is actually
another person? Or does it mean the conflicting record denotes the same user? If it’s the
same user, shouldn’t the conflicting record just be removed?
Really confused about the nature of the problem and the suggested solutions.
Thanks!
4:44 p.m.
On Tue, 2017-11-07 at 13:33 -0600, Sergei Gerasenko wrote:
Hi,
I was going through RedHat’s documentation on naming conflicts.
Here’s what it says at the beginning (https://access.redhat.com/docum
entation/en-
us/red_hat_directory_server/10/html/administration_guide/managing_rep
lication-solving_common_replication_conflicts
<https://access.redhat.com/documentation/en-
us/red_hat_directory_server/10/html/administration_guide/managing_rep
lication-solving_common_replication_conflicts>):
14.23.1. Solving Naming Conflicts
When two entries are created with the same DN on different servers,
the automatic conflict resolution procedure during replication
renames the last entry created, including the entry's unique
identifier in the DN. Every directory entry includes a unique
identifier given by the operational attribute nsuniqueid. When a
naming conflict occurs, this unique ID is appended to the non-unique
DN.
<>
What I don’t understand is how conflicts can happen at all if the
last one wins?
The point is that if the last one wins, what do we do with the first?
We don't want to just delete it in case the order of operations was not
what the admin expected. So when you do:
Master 1 Master 2
Time 0 ADD E
Time 1 ADD E
We are going to keep M1 E, and we'll conflict on M2 E - this becomes
the conflict entry.
Also, they are talking about solutions to the conflicts and
specifically renaming the user that has nsuniqueid prepended. Does
that assume that the conflicting user is actually another person? Or
does it mean the conflicting record denotes the same user? If it’s
the same user, shouldn’t the conflicting record just be removed?
Really confused about the nature of the problem and the suggested
solutions.
Thanks!
See above. It's about preserving the duplicate entry incase the
administrator wishes to revive them or see what happened. :)
Hope that helps, Ludwig might have more to say on this.
_______________________________________________
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
7:53 p.m.
Thanks Willam. It does make sense now. I don't know how I could have misunderstood it
:) So thank you again for clarifying it!
> On Nov 7, 2017, at 4:44 PM, William Brown <wibrown(a)redhat.com> wrote:
>
>> On Tue, 2017-11-07 at 13:33 -0600, Sergei Gerasenko wrote:
>> Hi,
>>
>> I was going through RedHat’s documentation on naming conflicts.
>> Here’s what it says at the beginning (https://access.redhat.com/docum
>> entation/en-
>> us/red_hat_directory_server/10/html/administration_guide/managing_rep
>> lication-solving_common_replication_conflicts
>> <https://access.redhat.com/documentation/en-
>> us/red_hat_directory_server/10/html/administration_guide/managing_rep
>> lication-solving_common_replication_conflicts>):
>>
>> 14.23.1. Solving Naming Conflicts
>> When two entries are created with the same DN on different servers,
>> the automatic conflict resolution procedure during replication
>> renames the last entry created, including the entry's unique
>> identifier in the DN. Every directory entry includes a unique
>> identifier given by the operational attribute nsuniqueid. When a
>> naming conflict occurs, this unique ID is appended to the non-unique
>> DN.
>> <>
>> What I don’t understand is how conflicts can happen at all if the
>> last one wins?
>
> The point is that if the last one wins, what do we do with the first?
> We don't want to just delete it in case the order of operations was not
> what the admin expected. So when you do:
>
> Master 1 Master 2
>
> Time 0 ADD E
>
> Time 1 ADD E
>
> We are going to keep M1 E, and we'll conflict on M2 E - this becomes
> the conflict entry.
>
>> Also, they are talking about solutions to the conflicts and
>> specifically renaming the user that has nsuniqueid prepended. Does
>> that assume that the conflicting user is actually another person? Or
>> does it mean the conflicting record denotes the same user? If it’s
>> the same user, shouldn’t the conflicting record just be removed?
>> Really confused about the nature of the problem and the suggested
>> solutions.
>> Thanks!
>
> See above. It's about preserving the duplicate entry incase the
> administrator wishes to revive them or see what happened. :)
>
>
> Hope that helps, Ludwig might have more to say on this.
>
>> _______________________________________________
>> 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
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
12:11 a.m.
Hi,
If I wanted to simulate a conflict the way it’s described in the RedHat documentation
(14.23.1.1. Renaming an Entry with a Multi-Valued Naming Attribute
<https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...>)
with a series of LDIF transformations, what would be the LDIFs? I installed and set up a
389 instance in a VM for this purpose.
I tried adding:
user1
user2
Then I tried to modrdn user2 to nsuniqueid=VALUE+user1, but got this error:
Rename Result: Server is unwilling to perform (53)
Additional info: new superior is identical to the entry dn
The exact LDIF for the ldapmodrdn command was:
uid=user1,ou=People,dc=example,dc=com
uid=nsuniqueid=82d86a81-c44811e7-b207809a-7d9aed98+user1
I’m just getting my feet wet with LDAP, so bear with me.
Thanks,
Sergei
On Nov 7, 2017, at 4:44 PM, William Brown <wibrown(a)redhat.com>
wrote:
On Tue, 2017-11-07 at 13:33 -0600, Sergei Gerasenko wrote:
> Hi,
>
> I was going through RedHat’s documentation on naming conflicts.
> Here’s what it says at the beginning (https://access.redhat.com/docum
> entation/en-
> us/red_hat_directory_server/10/html/administration_guide/managing_rep
> lication-solving_common_replication_conflicts
> <https://access.redhat.com/documentation/en-
> us/red_hat_directory_server/10/html/administration_guide/managing_rep
> lication-solving_common_replication_conflicts>):
>
> 14.23.1. Solving Naming Conflicts
> When two entries are created with the same DN on different servers,
> the automatic conflict resolution procedure during replication
> renames the last entry created, including the entry's unique
> identifier in the DN. Every directory entry includes a unique
> identifier given by the operational attribute nsuniqueid. When a
> naming conflict occurs, this unique ID is appended to the non-unique
> DN.
> <>
> What I don’t understand is how conflicts can happen at all if the
> last one wins?
The point is that if the last one wins, what do we do with the first?
We don't want to just delete it in case the order of operations was not
what the admin expected. So when you do:
Master 1 Master 2
Time 0 ADD E
Time 1 ADD E
We are going to keep M1 E, and we'll conflict on M2 E - this becomes
the conflict entry.
> Also, they are talking about solutions to the conflicts and
> specifically renaming the user that has nsuniqueid prepended. Does
> that assume that the conflicting user is actually another person? Or
> does it mean the conflicting record denotes the same user? If it’s
> the same user, shouldn’t the conflicting record just be removed?
> Really confused about the nature of the problem and the suggested
> solutions.
> Thanks!
See above. It's about preserving the duplicate entry incase the
administrator wishes to revive them or see what happened. :)
Hope that helps, Ludwig might have more to say on this.
> _______________________________________________
> 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
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
12:36 a.m.
On Wed, 2017-11-08 at 00:11 -0600, Sergei Gerasenko wrote:
Hi,
If I wanted to simulate a conflict the way it’s described in the
RedHat documentation (14.23.1.1. Renaming an Entry with a Multi-
Valued Naming Attribute <https://access.redhat.com/documentation/en-u
s/red_hat_directory_server/10/html/administration_guide/managing_repl
ication-solving_common_replication_conflicts>) with a series of LDIF
transformations, what would be the LDIFs? I installed and set up a
389 instance in a VM for this purpose.
I tried adding:
user1
user2
Then I tried to modrdn user2 to nsuniqueid=VALUE+user1, but got this
error:
Rename Result: Server is unwilling to perform (53)
Additional info: new superior is identical to the entry dn
The exact LDIF for the ldapmodrdn command was:
uid=user1,ou=People,dc=example,dc=com
uid=nsuniqueid=82d86a81-c44811e7-b207809a-7d9aed98+user1
I’m just getting my feet wet with LDAP, so bear with me.
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,
Thanks,
Sergei
> On Nov 7, 2017, at 4:44 PM, William Brown <wibrown(a)redhat.com>
> wrote:
>
> On Tue, 2017-11-07 at 13:33 -0600, Sergei Gerasenko wrote:
> > Hi,
> >
> > I was going through RedHat’s documentation on naming conflicts.
> > Here’s what it says at the beginning (https://access.redhat.com/d
> > ocum
> > entation/en-
> > us/red_hat_directory_server/10/html/administration_guide/managing
> > _rep
> > lication-solving_common_replication_conflicts
> > <https://access.redhat.com/documentation/en-
> > us/red_hat_directory_server/10/html/administration_guide/managing
> > _rep
> > lication-solving_common_replication_conflicts>):
> >
> > 14.23.1. Solving Naming Conflicts
> > When two entries are created with the same DN on different
> > servers,
> > the automatic conflict resolution procedure during replication
> > renames the last entry created, including the entry's unique
> > identifier in the DN. Every directory entry includes a unique
> > identifier given by the operational attribute nsuniqueid. When a
> > naming conflict occurs, this unique ID is appended to the non-
> > unique
> > DN.
> > <>
> > What I don’t understand is how conflicts can happen at all if the
> > last one wins?
>
> The point is that if the last one wins, what do we do with the
> first?
> We don't want to just delete it in case the order of operations was
> not
> what the admin expected. So when you do:
>
> Master 1 Master 2
>
> Time 0 ADD E
>
> Time 1 ADD E
>
> We are going to keep M1 E, and we'll conflict on M2 E - this
> becomes
> the conflict entry.
>
> > Also, they are talking about solutions to the conflicts and
> > specifically renaming the user that has nsuniqueid prepended.
> > Does
> > that assume that the conflicting user is actually another person?
> > Or
> > does it mean the conflicting record denotes the same user? If
> > it’s
> > the same user, shouldn’t the conflicting record just be removed?
> > Really confused about the nature of the problem and the suggested
> > solutions.
> > Thanks!
>
> See above. It's about preserving the duplicate entry incase the
> administrator wishes to revive them or see what happened. :)
>
>
> Hope that helps, Ludwig might have more to say on this.
>
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproje
> > ct.o
> > rg
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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
7:35 a.m.
Thank you, William. I currently don’t have MMR set up, but I think it should not be a hard
to do. Currently, I just spun up a VM and installed 389-ds on it. The reason why I want to
simulate this is because I don’t quite understand the technique Redhat employs to resolve
the conflict. If you look in that section (14.23.1.1), you will see that they first rename
the nsunique+uid attribute to uid=NewValue keeping the old RDN and then delete the
uid=NewValue along with the conflict marker. The deletion is done under the new dn of
uid=NewValue,….
I think I now understand why the rename has to happen first. Since there are in that
scenario two “adamss” users, if we just rename the second into “new” and delete the old
RDN, it will delete the first “adamss” as well, right?
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?
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,
9:34 p.m.
On Wed, 2017-11-08 at 07:35 -0600, Sergei Gerasenko wrote:
Thank you, William. I currently don’t have MMR set up, but I think
it
should not be a hard to do. Currently, I just spun up a VM and
installed 389-ds on it. The reason why I want to simulate this is
because I don’t quite understand the technique Redhat employs to
resolve the conflict. If you look in that section (14.23.1.1), you
will see that they first rename the nsunique+uid attribute to
uid=NewValue keeping the old RDN and then delete the uid=NewValue
along with the conflict marker. The deletion is done under the new dn
of uid=NewValue,….
I think I now understand why the rename has to happen first. Since
there are in that scenario two “adamss” users, if we just rename the
second into “new” and delete the old RDN, it will delete the first
“adamss” as well, right?
Not quite. When we have this scenario:
M1 M2
T0 Add E1
T1 Add E2
To make this easier, let's call the "E1" and "E2". They are the
same
entry, but the number denotes the server they were added on. (ie
uid=adamss for both E1 and E2)
So in this case, when we replicate the change from M2 -> M1 (and vice
versa), then what happens is we rename E2 from "uid=adamss" to:
uid=adamss+nsUniqueId=...
And add the objectClass (nsTombstone)
E1 however, remains as uid=adamss, and is not altered.
So the admin then when they realise has to:
* Leave this alone. Purging will clean the E2 conflict later, so E1
survives.
* If they want to revive E2, they need to delete E1 (or move it), then
move E2 to the original RDN.
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.
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
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
rg
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
1:10 p.m.
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>
5:03 p.m.
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
8:26 p.m.
Yep, that’s a very good tutorial indeed! To answer my own question then, since the default
scope is sub and the filter is cn=replica, the replica entry is found?
On Nov 9, 2017, at 5:03 PM, William Brown <wibrown(a)redhat.com>
wrote:
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
<https://fy.blackhats.net.au/blog/html/pages/ldap_guide_part_1_foundatio>
ns.html
9:04 p.m.
On Thu, 2017-11-09 at 20:26 -0600, Sergei Gerasenko wrote:
Yep, that’s a very good tutorial indeed! To answer my own question
then, since the default scope is sub and the filter is cn=replica,
the replica entry is found?
Exactly! :)
> On Nov 9, 2017, at 5:03 PM, William Brown <wibrown(a)redhat.com>
> wrote:
>
> 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_found
> atio
> <https://fy.blackhats.net.au/blog/html/pages/ldap_guide_part_1_foun
> datio>
> ns.html
_______________________________________________
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
2352
days inactive
2355
days old
389-users@lists.fedoraproject.org
10 comments
3 participants
participants (3)
-
gerases＠gmail.com -
Sergei Gerasenko
-
William Brown