Hi Todd,
Thanks for your explanations, it make sense.
To make it work, was it enough to add to the definitions (uidNumber/gidNumber) (usr/share/dirsrv/schema/*) 'ORDERING integerOrderingMatch'.
Or did you have to add 'nsMatchingRule: integerOrderingMatch' to the index entry and reindex ?
best regards thierry
On 8/17/22 5:47 PM, Merritt, Todd R - (tmerritt) wrote:
Hi Theirry,
It looks like that internal search was failing due to not having the appropriate matching rules in place. Once I added the indices it started to behave correctly. I guess it's probably a bug that it does not indicate that the search failed and/or continues to allocate the value without really knowing if it's a duplicate or not.
Thanks, Todd
*From:* Thierry Bordaz tbordaz@redhat.com *Sent:* Wednesday, August 17, 2022 8:30 AM *To:* General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org; Merritt, Todd R - (tmerritt) tmerritt@arizona.edu *Subject:* [EXT]Re: [389-users] Re: DNA Plugin creating duplicates
*External Email*
Hi,
sorry to be late on that thread. DNA should prevent duplicate values via internal searches before allocating. If configured ranges from server are separated, DNA should not allocate duplicate. Is it possible that a direct update could set the attribute managed by DNA ?
regards Thierry
On 8/11/22 9:59 PM, Merritt, Todd R - (tmerritt) wrote:
Yep, I just tested it out for haha's on my test directory instance after skimming the plugin source and seeing that it actually does does a range search using >=, <=. Sure enough that seems to have resolved it. It did work properly in the current configuration once upon a time so either my directory grew enough that the range search started to time out without the index or the range search was introduced in an update at some point. Thanks for the pointer!
Todd
*From:* Patrick M Landry patrick.landry@louisiana.edu mailto:patrick.landry@louisiana.edu *Sent:* Thursday, August 11, 2022 12:55 PM *To:* General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org *Subject:* [EXT][389-users] Re: DNA Plugin creating duplicates
*External Email*
Sorry, I just double checked and I *do* have the integerOrderingMatch Matching Rule configured for uidNumber and gidNumber. I have no idea if that would make a difference for you or not.
-- Patrick Landry Special Projects Engineer University Computing Support Services University of Louisiana at Lafayette P.O. Box 43621 Lafayette, LA 70504 (337) 482-6402 patrick.landry@louisiana.edu mailto:patrick.landry@louisiana.edu ––––––––––––––––––––––––– Université des Acadiens
*From:* Merritt, Todd R - (tmerritt) tmerritt@arizona.edu mailto:tmerritt@arizona.edu *Sent:* Thursday, August 11, 2022 2:26 PM *To:* General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org *Subject:* [389-users] Re: DNA Plugin creating duplicates CAUTION: This email originated from outside of UL Lafayette. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks, that's a good thought. It looks like I do have the index set up though.
dn: cn=uidnumber,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config cn: uidnumber nsIndexType: eq nsSystemIndex: False objectClass: top objectClass: nsIndex
Does the index also need to support nsMatchingRule: integerOrderingMatch for inequality searching?
Todd
*From:* Patrick M Landry patrick.landry@louisiana.edu mailto:patrick.landry@louisiana.edu *Sent:* Thursday, August 11, 2022 12:16 PM *To:* General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org *Subject:* [EXT][389-users] Re: DNA Plugin creating duplicates
*External Email*
It has been a long time since I set this up and I am running an older version of the server but I did find this in my notes:
Before assigning a number to a new entry theDNAplugin searches the directory to ensure that the number is not already being used. For this reason indexes had to be created for all of the attributes which theDNAplugin can assign values to.
Perhaps that is it?
Patrick Landry Special Projects Engineer University Computing Support Services University of Louisiana at Lafayette P.O. Box 43621 Lafayette, LA 70504 (337) 482-6402 patrick.landry@louisiana.edu mailto:patrick.landry@louisiana.edu ––––––––––––––––––––––––– Université des Acadiens
*From:* Merritt, Todd R - (tmerritt) tmerritt@arizona.edu mailto:tmerritt@arizona.edu *Sent:* Thursday, August 11, 2022 12:51 PM *To:* 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org *Subject:* [389-users] DNA Plugin creating duplicates CAUTION: This email originated from outside of UL Lafayette. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi,
I'm running 389ds 2.0.15 on a two node cluster in a multi master mode. I'm using the DNA plugin to generate unique uid numbers for new accounts. Each directory instance is assigned a unique range of uid numbers. It works in so far as it assigns a uid number when it gets the magic token but whatever is supposed to be verifying that the uid number is not already assigned is not working. I've cranked the error log level up, but I don't get anything in the logs that is helpful in determining why that validation is not working correctly.
# ansible-managed-uidnumber-generation, Distributed Numeric Assignment Plugin, plugins, config dn: cn=ansible-managed-uidnumber-generation,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: dnaPluginConfig cn: ansible-managed-uidnumber-generation dnaType: uidNumber dnaNextValue: 62009 dnaMaxValue: 131000 dnaMagicRegen: generate dnaFilter: (objectclass=posixAccount) dnaScope: ou=Accounts,dc=example,dc=edu dnaSharedCfgDN: ou=ranges,ou=Accounts,dc=example,dc=edu
I'm stumped. Anyone have any direction on how to debug this further?
Thanks! Todd
389-users mailing list --389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue https://pagure.io/fedora-infrastructure/new_issue
I did not try modifying the schema. I just added the matching rule to the index and reindexed.
Thanks, Todd ________________________________ From: Thierry Bordaz tbordaz@redhat.com Sent: Thursday, August 18, 2022 1:40 AM To: Merritt, Todd R - (tmerritt) tmerritt@arizona.edu; General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org Subject: Re: [EXT]Re: [389-users] Re: DNA Plugin creating duplicates
External Email
Hi Todd,
Thanks for your explanations, it make sense.
To make it work, was it enough to add to the definitions (uidNumber/gidNumber) (usr/share/dirsrv/schema/*) 'ORDERING integerOrderingMatch'.
Or did you have to add 'nsMatchingRule: integerOrderingMatch' to the index entry and reindex ?
best regards thierry
On 8/17/22 5:47 PM, Merritt, Todd R - (tmerritt) wrote: Hi Theirry,
It looks like that internal search was failing due to not having the appropriate matching rules in place. Once I added the indices it started to behave correctly. I guess it's probably a bug that it does not indicate that the search failed and/or continues to allocate the value without really knowing if it's a duplicate or not.
Thanks, Todd ________________________________ From: Thierry Bordaz tbordaz@redhat.commailto:tbordaz@redhat.com Sent: Wednesday, August 17, 2022 8:30 AM To: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org; Merritt, Todd R - (tmerritt) tmerritt@arizona.edumailto:tmerritt@arizona.edu Subject: [EXT]Re: [389-users] Re: DNA Plugin creating duplicates
External Email
Hi,
sorry to be late on that thread. DNA should prevent duplicate values via internal searches before allocating. If configured ranges from server are separated, DNA should not allocate duplicate. Is it possible that a direct update could set the attribute managed by DNA ?
regards Thierry
On 8/11/22 9:59 PM, Merritt, Todd R - (tmerritt) wrote: Yep, I just tested it out for haha's on my test directory instance after skimming the plugin source and seeing that it actually does does a range search using >=, <=. Sure enough that seems to have resolved it. It did work properly in the current configuration once upon a time so either my directory grew enough that the range search started to time out without the index or the range search was introduced in an update at some point. Thanks for the pointer!
Todd ________________________________ From: Patrick M Landry patrick.landry@louisiana.edumailto:patrick.landry@louisiana.edu Sent: Thursday, August 11, 2022 12:55 PM To: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org Subject: [EXT][389-users] Re: DNA Plugin creating duplicates
External Email
Sorry, I just double checked and I do have the integerOrderingMatch Matching Rule configured for uidNumber and gidNumber. I have no idea if that would make a difference for you or not.
-- Patrick Landry Special Projects Engineer University Computing Support Services University of Louisiana at Lafayette P.O. Box 43621 Lafayette, LA 70504 (337) 482-6402 patrick.landry@louisiana.edumailto:patrick.landry@louisiana.edu ––––––––––––––––––––––––– Université des Acadiens
________________________________ From: Merritt, Todd R - (tmerritt) tmerritt@arizona.edumailto:tmerritt@arizona.edu Sent: Thursday, August 11, 2022 2:26 PM To: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org Subject: [389-users] Re: DNA Plugin creating duplicates
CAUTION: This email originated from outside of UL Lafayette. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks, that's a good thought. It looks like I do have the index set up though.
dn: cn=uidnumber,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config cn: uidnumber nsIndexType: eq nsSystemIndex: False objectClass: top objectClass: nsIndex
Does the index also need to support nsMatchingRule: integerOrderingMatch for inequality searching?
Todd ________________________________ From: Patrick M Landry patrick.landry@louisiana.edumailto:patrick.landry@louisiana.edu Sent: Thursday, August 11, 2022 12:16 PM To: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org Subject: [EXT][389-users] Re: DNA Plugin creating duplicates
External Email
It has been a long time since I set this up and I am running an older version of the server but I did find this in my notes:
Before assigning a number to a new entry the DNA plugin searches the directory to ensure that the number is not already being used. For this reason indexes had to be created for all of the attributes which the DNA plugin can assign values to.
Perhaps that is it?
-- Patrick Landry Special Projects Engineer University Computing Support Services University of Louisiana at Lafayette P.O. Box 43621 Lafayette, LA 70504 (337) 482-6402 patrick.landry@louisiana.edumailto:patrick.landry@louisiana.edu ––––––––––––––––––––––––– Université des Acadiens
________________________________ From: Merritt, Todd R - (tmerritt) tmerritt@arizona.edumailto:tmerritt@arizona.edu Sent: Thursday, August 11, 2022 12:51 PM To: 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org Subject: [389-users] DNA Plugin creating duplicates
CAUTION: This email originated from outside of UL Lafayette. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi,
I'm running 389ds 2.0.15 on a two node cluster in a multi master mode. I'm using the DNA plugin to generate unique uid numbers for new accounts. Each directory instance is assigned a unique range of uid numbers. It works in so far as it assigns a uid number when it gets the magic token but whatever is supposed to be verifying that the uid number is not already assigned is not working. I've cranked the error log level up, but I don't get anything in the logs that is helpful in determining why that validation is not working correctly.
# ansible-managed-uidnumber-generation, Distributed Numeric Assignment Plugin, plugins, config dn: cn=ansible-managed-uidnumber-generation,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: dnaPluginConfig cn: ansible-managed-uidnumber-generation dnaType: uidNumber dnaNextValue: 62009 dnaMaxValue: 131000 dnaMagicRegen: generate dnaFilter: (objectclass=posixAccount) dnaScope: ou=Accounts,dc=example,dc=edu dnaSharedCfgDN: ou=ranges,ou=Accounts,dc=example,dc=edu
I'm stumped. Anyone have any direction on how to debug this further?
Thanks! Todd
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.orgmailto:389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
389-users@lists.fedoraproject.org