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: openldap-2.4.7-6.fc9.ppc.rpm How reproducible: Every time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: 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 (openldap-2.4.7-6.fc9.i386). 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. Please attach - 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] OpenLDAP configuration This is the OpenLDAP configuration that I am using (LDIF follows in next attachment). ldapsearch -x uid=mike works. ldapsearch -x uidNumber=500 does not return anything.
Created attachment 293759 [details] LDAP database
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 searches. 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.