From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6 Description of problem: Command 'getent' doesnt returns items stored in ldap. I had a working FC3 server where all users was stored on ldap. Commands 'id' and 'getent' always showed needed info about these users. After upgrade to FC4, the getent never returns passwd or group info about these users, so many program (vsftpd and more) doesnt work. As result, the system is unusable. Version-Release number of selected component (if applicable): glibc-2.3.5-10.3 How reproducible: Always Steps to Reproduce: 1. Store users account in ldap 2. Run 'getent passwd' Actual Results: Command doesnt return none info about ldap users. # getent passwd | grep tom # Expected Results: # getent passwd | grep tom tom:x:1014:513::/home/tom:/bin/bash # Additional info: # id tom uid=1014(tom) gid=513(Domain Users) groups=513(Domain Users) # # grep ldap /etc/nsswitch.conf passwd: files ldap shadow: files ldap group: files ldap
Are you using nscd? Does getent passwd tom work (as opposed to getent passwd | grep tom )?
Uff! It depends on how the getent is called and if the nscd is running or not: # service nscd start Starting nscd: [ OK ] # getent passwd | grep tom # # getent passwd tom tom:x:1014:513:System User:/home/tom:/bin/bash # # service nscd stop Stopping nscd: [ OK ] # getent passwd | grep tom # # getent passwd tom # I did also discovered that this bug is only occurs if you are root or if program runs with root priviledges. The common non-root user have no problem even the nscd is running or not and even he runs 'getent passwd tom' or 'getent passwd | grep tom'. The openldap's slapd is used with default unmodified ACLs. I did test to retrieve tom's LDIF with and without cn=Manager rights and did look at diff and did not found anything strange: $ ldapsearch -x uid=tom | sort > /tmp/nonmanager.txt $ ldapsearch -x -W -D "cn=Manager,dc=company,dc=cz" uid=tom | sort > /tmp/manager.txt Enter LDAP Password: ********* $ diff -ruN /tmp/nonmanager.txt /tmp/manager.txt (Result is attached as file diff.txt)
FIXME -- file diff.txt is empty of course. Time to one more cup of coffee tonight.
Can you then: 1) stop nscd 2) strace getent passwd tom as root 3) strace getent passwd tom as normal user See where they differ?
Jakub, good point! I did found difference. Non-root request is done as anonymous ldap bind, what is OK. Root request is done as DN 'rootbinddn' defined in /etc/ldap.conf with password taken from file /etc/ldap.secret. This request always fails with ldap "invalidCredential" error. glibc-2.3.5-0.fc3.1 sends password WITHOUT "\n" so it is OK while glibc-2.3.5-10.3 sends password WITH "\n" so it FAILS. Ldap server make difference between "password" and "password\n" I dont know, what code exactly changed from FC3 to FC4 epoch.
This has nothing to do with glibc. nss_ldap handles all the LDAP details.
That's a bug in nss_ldap 234 -- the newline isn't stripped off properly. This is fixed in Raw Hide, and will be fixed in nss_ldap-234-8.
I backported this fix from 235 to 234 and it is working very well. Hope we will see this in 4/update/testing soon.
Created attachment 118140 [details] Strip newline from password. Strip newline from password patch from nss_ldap-235.
This bug is pretty fatal. It breaks down all samba PDC based networks. Until the official fix will come (this century I hope) the fixed packages are on http://crash.fce.vutbr.cz/crash-hat/4/nss_ldap/
What I see is that 'getent passwd | wc -l' always return 539 users, even if there is more users in the LDAP DB. I have created a special users for nss_ldap to connect to openldap, as described in this howto: http://samba.idealx.org/smbldap-howto.en.html#htoc31 What does this "magic" 539 number means?
(In reply to comment #0) > # id tom > uid=1014(tom) gid=513(Domain Users) groups=513(Domain Users) If the command id works, then you need to add this option to /etc/openldap/slapd.conf: sizelimit unlimited This solved my problem, now 'getent passwd | wc -l' returns all users HTH
The sizelimit thing isn't related to the original filer's bug -- changing the bug summary to reduce confusion.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Fixed in upstream. Closing the bug.