ObjectClass eq index corruption (ITS#1513)

[Ben Gertzfield <che@debian.org>]

[This is a repost, as the original bug report was bounced as being too
long.  The log has been snipped, but is available at the URL quoted.]

On 2002-01-04, our production servers running OpenLDAP 2.0.17 in a
widely-replicated system began to exhibit extremely strange behavior
after running stably for three months.

We are using OpenLDAP for authentication and home directory
information for a large email cluster using qmail-ldap, and have many
users like:

dn: uid=sysadmin_alien.jp,ou=people,ou=bbol,o=gmo
uid: sysadmin_alien.jp
objectClass: qmailuser

(just a sample of the LDIF for this user).  qmail-ldap does searches
of the form:

(&(objectClass=qmailuser)(uid=sysadmin_alien.jp))

when authenticating for POP-3 and SMTP AUTH.

However, ever since about 2002-01-04, for about 1/3rd of our users,
even though they have objectClass set to qmailuser, searches like the
above fail.  We are indexing on objectClass in slapd.conf:

index   objectClass             eq

which seems to be exhibiting some horrible corruption.

bash-2.03$ ldapsearch -h 172.16.5.100 -b ou=bbol,o=gmo -D cn=admin,o=gmo -W -x '(uid=wataru_ryoke@bbol.jp)' uid objectClass             
Enter LDAP Password: 
version: 2

#
# filter: (uid=wataru_ryoke@bbol.jp)
# requesting: uid objectClass 
#

# wataru_ryoke@bbol.jp, people, bbol, gmo
dn: uid=wataru_ryoke@bbol.jp, ou=people, ou=bbol, o=gmo
objectClass: infranetuser
objectClass: top
objectClass: organization
objectClass: organizationalUnit
objectClass: posixAccount
objectClass: account
objectClass: shadowAccount
objectClass: qmailuser
objectClass: inetOrgPerson
uid: wataru_ryoke@bbol.jp

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

You can see that objectClass for wataru_ryokeincludes qmailuser.
However, a search filtered on
(&(objectClass=qmailuser)(uid=bcj_goodtime.jp)) returns nothing:

bash-2.03$ ldapsearch -h 172.16.5.100 -b ou=bbol,o=gmo -D cn=admin,o=gmo -W -x '(&(objectClass=qmailuser)(uid=wataru_ryoke@bbol.jp))' uid objectClass
Enter LDAP Password: 
version: 2

#
# filter: (&(objectClass=qmailuser)(uid=wataru_ryoke@bbol.jp))
# requesting: uid objectClass 
#

# search result
search: 2
result: 0 Success

# numResponses: 1

This is really upsetting.  What's worse, is that the behavior
*CHANGES* over time!  Some days, some users will work with queries
like (&(objectClass=qmailuser)(uid=wataru_ryoke@bbol.jp)) and other
days, they will not.

I have a debug log (level 4095) of a session that failed in this
manner (with uid=bcj_goodtime.jp) below.  I have snipped all packets
with passwords in them, but that shouldn't be important.

Notice that bcj_goodtime.jp has objectClass=qmailuser, but the search
for (&(objectClass=qmailuser)(uid=bcj_goodtime.jp)) fails.
Interestingly enough, this is one of the users that later shows up
just fine with such a query.

If it would be any help, I have made a tar archive of the misbehaving
Berkeley DB 3.2 db db files.  It is available at:

http://nausicaa.interq.or.jp/ldap/

The log below is also available at the above URL.

If you need any more information, please feel free to contact me.

Ben

-- 
Brought to you by the letters E and C and the number 3.
"I wanna be Twist Barbie!"
Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/