The DNA plug-in uses a range search internally to locate the next free value within the managed range. This works fine when the values are strictly integers, but the DNA plug-in supports a prefix to the integer portion of the value (such as "user1 - user1000"). When a prefix is defined, we should not use a range search to locate the next free value. We should simply do an exact match search to see if the next value in the cached configuration entry is free. If it is not free, we iterate through each value in the range until we either find a free value, or hit the end of the range. This will typically perform fine, as the next value in the configuration entry should be free unless someone manually assigned it. The worst case scenario is that we have to go through a large block of values that was manually assigned, which will be helped by an equality index. Even so, this case should be rare.
Created attachment 313468 [details] CVS Diffs These changes implement the approach described in the previous comment. For efficiency in the case that we have to go through a large block of manually assigned values, I wanted to reuse a previously allocated pblock instead of allocating one for each search. This required me to export a new public SLAPI function that re-initializes a pblock so it can be reused.
https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff#ldap/servers/plugins/dna/dna.c_sec1 - lines 864-880 You could use ldap_controls_free(ctrls) - it is ok to pass a NULL, and it will free all controls in the array e.g. ldap_controls_free(ctrls); ctrls = NULL; instead of if (ctrls) { ldap_control_free(ctrls[0]); slapi_ch_free(&ctrls); } https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff#ldap/servers/plugins/dna/dna.c_sec2 - line 917 Is it ok to call slapi_free_search_results_internal with no search results?
(In reply to comment #2) > https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff#ldap/servers/plugins/dna/dna.c_sec1 > - lines 864-880 > > You could use ldap_controls_free(ctrls) - it is ok to pass a NULL, and it will > free all controls in the array e.g. > ldap_controls_free(ctrls); > ctrls = NULL; > instead of > if (ctrls) { > ldap_control_free(ctrls[0]); > slapi_ch_free(&ctrls); > } I'll address this in a new set of diffs shortly. > > https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff#ldap/servers/plugins/dna/dna.c_sec2 > - line 917 > > Is it ok to call slapi_free_search_results_internal with no search results? Yes, this is safe. The slapi_free_search_results_internal() function first checks if pb->pb_plugin_internal_search_op_entries and pb->pb_plugin_internal_search_op_referrals are NULL before attempting to free them.
Created attachment 313486 [details] Revised Diffs
Checked into ldapserver (HEAD). Thanks to Rich for his review! Checking in ldap/servers/plugins/dna/dna.c; /cvs/dirsec/ldapserver/ldap/servers/plugins/dna/dna.c,v <-- dna.c new revision: 1.8; previous revision: 1.7 done Checking in ldap/servers/slapd/pblock.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/pblock.c,v <-- pblock.c new revision: 1.16; previous revision: 1.15 done Checking in ldap/servers/slapd/slapi-plugin.h; /cvs/dirsec/ldapserver/ldap/servers/slapd/slapi-plugin.h,v <-- slapi-plugin.h new revision: 1.28; previous revision: 1.27 done
Would it suffice for verification if I added 1000 users using DNA to assign uid numbers that was configured with a prefix - (user1 user10 user100 user1000) and then verify their assigned uidNumbers? Thanks
- Setup a range with a prefix for "user1" - "user100". - Manually create 3 users explicitly specifying values of "user1", "user2", and "user11" to bypass DNA. - Create a new user and allow DNA to generate the value from the range. Make sure that the new user gets the "user3" value from the range.
fix verified RHEL 4 - new automated acceptance test added to regress this bug - results: DNA TEST BUG 457951: Sorted Range Search With DNA Prefix Adding users and groups with manually defined uid and gid numbers 1,2, and 11 adding new entry cn=Posix User1,ou=People,o=dna.net adding new entry cn=Posix User2,ou=People,o=dna.net adding new entry cn=Posix User11,ou=People,o=dna.net adding new entry cn=Group1,ou=Groups,o=dna.net adding new entry cn=Group2,ou=Groups,o=dna.net adding new entry cn=Group11,ou=Groups,o=dna.net adding new entry cn=Posix User101,ou=People,o=dna.net adding new entry cn=Posix User102,ou=People,o=dna.net adding new entry cn=Posix User111,ou=People,o=dna.net adding new entry cn=Group101,ou=Groups,o=dna.net adding new entry cn=Group102,ou=Groups,o=dna.net adding new entry cn=Group111,ou=Groups,o=dna.net Add users and groups and let DNA assign uid and gid numbers - next 3 adding new entry cn=Posix User3,ou=People,o=dna.net adding new entry cn=Group3,ou=Groups,o=dna.net adding new entry cn=Posix User103,ou=People,o=dna.net adding new entry cn=Group103,ou=Groups,o=dna.net Verifying users added from server 1 Posix User1 is assigned expected uidNumber: user1 Posix User2 is assigned expected uidNumber: user2 Posix User3 is assigned expected uidNumber: user3 Posix User11 is assigned expected uidNumber: user11 Verifying users added from server 2 Posix User101 is assigned expected uidNumber: user101 Posix User102 is assigned expected uidNumber: user102 Posix User103 is assigned expected uidNumber: user103 Posix User111 is assigned expected uidNumber: user111 Verifying groups added from server 1 Group1 is assigned expected gidNumber: group1 Group2 is assigned expected gidNumber: group2 Group3 is assigned expected gidNumber: group3 Group11 is assigned expected gidNumber: group11 Verifying groups added from server 2 Group101 is assigned expected gidNumber: group101 Group102 is assigned expected gidNumber: group102 Group103 is assigned expected gidNumber: group103 Group111 is assigned expected gidNumber: group111 TestCaseResult dna_bug457951 PASS
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html