[Date Prev][Date Next]
Re: ldapsearch with -s "one" works where -s "sub" fails (ITS#378)
- To: openldap-bugs@OpenLDAP.org
- Subject: Re: ldapsearch with -s "one" works where -s "sub" fails (ITS#378)
- From: Jens Heunemann <email@example.com>
- Date: Sat, 04 Dec 1999 16:59:30 +0100
- Organization: Consol GmbH
- References: <199911191211.MAA97971@cantor.boolean.net> <firstname.lastname@example.org>
Julio Sanchez wrote:
> email@example.com writes:
> > Full_Name: Jens Heunemann
> > Version: 1.2.7
> > OS: Linux 2.2.5
> > URL:
> > Submission from: (NULL) (188.8.131.52)
> > Hi, I ran into the following problem:
> > I inserted an entry into an ldap-Database with a perlscript. When I try to
> > search for
> > the entry, the following strange behavior occurs:
> > 1.
> > If I search with:
> > # bin/ldapsearch -b "ou=N.N., c=Australia, o=opcos" -s sub "sn=Test"
> > I get no results.
> > 2.
> > If I search with:
> > # bin/ldapsearch -b "ou=N.N., c=Australia, o=opcos" -s one "sn=Test"
> > I get the entry I'm searching for:
> Your indexes are hosed, id2children seems alright, but the dn index is
> broken. I suggest you stop slapd, do ldbmcat, remove the files in the
> database and do a ldif2ldbm on the output from ldbmcat. With 1.2.7,
Tried it, and it worked, seems you are right, the index is broken.
Problem is, I cannot recreate the index after each insert in the
database (since I am not the one who does the inserts)
> don't do it with older versions.
> > ------
> > cn=Jens Test, ou=N.N., c=Australia, o=OPCOs
> > < attributes snipped >
> > ----------
> > If I search with the filter sn=*, in both (!) cases the second person which is
> > located
> > under this basedn is found:
> This is because sn=* in your case seems to be ALLIDS (a special mark
> that says it is useless to list the specific entries that have a sn
> since there are so many). Thus, slapd scans all entries anyway and
> discards those that should not be returned. The selection logic is
> independent from idexing and so it works despite your index problems.
> Everything seems coherent with hosed indexes, so I would kill that
> possibility first.
Jens Heunemann firstname.lastname@example.org
ConSol GmbH http://www.consol.de
Franziskanerstrasse 38 Tel.:089/45841-503
81669 Muenchen Fax.:089/45841-199