Hi All,
We are searching with same filter but with two different search bases and we are seeing results to be different.
Case1: (working case) Search filter: (cn=monitorsoapnode*) Search base: o=itsmydomain.com Search result: cn=monitorsoapnode@np-m910-45-4,cn=soap nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.commailto:cn=monitorsoapnode@np-m910-45-4,cn=soap%20nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.com cn=monitorsoapnode@ np-m910-87-8,cn=soap nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.com
Case2: (not working case) Search filter: (cn=monitorsoapnode*) Search base: cn=ucloud,o=itsmydomain.com Search result: cn=monitorsoapnode@np-m910-45-4,cn=soap nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.commailto:cn=monitorsoapnode@np-m910-45-4,cn=soap%20nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.com
It is observed that with search base "o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" we are getting the expected results. We are seeing this behaviour with hdb database, but not with bdb. But we want to stick to hdb only. Is there any workaround to fix the issue(something like changing the configuration settings)? It is also observed that in both cases bdb_substring_candidates value is 2 but bdb_search_candidates value is different. I am not sure if this observation is relevant or not.
You can check the logs for working and not working cases below. Please help.
########Not working case log ################## <= send_search_entry: conn 1000 exit. send_ldap_result: conn=1000 op=8 p=3 send_ldap_response: msgid=9 tag=101 err=0 ber_flush2: 14 bytes to sd 12 connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 118 contents: op tag 0x63, time 1409136356 ber_get_next conn=1000 op=9 do_search ber_scanf fmt ({miiiib) ber:
dnPrettyNormal: <cn=ucloud,o=itsmydomain.com>
<<< dnPrettyNormal: <cn=ucloud,o=itsmydomain.com>, <cn=ucloud,o=itsmydomain.com> ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" => hdb_search bdb_dn2entry("cn=ucloud,o=itsmydomain.com") search_candidates: base="cn=ucloud,o=itsmydomain.com" (0x00000002) scope=2 => hdb_dn2idl("cn=ucloud,o=itsmydomain.com") => bdb_substring_candidates (cn) => key_read <= bdb_index_read 6 candidates => key_read <= bdb_index_read 33 candidates => key_read <= bdb_index_read 3 candidates => key_read <= bdb_index_read 17 candidates => key_read <= bdb_index_read 6 candidates => key_read <= bdb_index_read 18 candidates <= bdb_substring_candidates: 2, first=267, last=198029 bdb_search_candidates: id=1 first=267 last=267 => send_search_entry: conn 1000 dn="cn=monitorsoapnode@np-m910-45-4,cn=soap nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.commailto:cn=monitorsoapnode@np-m910-45-4,cn=soap%20nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" ber_flush2: 140 bytes to sd 12 <= send_search_entry: conn 1000 exit. send_ldap_result: conn=1000 op=9 p=3 send_ldap_response: msgid=10 tag=101 err=0 ber_flush2: 14 bytes to sd 12
########Working case log ################## <= send_search_entry: conn 1000 exit. send_ldap_result: conn=1000 op=9 p=3 send_ldap_response: msgid=10 tag=101 err=0 ber_flush2: 14 bytes to sd 12 connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 108 contents: op tag 0x63, time 1409136444 ber_get_next conn=1000 op=10 do_search ber_scanf fmt ({miiiib) ber:
dnPrettyNormal: <o=itsmydomain.com>
<<< dnPrettyNormal: <o=itsmydomain.com>, <o=itsmydomain.com> ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" => hdb_search bdb_dn2entry("o=itsmydomain.com") search_candidates: base="o=itsmydomain.com" (0x00000001) scope=2 => hdb_dn2idl("o=itsmydomain.com") => bdb_substring_candidates (cn) => key_read <= bdb_index_read 6 candidates => key_read <= bdb_index_read 33 candidates => key_read <= bdb_index_read 3 candidates => key_read <= bdb_index_read 17 candidates => key_read <= bdb_index_read 6 candidates => key_read <= bdb_index_read 18 candidates <= bdb_substring_candidates: 2, first=267, last=198029 bdb_search_candidates: id=2 first=267 last=198029 => send_search_entry: conn 1000 dn="cn=monitorsoapnode@np-m910-45-4,cn=soap nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.commailto:cn=monitorsoapnode@np-m910-45-4,cn=soap%20nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" ber_flush2: 140 bytes to sd 12 <= send_search_entry: conn 1000 exit. => send_search_entry: conn 1000 dn="cn=monitorsoapnode@np-m910-87-8,cn=soap nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.commailto:cn=monitorsoapnode@np-m910-87-8,cn=soap%20nodes,o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" ber_flush2: 140 bytes to sd 12 <= send_search_entry: conn 1000 exit. send_ldap_result: conn=1000 op=10 p=3 send_ldap_response: msgid=11 tag=101 err=0 ber_flush2: 14 bytes to sd 12
Slapd config details you may be interested in are as follows
####### Config details start ###### database hdb suffix "o= itsmydomain.com" rootdn "cn=Directory Manager,o= itsmydomain.com" rootpw {SSHA}4tqAhskuvQm3wFz9EI3lqLI8pRRs6IfI
sizelimit 2000 index default pres,eq index cn pres,eq,sub index objectClass eq index entryCSN,entryUUID eq index authenticationuser pres,eq,sub index osidentity pres,eq,sub cachesize 5000 checkpoint 1024 10
####### Config details end ######
Regards, Jegan.
--On Tuesday, September 02, 2014 11:07 AM +0000 Jeganathan S jeganats@opentext.com wrote:
It is observed that with search base "o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" we are getting the expected results.
We are seeing this behaviour with hdb database, but not with bdb. But we want to stick to hdb only. Is there any workaround to fix the issue(something like changing the configuration settings)?
It is also observed that in both cases bdb_substring_candidates value is 2 but bdb_search_candidates value is different. I am not sure if this observation is relevant or not.
What openldap version are you using?
I would note that your "working base" of "o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" is not listed in either case 1 or case 2 as a base you used, and that in both case 1 and case 2, you say you got the same result. So based off of what you sent in email, everything appears to be working and neither case appears related to your complaint... You'll need to provide more precise information.
Since you didn't state what version of OpenLDAP you're using, one could endlessly speculate on potential fixed bugs over the last 5+ years that could result in the behavior you're reporting.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi Quanah,
Sorry for the inconsistency. Actually we get expected result on both search bases("o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" and "o=itsmydomain.com") and the result differs only when the search base is " cn=ucloud,o=itsmydomain.com ".
In the case 1, we get two entries in the result set but in the case 2, we get only one entry. I think due to formatting issue it was deceptive in the previous mail.
The openldap version that we use is 2.4.21. This issue consistently occurs when we export(slapcat) the content in ldif format and imported(slapadd) again into a clean ldap server.
Thanks, Jegan
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: 02 September 2014 22:19 To: Jeganathan S; openldap-technical@openldap.org Subject: Re: FW: Openldap search results varies with search base
--On Tuesday, September 02, 2014 11:07 AM +0000 Jeganathan S jeganats@opentext.com wrote:
It is observed that with search base "o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" we are getting the expected results.
We are seeing this behaviour with hdb database, but not with bdb. But we want to stick to hdb only. Is there any workaround to fix the issue(something like changing the configuration settings)?
It is also observed that in both cases bdb_substring_candidates value is 2 but bdb_search_candidates value is different. I am not sure if this observation is relevant or not.
What openldap version are you using?
I would note that your "working base" of "o=system,cn=cordys,cn=ucloud,o=itsmydomain.com" is not listed in either case 1 or case 2 as a base you used, and that in both case 1 and case 2, you say you got the same result. So based off of what you sent in email, everything appears to be working and neither case appears related to your complaint... You'll need to provide more precise information.
Since you didn't state what version of OpenLDAP you're using, one could endlessly speculate on potential fixed bugs over the last 5+ years that could result in the behavior you're reporting.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, September 03, 2014 5:39 AM +0000 Jeganathan S jeganats@opentext.com wrote:
The openldap version that we use is 2.4.21. This issue consistently occurs when we export(slapcat) the content in ldif format and imported(slapadd) again into a clean ldap server.
I would note that 2.4.21 is 4.5 years old, and multitudes of bugs have been fixed since then. I strongly advise you to run a current release. In general, you're just wasting your time until you do.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Thanks Quanah,
The issue is not occurring with latest openldap(2.4.39).
Regards, Jeganathan
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: 03 September 2014 11:54 To: Jeganathan S; openldap-technical@openldap.org Subject: RE: FW: Openldap search results varies with search base
--On Wednesday, September 03, 2014 5:39 AM +0000 Jeganathan S jeganats@opentext.com wrote:
The openldap version that we use is 2.4.21. This issue consistently occurs when we export(slapcat) the content in ldif format and imported(slapadd) again into a clean ldap server.
I would note that 2.4.21 is 4.5 years old, and multitudes of bugs have been fixed since then. I strongly advise you to run a current release. In general, you're just wasting your time until you do.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Jeganathan S -
Quanah Gibson-Mount