Bug 431069 - ldapsearch -x query of uidNumber=500 now fails
ldapsearch -x query of uidNumber=500 now fails
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
rawhide
powerpc Linux
low Severity low
: ---
: ---
Assigned To: Jan Safranek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-31 11:11 EST by W. Michael Petullo
Modified: 2008-02-12 07:44 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-12 07:44:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
OpenLDAP configuration (48.98 KB, application/x-gzip)
2008-02-01 14:15 EST, W. Michael Petullo
no flags Details
LDAP database (3.85 KB, text/plain)
2008-02-01 14:19 EST, W. Michael Petullo
no flags Details
Debug output from "ldapsearch uid=mike" (succeeds) (171.15 KB, text/plain)
2008-02-08 06:57 EST, W. Michael Petullo
no flags Details
Debug output from "ldapsearch uidNumber=500" (fails) (156.59 KB, application/octet-stream)
2008-02-08 06:58 EST, W. Michael Petullo
no flags Details

  None (edit)
Description W. Michael Petullo 2008-01-31 11:11:38 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:
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
Comment 1 Jan Safranek 2008-02-01 09:21:50 EST
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
Comment 2 W. Michael Petullo 2008-02-01 14:15:44 EST
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.
Comment 3 W. Michael Petullo 2008-02-01 14:19:31 EST
Created attachment 293759 [details]
LDAP database
Comment 4 Jan Safranek 2008-02-07 10:14:03 EST
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 :(.
Comment 5 W. Michael Petullo 2008-02-08 06:57:00 EST
Created attachment 294343 [details]
Debug output from "ldapsearch uid=mike" (succeeds)
Comment 6 W. Michael Petullo 2008-02-08 06:58:33 EST
Created attachment 294344 [details]
Debug output from "ldapsearch uidNumber=500" (fails)
Comment 7 Jan Safranek 2008-02-11 10:48:03 EST
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 :).

Comment 8 W. Michael Petullo 2008-02-11 13:56:31 EST
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?
Comment 9 Jan Safranek 2008-02-12 07:44:32 EST
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.

Note You need to log in before you can comment on or make changes to this bug.