Your message dated Fri, 21 Dec 2007 00:10:28 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Bug#215315: slapd: index generation problem?
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: slapd
Version: 2.1.22-3
Severity: normal
Hi, I get the following rather interesting looking problem with OpenLDAP...
I haven't looked at the code, but it definitely appears to be an index
issue.
I found this, while fiddling with directory-administrator pointing to
sid's slapd. it tries to violate the schema by adding another
Structural objectClass to a Group object.
Here's a transcript of what happens:
[root]# ldapsearch -x -h localhost "(&(objectClass=posixGroup)(cn=sys))"
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (&(objectClass=posixGroup)(cn=sys))
# requesting: ALL
#
# sys, Group, ethernal.org
dn: cn=sys,ou=Group,dc=.....
objectClass: posixGroup
objectClass: top
cn: sys
gidNumber: 3
memberUid: mjb
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Ok, object is visible... lets delete an attribute:
[root]# ldapmodify -x -W -D cn=admin,dc=.....
Enter LDAP Password:
dn: cn=sys,ou=Group,dc=.....
delete: memberUid
modifying entry "cn=sys,ou=Group,dc=.....
[root]# ldapsearch -x -h localhost "(&(objectClass=posixGroup)(cn=sys))"
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (&(objectClass=posixGroup)(cn=sys))
# requesting: ALL
#
# sys, Group, ethernal.org
dn: cn=sys,ou=Group,dc=.....
objectClass: posixGroup
objectClass: top
cn: sys
gidNumber: 3
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Right. no problems, still visible. I'll add it again, just to prove that
this is ok:
[root]# ldapmodify -x -W -D cn=admin,dc=.....
Enter LDAP Password:
dn: cn=sys,ou=Group,dc=.....
memberUid: mjb
modifying entry "cn=sys,ou=Group,dc=.....
[root]# ldapsearch -x -h localhost "(&(objectClass=posixGroup)(cn=sys))"
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (&(objectClass=posixGroup)(cn=sys))
# requesting: ALL
#
# sys, Group, ethernal.org
dn: cn=sys,ou=Group,dc=.....
objectClass: posixGroup
objectClass: top
cn: sys
gidNumber: 3
memberUid: mjb
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Ok, still no problem. lets delete it again:
[root]# ldapmodify -x -W -D cn=admin,dc=.....
Enter LDAP Password:
dn: cn=sys,ou=Group,dc=.....
delete: memberUid
modifying entry "cn=sys,ou=Group,dc=.....
[root]# ldapsearch -x -h localhost "(&(objectClass=posixGroup)(cn=sys))"
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (&(objectClass=posixGroup)(cn=sys))
# requesting: ALL
#
# sys, Group, ethernal.org
dn: cn=sys,ou=Group,dc=.....
objectClass: posixGroup
objectClass: top
cn: sys
gidNumber: 3
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Now, lets modify, this time trying to add an objectClass that is a
violation.
[root]# ldapmodify -x -W -D cn=admin,dc=.....
Enter LDAP Password:
dn: cn=sys,ou=Group,dc=.....
objectClass: groupOfNames
memberUid: mjb
member: uid=mjb,ou=People,dc=.....
modifying entry "cn=sys,ou=Group,dc=.....
ldapmodify: update failed: cn=sys,ou=Group,dc=.....
ldap_modify: Cannot modify object class (69)
additional info: structural object class modification from
'posixGroup' to 'groupOfNames' not allowed
Ok, that failed... the object is still visible:
[root]# ldapsearch -x -h localhost "(&(objectClass=posixGroup)(cn=sys))"
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (&(objectClass=posixGroup)(cn=sys))
# requesting: ALL
#
# sys, Group, ethernal.org
dn: cn=sys,ou=Group,dc=.....
objectClass: posixGroup
objectClass: top
cn: sys
gidNumber: 3
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Lets try adding that attribute the previous way:
[root]# ldapmodify -x -W -D cn=admin,dc=.....
Enter LDAP Password:
dn: cn=sys,ou=Group,dc=.....
memberUid: mjb
modifying entry "cn=sys,ou=Group,dc=.....
And:
[root]# ldapsearch -x -h localhost "(&(objectClass=posixGroup)(cn=sys))"
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (&(objectClass=posixGroup)(cn=sys))
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
Where the fuck did it go?!?!?! :)
It appears to only be because of the "objectClass=posixGroup" query.. :
[root]# ldapsearch -x -h localhost "objectClass=posixGroup" | grep
"^dn.*sys"
[root]#
(Sorry, not showing you the contents of my directory... but it's not
there...)
cn=sys works fine as a query:
[root]# ldapsearch -x -h localhost "cn=sys"
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: cn=sys
# requesting: ALL
#
# sys, Group, ethernal.org
dn: cn=sys,ou=Group,dc=.....
objectClass: posixGroup
objectClass: top
cn: sys
gidNumber: 3
memberUid: mjb
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Stop/Start SLAPD, with a slapindex run:
[root]# /etc/init.d/slapd stop
Stopping OpenLDAP: slapd.
[root]# slapindex -v
...
[root]# /etc/init.d/slapd start
Starting OpenLDAP: slapd.
[root]# ldapsearch -x -h localhost "(&(objectClass=posixGroup)(cn=sys))"
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (&(objectClass=posixGroup)(cn=sys))
# requesting: ALL
#
# sys, Group, ethernal.org
dn: cn=sys,ou=Group,dc=.....
objectClass: posixGroup
objectClass: top
cn: sys
gidNumber: 3
memberUid: mjb
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
And it appears to be all back to normal..
slapd.conf has this for indexes:
# Indexing options for database #1
index objectClass eq,pres
index uid,uidNumber,gidNumber eq,pres
(and schemacheck is 'on', obviously)
Cheers,
Mike.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux toolbox 2.4.22 #1 Mon Oct 6 14:35:12 NZDT 2003 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages slapd depends on:
ii coreutils [fileutils] 5.0.91-2 The GNU core utilities
ii debconf 1.3.14 Debian configuration management sy
ii fileutils 5.0.91-2 The GNU file management utilities
ii libc6 2.3.2-8 GNU C Library: Shared libraries an
ii libdb4.1 4.1.25-9 Berkeley v4.1 Database Libraries [
ii libgcrypt1 1.1.12-4 LGPL Crypto library - runtime libr
ii libgnutls7 0.8.9-2 GNU TLS library - runtime library
ii libiodbc2 3.0.6-4 iODBC Driver Manager
ii libldap2 2.1.22-3 OpenLDAP libraries
ii libltdl3 1.5-2 A system independent dlopen wrappe
ii libmime-base64-perl 2.20-1 MIME/Base64 decoding for Perl
ii libsasl2 2.1.15-5.2 Authentication abstraction library
ii libslp1 1.0.11-4 OpenSLP libraries
ii libtasn1-0 0.1.2-1 Manage ASN.1 structures (runtime)
ii libwrap0 7.6-ipv6.1-3 Wietse Venema's TCP wrappers libra
ii perl [libmime-base64-perl] 5.8.1-2 Larry Wall's Practical Extraction
ii psmisc 21.3-1 Utilities that use the proc filesy
ii zlib1g 1:1.1.4-15 compression library - runtime
-- debconf information excluded
--- End Message ---
--- Begin Message ---
My guess is that this indexing problem was originally an LDBM backend
problem, which has now been fixed by dropping LDBM entirely. Anyway, no
response to a ping in June 2007. Closing.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--- End Message ---
