Bug 145310
Summary: | nss_ldap 227 & 232 kills network logins | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nicolas Mailhot <nicolas.mailhot> |
Component: | nss_ldap | Assignee: | Nalin Dahyabhai <nalin> |
Status: | CLOSED DEFERRED | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | bugzilla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-12-10 21:32:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Nicolas Mailhot
2005-01-17 11:06:21 UTC
I can confirm this, but nss_ldap-220-3.x86_64 does not work either, so it's impossible to log in with ldap at all! I was able to login by replacing "URI" directive with "HOST". See bug #135228 Add bugzilla to Cc List Regarding comment #2 -> did you log in with 227 or 220 ? I can confirm 220 works with host, in fact this is how this box has been setup forever I can't remember now. The host that is working has 226-2 installed, which was the previous version from rawhide. Unfortunately I do not have a copy of the rpm, so for now I will have to use host. Ok if you still have 226-2 sitting in you yum/apt cache I'm interested - I'm pretty sure it works unlike 227 but I'd like to make sure As for the host/uri problem -> this is not the subject of this particular bug, since the bow I'm reporting it from uses host I found a copy here: http://fedora.mirrored.ca/fedora/development/x86_64/Fedora/RPMS/nss_ldap-226-2.x86_64.rpm Ok, thanks, I can confirm then that the problem is with 227 and 226-2 works here (on x86, krb5+ldap auth) I did a fresh installation of fc3.x86_64, and so far I have been unable to log in at all using any version of nss_ldap. The configuration is identical to a working i386 host. I even set /etc/ldap.conf as a symlink to /etc/openldap/ldap.conf, and did a search with ldapsearch, which returns the correct information. The messages are:- /var/log/secure: Jan 19 11:07:48 miranda login[23221]: pam_succeed_if: error retrieving information about user chills /var/log/messages: Jan 19 11:07:48 miranda login(pam_unix)[23221]: authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= Jan 19 11:07:48 miranda login(pam_unix)[23221]: could not identify user (from getpwnam(chills)) Jan 19 11:07:48 miranda login[23221]: User not known to the underlying authentication module nss_ldap.i386 0:232-1 still broken I can confirm this bug (FC3, with openldap 2.2.23; nss_ldap > 226 does not work). It is also reported on the PADL-site, but I have not seen any reaction from them. I think it has something to do with trying to make a permanent connection with the directory server. With nss_ldap-234-1 all problems are gone !! Thanks .. Alfred, I can't find that version on Rawhide. Where did you obtain it from? BTW I no longer have access to the systems where this bug manifested, so I'm not the one to close this The Fedora download server has the new version (nss_ldap-234-1) available under the development directory !! Good luck. It has also the new version of OpenLDAP (2.2.23) available. But be carefull with it: it is compiled against its own version of db4 (version 4.3.27). This means that you have to upgrade your own FC3 to db4-4.3.27, otherwise your database utilities will not work (e.g. db_recover). If you do, please do not forget to install compat-db, for your non-upgraded FC3 programs !!!!! Additional remark on OpenLDAP version 2.2.23. I found it necessary to change the init-script of OpenLDAP to remove the __db.00? files from /var/lib/ldap/directory on every startup. This was the only way to assure correct startup of OpenLDAP in case of a system crash (which happens to often to me). Also add the -u option to slaptest in the init-script to assure a proper test of the config-files !!!! Have fun with testing ... ! I'm closing this one as it's not seing any activity and I can't test it anymore |