Red Hat Bugzilla – Bug 431069
ldapsearch -x query of uidNumber=500 now fails
Last modified: 2008-02-12 07:44:32 EST
Description of problem:I am using LDAP for network information. The following query does not work when using the latest version:
ldapsearch -x uidNumber=500
nss_ldap makes a similar query when a user logs in and it also fails, so the issue does not seem to be in ldapsearch.
Version-Release number of selected component:
Steps to Reproduce:
Additional info:"ldapsearch -x uidNumber=500" works fine after I downgrade to Fedora 8's openldap, openldap-clients, openldap-servers, openssl and nss_ldap
I am not able to reproduce it - ldapsearch -x uidNumber=500 works for me
What I have done:
- edit default /etc/openldap/slapd.conf, just uncomment "rootpw secret"
- service ldap start
- edit /etc/openldap/ldap.conf, uncomment "BASE dc=example, dc=com"
- add some users using migrationtools (migrate_base.pl and migrate_passwd.pl)
-> I can search with uidNumber=500 filter.
- content of your /etc/openldap/ directory (without passwords, of course)
- ldif export of your ldap database (few users should be enough, just to
reproduce the bug)
Thanks in advance
Created attachment 293758 [details]
This is the OpenLDAP configuration that I am using (LDIF follows in next
ldapsearch -x uid=mike works.
ldapsearch -x uidNumber=500 does not return anything.
Created attachment 293759 [details]
I am still not able to reproduce it. I found a timeslot on a PPC here and even
with you config and your database I am able to do ldapsearch -x uidNumber=500
(without ldaps://, but that does not matter IMO).
Frankly, I am getting out of ideas... Could you please (preferably on another
machine) install rawhide + openldap, create new database, import your users and
try it there? If it is still does not work (which I doubt, but...), then please
try to generate slapd.log, and try to compare search with uid=mike and
uidNumber=500, maybe there is something interesting. Attach these logs (with
maximum log level, i.e. 4294967295) to the bug.
If you do not have another machine, please attach at least the log with the two
How to get slapd log:
service ldap stop
slapd -d <log level> > slapd.log
Log level: -d 1 is usually enough, use -d 4294967295 for extra detailed logs.
Check man slapd for another options (e.g. you want ldaps://).
BTW, do not use MODIFIED Bugzilla state, it means "This bug has had a fix
generated and tested by the component owner, and the code has been checked into
CVS." - and we do not have fix yet :(.
Created attachment 294343 [details]
Debug output from "ldapsearch uid=mike" (succeeds)
Created attachment 294344 [details]
Debug output from "ldapsearch uidNumber=500" (fails)
There is something wrong with your bdb database - looking at the logs, I can see
" bdb_index_read: failed (-30989)", which means "Key/data pair not found (EOF)".
Could you please run slapindex to reindex your db (beware, it can change owner
of the database files to root, run 'chown ldap:ldap /var/lib/ldap/* afterwards')
and if it does not help, then export you db to ldif, clear the database (rm -rf
/var/lib/ldap/*) and restore the database again from the ldif?
Or use different backend as last resort - I know it's not the advice you want to
hear from me, but I am sure it helps :).
Running slapindex seems to have fixed my problem.
It seems there still may be a bug, as the database became corrupt. Or, perhaps
the openldap clients should be more verbose when an error is encountered, even
if debugging is turned off.
Do you think there is anything that should be investigated more?
I cannot guess what damaged your database, try to check your hardware and reopen
the bug if it happens again.
Regarding the ldapsearch output, I think it's verbose enough, the problem was in
the server - it did not find any entry with uidNumber=500, so the client
displayed no entry, that's how it should behave. Even the server did not
recognize that the database indexes are broken.