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/ht... https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-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? 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!
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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
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@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 2Time 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@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
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/html/administration_guide/managing_replication-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.
Thanks, Sergei
On Nov 7, 2017, at 4:44 PM, William Brown wibrown@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 2Time 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@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
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@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproje ct.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
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
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,
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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
Not quite. When we have this scenario:
M1 M2T0 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-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org
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@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org 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@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject .org mailto:389-users-leave@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
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@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
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@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
389-users@lists.fedoraproject.org
-
gerases＠gmail.com -
Sergei Gerasenko
-
William Brown