[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RE: RE: Search scope and start DN ignored on search. (ITS#2082)
This issue has been resolved as far as I can tell thanks to Howard's fix.
The fix is contained in rev 1.59 of back-bdb/idl.c.
Andy
----- Original Message -----
From: "Howard Chu" <hyc@symas.com>
To: "Banzaitron" <banzaitron@adelphia.net>
Sent: Monday, September 16, 2002 2:00 PM
Subject: RE: RE: RE: Search scope and start DN ignored on search. (ITS#2082)
> Great. Can you please send a reply to openldap-its@openldap.org so we can
> document the fix and such...
>
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>
> > -----Original Message-----
> > From: Banzaitron [mailto:banzaitron@adelphia.net]
> > Sent: Monday, September 16, 2002 12:45 PM
> > To: Howard Chu
> > Subject: Re: RE: RE: Search scope and start DN ignored on search.
> > (ITS#2082)
> >
> >
> > You are the MAN! Problem is gone.
> > Thank you so much.
> >
> > Andy
> >
> > ----- Original Message -----
> > From: "Banzaitron" <banzaitron@adelphia.net>
> > To: <banzaitron@adelphia.net>
> > Sent: Sunday, September 15, 2002 10:49 PM
> > Subject: Fwd: RE: RE: Search scope and start DN ignored on search.
> > (ITS#2082)
> >
> >
> > >
> > > >From: "Howard Chu" <hyc@symas.com>
> > > >To: "Banzaitron" <banzaitron@adelphia.net>
> > > >Subject: RE: RE: Search scope and start DN ignored on search.
> > (ITS#2082)
> > > >Date: Fri, 13 Sep 2002 11:20:19 -0700
> > > >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> > > >Importance: Normal
> > > >
> > > >Please test rev 1.59 of back-bdb/idl.c. Thanks.
> > > >
> > > > -- Howard Chu
> > > > Chief Architect, Symas Corp. Director, Highland Sun
> > > > http://www.symas.com http://highlandsun.com/hyc
> > > > Symas: Premier OpenSource Development and Support
> > > >
> > > > > -----Original Message-----
> > > > > From: Banzaitron [mailto:banzaitron@adelphia.net]
> > > > > Sent: Friday, September 13, 2002 8:33 AM
> > > > > To: Howard Chu
> > > > > Subject: Re: RE: Search scope and start DN ignored on search.
> > (ITS#2082)
> > > > >
> > > > >
> > > > > Hi Howard, I just uploaded a zip file
> > (andy-hofle-020913.zip) into the
> > > > > incoming directory containing a large LDIF, my slapd.conf, and my
> > custom
> > > > > schema file. The LDIF contains a lot of corporate data, so if
> > possible,
> > > > > please try not to make any of it public.
> > > > >
> > > > > Once you import the LDIF, you can go to:
> > > > >
> > > > > uid=3374380, ou=People, o=worldcom, wcomroot=top, o=wcomnet.com
> > > > >
> > > > > and search for (objectclass=wcomservice)
> > > > > to see the slowdown. If you have debugging turned high, you will
see
> > every
> > > > > single entry being searched through. ALso, if you try
> > (objectclass=*)
> > you
> > > > > will see that it runs instantly. At least I hope you see the same
> > behavior
> > > > > as me. :) There are also other attributes that search the entire
> > tree. I
> > > > > believe a search of (wcomsn=*) at that same level also causes the
> > slowdown.
> > > > >
> > > > > Thanks alot for looking at this.
> > > > >
> > > > > Andy
> > > > >
> > > > > ----- Original Message ----- >
> > > > > > >From: "Howard Chu" <hyc@symas.com>
> > > > > > >To: <banzaitron@adelphia.net>
> > > > > > >Subject: RE: Search scope and start DN ignored on search.
> > (ITS#2082)
> > > > > > >Date: Thu, 12 Sep 2002 13:18:54 -0700
> > > > > > >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> > > > > > >Importance: Normal
> > > > > > >
> > > > > > >Yes, please put an archive with your test data and config up. I
> > cannot
> > > > > > >reproduce this error on my test system.
> > > > > > >
> > > > > > > -- Howard Chu
> > > > > > > Chief Architect, Symas Corp. Director, Highland Sun
> > > > > > > http://www.symas.com
http://highlandsun.com/hyc
> > > > > > > Symas: Premier OpenSource Development and Support
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: owner-openldap-bugs@OpenLDAP.org
> > > > > > > > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of
> > > > > > > > banzaitron@adelphia.net
> > > > > > > > Sent: Thursday, September 12, 2002 8:32 AM
> > > > > > > > To: openldap-its@OpenLDAP.org
> > > > > > > > Subject: 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> >
> >
> >
>