Bug 60916 - openldap not indexing properly with gdbm backend
openldap not indexing properly with gdbm backend
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: openldap (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-08 17:18 EST by John Dalbec
Modified: 2014-08-31 19:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 10:47:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Dalbec 2002-03-08 17:18:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (Windows NT 5.0; U)

Description of problem:
I'm running a large openldap directory on RH 7.1 with some RH 7.2 packages.  (The LDIF file I get by dumping the directory is ~26M.)  I've installed the RH 7.2 openldap 
erratum (2.0.21-1).  I get incorrect search results using the gdbm backend.  I tried dumping and reloading the database; no luck.  I tried loading the database on a 
different machine in case it was a hardware problem; still no luck.  I tried installing the RH 7.2 version of GDBM; still no luck.  AFAICT the 7.1 and 7.2 versions of GDBM 
are the same.  Finally I built packages for Berkeley DB 3.3.11 and compiled OpenLDAP against these;  this worked.

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes (changes when directory is updated).

Steps to Reproduce:
1. Install OpenLDAP
2. Load ~26M worth of LDAP records
3. Try various searches
	

Actual Results:  Some searches (especially using wildcards) give incorrect results.

Expected Results:  All results should be correct.

Additional info:

Examples of bad searches:
ldapsearch -x 'ou=computer services' returns 30 people (correct)
ldapsearch -x 'ou=computer services*' returns 30 records, but several records are duplicates and others are missing.
ldapsearch -x 'ou=*computer services' returns 33 people (correct)
ldapsearch -x 'ou=*computer services*' returns 22 people (wrong)
ldapsearch -x 'cn=employees' returns

dn: cn=employees,ou=Group,dc=ysu,dc=edu
objectClass: posixGroup
objectClass: top
cn: employees
gidNumber: 502

but ldapsearch -x '(&(gidNumber=502)(objectClass=posixGroup))' returns nothing.

/etc/openldap/slapd.conf:
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/redhat/rfc822-MailMember.schema
include         /etc/openldap/schema/redhat/autofs.schema
include         /etc/openldap/schema/redhat/kerberosobject.schema
include         /etc/openldap/schema/ysulocal/eduPerson-schema
include         /etc/openldap/schema/ysulocal/ysuEduPerson.schema
access to * by * read
sasl-secprops none
sizelimit 50
TLSCertificateFile /usr/share/ssl/certs/slapd.pem
TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem
database        ldbm
suffix          "dc=ysu,dc=edu"
rootdn          "cn=Manager,dc=ysu,dc=edu"
*rootpw edited*
directory       /var/lib/ldap
index   objectClass,uid,uidNumber,gidNumber,memberUid,member    pres,eq
index   cn,sn,givenname,o,ou,mail,telephoneNumber       pres,eq,sub
index   eduPersonAffiliation,eduPersonPrimaryAffiliation        pres,eq
index   eduPersonNickname,eduPersonPrincipalName        pres,eq,sub
index   ysuEduPersonMajor,ysuEduPersonSchool            pres,eq
index   ysuEduPersonOutlookDept                         pres,eq,sub
access to attr=userPassword
        by self write
        by anonymous auth
        by * none
access to attrs=mail,uid
        by * peername="IP=127\.0\.0\.1" read
        by * peername="IP=150\.134\.10\.20[123]" read
        by anonymous search
        by group="cn=Staff,ou=DNGroups,dc=ysu,dc=edu" read
        by group="cn=Faculty,ou=DNGroups,dc=ysu,dc=edu" read
        by * search
access to attr=entry
        by * read
access to *
        by * peername="IP=127\.0\.0\.1" read
        by * peername="IP=150\.134\.10\.20[123]" read
        by anonymous none
        by group="cn=Staff,ou=DNGroups,dc=ysu,dc=edu" read
        by group="cn=Faculty,ou=DNGroups,dc=ysu,dc=edu" read
        by * none

/etc/openldap/schema/ysulocal/eduPerson-schema
attributetype ( 1.3.6.1.4.1.5923.1.1.1.1 
        NAME 'eduPersonAffiliation' 
        EQUALITY caseIgnoreMatch 
        SUBSTR caseIgnoreSubstringsMatch 
        DESC 'eduPerson per Internet2 and EDUCAUSE' 
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
attributetype ( 1.3.6.1.4.1.5923.1.1.1.2 
        NAME 'eduPersonNickname' SUP name 
        DESC 'eduPerson per Internet2 and EDUCAUSE' 
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
attributetype ( 1.3.6.1.4.1.5923.1.1.1.3 
        NAME 'eduPersonOrgDN' SUP distinguishedName 
        DESC 'eduPerson per Internet2 and EDUCAUSE' 
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.5923.1.1.1.4 
        NAME 'eduPersonOrgUnitDN' SUP distinguishedName 
        DESC 'eduPerson per Internet2 and EDUCAUSE' 
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )
attributetype ( 1.3.6.1.4.1.5923.1.1.1.5 
        NAME 'eduPersonPrimaryAffiliation' 
        EQUALITY caseIgnoreMatch 
        SUBSTR caseIgnoreSubstringsMatch 
        DESC 'eduPerson per Internet2 and EDUCAUSE' 
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.5923.1.1.1.6 
        NAME 'eduPersonPrincipalName' SUP name
        DESC 'eduPerson per Internet2 and EDUCAUSE' 
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.5923.1.1.2 
        NAME 'eduPerson' 
        SUP  'inetOrgPerson' 
        MAY ( eduPersonAffiliation $ eduPersonNickname $ 
                eduPersonOrgDN $ eduPersonOrgUnitDN $ 
                eduPersonPrimaryAffiliation $ eduPersonPrincipalName ) 
                ) 

/etc/openldap/schema/ysulocal/ysuEduPerson.schema
attributetype ( 1.3.6.1.4.1.10974.1.1.1.1 
        NAME 'ysuEduPersonMajor' 
        EQUALITY caseIgnoreMatch 
        SUBSTR caseIgnoreSubstringsMatch 
        DESC 'Student major from YSU database' 
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
attributetype ( 1.3.6.1.4.1.10974.1.1.1.2
        NAME 'ysuEduPersonMajorCode'
        EQUALITY caseIgnoreMatch 
        SUBSTR caseIgnoreSubstringsMatch 
        DESC 'Student major sought code from YSU database'
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15{3}' )
attributetype ( 1.3.6.1.4.1.10974.1.1.1.3
        NAME 'ysuEduPersonSchool'
        EQUALITY caseIgnoreMatch 
        SUBSTR caseIgnoreSubstringsMatch 
        DESC 'Student school from YSU database'
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
attributetype ( 1.3.6.1.4.1.10974.1.1.1.4 
        NAME 'ysuEduPersonSchoolCode' 
        EQUALITY caseIgnoreMatch 
        SUBSTR caseIgnoreSubstringsMatch 
        DESC 'Student school code from YSU database' 
        SYNTAX '1.3.6.1.4.1.1466.115.121.1.15{1}' )
attributetype ( 1.3.6.1.4.1.10974.1.1.1.5 
        NAME ( 'ysuEduPersonOutlookDept' 'department' ) 
        SUP ou )
objectclass ( 1.3.6.1.4.1.10974.1.1.2.1 
        NAME 'ysuEduPerson' 
        SUP  'eduPerson' 
        MAY ( ysuEduPersonMajor $ ysuEduPersonMajorCode $ 
                ysuEduPersonSchool $ ysuEduPersonSchoolCode $
                ysuEduPersonOutlookDept )
                )
Comment 1 John Morrissey 2002-04-21 16:07:35 EDT
If you can, you might want to try 2.0.22 (no RH RPMs AFAICT). From CHANGES:

OpenLDAP 2.0.22 Release
[snip]
    Fixed back-ldbm index threading bug
    Fixed back-ldbm ordering presence index bug

There were also some rather notorious index corruption bugs in earlier versions
of OpenLDAP (other RH bugs have referenced 2.0.11).
Comment 2 Darren Gamble 2002-08-16 11:23:46 EDT
I have the same problem.  I've tried 2.0.21 and 2.0.23 , and even a modified 
RPM with 2.0.25 .  They all have this problem.

I think there may be two seperate problems- one that seems to be with slapindex 
(did you try a slapindex after you did your import?  If so, try it without), 
and another where they are corrupted while the server is running (which is what 
the changelog reference refers to, I believe).

I also tried compiling against bdb 3.3.11.  This did NOT fix the problem, 
however, although it caused LESS records to be incorrect.
Comment 3 Richard L. Goerwitz III 2002-09-20 10:47:17 EDT
This problem seems (in my testing) to crop up only when I try to index
objectClass attributes with a gdbm back end.
Comment 4 Bill Nottingham 2006-08-07 13:44:02 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Comment 5 Bill Nottingham 2006-10-18 10:47:26 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.