[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Search scope and start DN ignored on search. (ITS#2082)
Full_Name: Andy Hofle
Version: OPENLDAP_REL_ENG_2_1
OS: Solaris 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (166.34.144.55)
I am running into a strange problem when performing a simple search on
objectClass. In certain places in the tree (not always), the LDAP will ignore
the startDN and scope of my search and search the ENTIRE tree, taking several
seconds to finish. This only occurs when I search on a specific objectclass
value. If I search (objectClass=*), the search runs perfectly and does not
ignore my scope and start DN.
Here is my search information:
startDN: "uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com"
scope: 1
filter: (objectclass=myorgservice)
The following is some debug output from this search:
do_search
ber_scanf fmt ({miiiib) ber:
>>> dnPrettyNormal: <uid=5253257, ou=People, o=myorg, myorgroot=top,
o=myorg.com>
=> ldap_bv2dn(uid=5253257, ou=People, o=myorg, myorgroot=top, o=myorg.com,0)
<= ldap_bv2dn(uid=5253257, ou=People, o=myorg, myorgroot=top, o=myorg.com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com,272)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com,272)=0
<<< dnPrettyNormal: <uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com>,
<uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com>
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
end get_filter 0
ber_scanf fmt ({M}}) ber:
conn=0 op=2 SRCH base="uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com"
scope=1 filter="(objectClass=myorgservice)"
=> bdb_back_search
bdb_dn2entry_rw("uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com")
=> bdb_dn2id_matched( "uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com"
)
====> bdb_cache_find_entry_dn2id("uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com"):
1688 (1 tries)
====> bdb_cache_find_entry_id( 1688 )
"uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com" (found) (1 tries)
search_candidates: base="uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com"
(0x00000698) scope=1
=> bdb_filter_candidates
AND
=> bdb_list_candidates 0xa0
=> bdb_filter_candidates
DN ONE
=> bdb_dn2idl( "uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com" )
<= bdb_dn2idl: id=10 first=1689 last=1698
<= bdb_filter_candidates: id=10 first=1689 last=1698
=> bdb_filter_candidates
OR
=> bdb_list_candidates 0xa1
=> bdb_filter_candidates
EQUALITY
=> bdb_equality_candidates
=> key_read
<= bdb_index_read: failed (-30990)
<= bdb_equality_candidates NULL
<= bdb_equality_candidates id=0, first=0, last=0
<= bdb_filter_candidates: id=0 first=0 last=0
=> bdb_filter_candidates
EQUALITY
=> bdb_equality_candidates
=> key_read
<= bdb_index_read 15284 candidates
<= bdb_equality_candidates id=15284, first=12, last=29997
<= bdb_filter_candidates: id=15284 first=12 last=29997
<= bdb_list_candidates: undefined rc=0
<= bdb_filter_candidates: id=15284 first=12 last=29997
<= bdb_list_candidates: undefined rc=0
<= bdb_filter_candidates: id=15284 first=12 last=29997
bdb_search_candidates: id=15284 first=12 last=29997
====> bdb_cache_return_entry_r( 1688 ): returned (0)
....
[snip]
....
====> bdb_cache_return_entry_r( 1707 ): created (0)
entry_decode: "myorgsn=source,uid=5256742,ou=People,o=myorg,myorgroot=top,o=myorg.com"
<= entry_decode(myorgsn=source,uid=5256742,ou=People,o=myorg,myorgroot=top,o=myorg.com)
=> test_filter
EQUALITY
=> string_expand: pattern: cn=Replication Manager,o=myorg.com
=> string_expand: expanded: cn=Replication Manager,o=myorg.com
=> regex_matches: string: cn=replication manager,o=myorg.com
=> regex_matches: rc: 0 matches
is_object_subclass(1.3.6.1.4.1.8067.1.4,2.5.6.0) 0
is_object_subclass(1.3.6.1.4.1.8067.1.4,1.3.6.1.4.1.8067.1.4) 1
<= test_filter 6
bdb_search: 1708 scope not okay
====> bdb_cache_return_entry_r( 1708 ): created (0)
entry_decode: "myorgsn=stock,uid=5256742,ou=People,o=myorg,myorgroot=top,o=myorg.com"
<= entry_decode(myorgsn=stock,uid=5256742,ou=People,o=myorg,myorgroot=top,o=myorg.com)
=> test_filter
EQUALITY
=> string_expand: pattern: cn=Replication Manager,o=myorg.com
=> string_expand: expanded: cn=Replication Manager,o=myorg.com
=> regex_matches: string: cn=replication manager,o=myorg.com
=> regex_matches: rc: 0 matches
is_object_subclass(1.3.6.1.4.1.8067.1.4,2.5.6.0) 0
is_object_subclass(1.3.6.1.4.1.8067.1.4,1.3.6.1.4.1.8067.1.4) 1
<= test_filter 6
bdb_search: 1709 scope not okay
....
As you can see, the candidate set is determined to be from first=12 last=29997
(there should only be 10 entries in the candidate set). The last part of the
log I included shows two invalid DNs that are being searched, with a msg 'scope
not okay' being returned for each one. The search proceeds like this until
every entry is processed and then it returns the correct result set. However,
with a large tree, this query might take 30 seconds or more (as it is now with
my relatively small DB, it is taking 5 seconds).
Again, with a search on objectclass=*, the search runs fine and does not search
the entire tree. The following query runs as it should:
startDN: "uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com"
scope: 1
filter: (objectclass=*)
I have tried the 2.1.4 OpenLDAP version as well as the latest 2.1.X from
engineering. I am using version 4.0.14 of BerkeleyDB. I have tried rebuilding
the indices, deleting the entire database and starting over, and the same
problem occurs everytime. The following are the relevant sections from my
slapd.conf:
--
database bdb
suffix "o=myorg.com"
rootdn "cn=Directory Manager,o=myorg.com"
rootpw secret
index ou,o eq
index cn pres,eq
index myorgfirstname,myorglastname,myorgvportalaccessinfo
pres,eq,sub
index myorggroupname,myorgworkphonenumber pres,eq,sub
index uid,myorgdn,myorgroot,myorgsn pres,eq
index objectclass,myorgadmin,myorgan pres,eq
index myorgsecondaryuid pres,eq
directory /opt/openldap/var/openldap
--
Please let me know if you would like me to submit my slapd.conf, org-specific
schema file, and test data ldif to the FTP site to allow you to reproduce this.
Thanks,
Andy Hofle
banzaitron@adelphia.net