Bug 60916
| Summary: | openldap not indexing properly with gdbm backend | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | John Dalbec <jpdalbec> |
| Component: | openldap | Assignee: | Jay Fenlason <fenlason> |
| Status: | CLOSED CANTFIX | QA Contact: | Aaron Brown <abrown> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | jfeeney, jwm |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-18 14:47:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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).
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. This problem seems (in my testing) to crop up only when I try to index objectClass attributes with a gdbm back end. 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. 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. |
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 ) )