Description of problem: Version-Release number of selected component (if applicable): glibc-2.3.6-3 pam_unix2-1.30-1 (custom rpm) nis-utils-1.5-2 (custom rpm) How reproducible: 100% Steps to Reproduce: 1. Upgrade to glibc 2. Attempt to login 3. Unknown user Actual results: User is not allowed to login Expected results: User logs in Additional info: The problem is with the libnss_nisplus module only. I copied /lib64/libnss_nisplus-2.3.5.so from a FC4 box still running glibc-2.3.5-10.3 and everything works properly.
*** This bug has been marked as a duplicate of 186592 ***
Hello Jakub, Are you sure that this is a duplicate? It seems that most people are complaining about the system not working correctly when NIS+ is defined in nsswitch.conf. In my case we are actually using NIS+. The autofs and niscat programs are able to communicate with our NIS+ Server, but unless I copy the libnss_nisplus-2.3.5.so from an older glibc then this machine is unable to authenticate our users via NIS+. Thanks, Erik
Yes, I'm sure it is a duplicate, it is the same bug already fixed in glibc CVS and rawhide rpms. libnss_nisplus* had a bug where it caused failures whenever it was listed in nsswitch.conf, wihch includes both the case where it is there by mistake (and no nis+ is configured on the box) or when it is used intentionally. There will be new glibcs released in a week to fortnight timeframe. *** This bug has been marked as a duplicate of 186592 ***
The new update (end of comment #3) got stuck in testing. Was there a problem with it or was that just an oversight? In any case, please fix for FC4. Thanks!
Since FC4 is getting close to transitioning from supported to unsupported except for fedoralegacy, a working release should be pushed into update for the users of the release that don't run updates-testing can transition into legacy with a better distribution. Fixed in rawhide should not be the goal for a transitioning release. Fixed in updates should be the solution. Will comment #3 regarding the new release of a glibc packages be pushed into updates before the legacy transition?
Fix uploaded to: http://people.redhat.com/jakub/glibc/2.3.6-5/ Whether the Fedora Legacy project chooses to issue it officially or not is their decision.
Legacy testing and QA work on this bug will be continuing in bug 200963, working with Jakub Jelinek's glibc-2.3.6-5.src.rpm. Thank you, Jakub!
Fedora Core 4 is now completely unmaintained. These bugs can't be fixed in that version. If the issue still persists in current Fedora Core, please reopen. Thank you, and sorry about this.