From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 Description of problem: After changing the password on our NIS-Server, the client does not use the new password while nscd is active. With deactivated nscd the new passwords are delivered. Restarting nscd gives again the old password. Timeouts in /etc/nscd.conf are the default values (600 sec), but I get the old password even after 3 days Version-Release number of selected component (if applicable): glibc-2.3.4-2.fc3 nscd-2.3.4-2.fc3 How reproducible: Always Steps to Reproduce: 1. Change password on NIS Server 2. wait 30 min 3. getent passwd user 4. getent passwd | grep user Actual Results: "getent passwd user" gives me the old password hash, while nscd is active "getent passwd|grep user" gives me the new hash, same for "ypcat passwd" Expected Results: After the 10 minutes timeout I expect to se the new hash values Additional info: No information about any problems in /var/log/messages Output from nscd -d -d -d: 12368: Access Vector Cache (AVC) started 12368: handle_request: request received (Version = 2) from PID 12376 12368: GETFDPW 12368: provide access to FD 5, for passwd
On FC3, I suffer of the same symptoms, but with hostnames. It returns old invalid IPs when resolving hostnames and the cache never gets updated. This happens with the same version reported above. nscd simply does not update its cache anymore.
Just got bitten by stale entries in nscd's hostname cache (FC3). This can lead to a numer of pretty bad problems, so I am increasing the severity.
I'm seeing this too. Was just going to post to fedora-test-list. It seems caches only get flushed when the files get touched, and not when the TTL has expired. Here's the post: We've been seeing nscd cache expiration problems every now and then like I mentioned a few months back with both passwd and hosts. Has happened often enough that it's not just a local configuration issue It seems like positive hits just don't time out, and nscd -i is the only thing that clears things up. passwd/hosts "never" get touched (we're using NIS+, customized local install), so the entries don't get invalidated that way, which might be the reason not that many other people are seeing the same problem. Another symptom I've sometimes seen is a DDNS host have an old address for days (until nscd -i hosts). nslookup, which doesn't go through nscd, shows the current address. nscd is running with default timeouts (600 secs for passwd, 3600 for hosts) Will be happy to get data to track this down. I suppose there's no database dumper that would tell what nscd is actually currently caching and how old the data is? I've actually ran nscd for quite some time in debug mode, and the only situation it flushes entries is touch /etc/passwd and touch /etc/hosts.
At our lab we have the same issue. We are using LDAP authentication, user tend to change their passwords, and try to access their mail trough IMAP, the imap server uses the NSCD cache, and oops failed. As discused in an erlier thread this is a disign issue, nscd was never tought to be use in this fasion. We have been able to control this trhough the configuration file. We reduce the lifetime of the hash tables, set the caches to be NON persisten. (that is right, no matter how many times you restart the service the cache does not flush unless this option is enabled.), and set the service to auto restart every 10 minutes. The overall preformance does not seem to be afected.
This bug has been raised to secalert as having possible security consequences due to stale DNS/auth/etc.
I checked into the upstream cvs a patch which might cure this problem. I don't know whether this is the case since nobody bothered to provide debug output. Hopefully we'll have a new rawhide version soon.
nscd-2.3.5-4 has this fix in.
Any chance for an FC3 errata?
Still no RHEL update over a month after nscd fix was found. We're beginning to doubt weither maintaining our "Enterprise" subscriptions is really worthwhile, compared to Fedora. What's stability without security and bug fixes?
This bug fix is scheduled for RHEL4 U2, it came too late to be included in RHEL4 U1.
Is a rawhide RPM with this fix that will be included in U2 available somewhere?
I'm happily using rawhide/FC4's nscd (only, not the other bits of glibc) on FC3, since an errata update doesn't seem to be coming any time soon for FC3 either. You might have luck on RHEL as well. Since the default nscd is pretty much unusable if you are hitting this bug it's unlikely it's going to make things any worse :-)
The rawhide/FC4 rpms will not be included in RHEL4 U2. Instead, the patch (among other fixes collected for U2) will be backported. If you want to rebuild glibc yourself, the fix is: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nscd/connections.c.diff?cvsroot=glibc&only_with_tag=fedora-branch&r1=1.55.2.7&r2=1.55.2.8 Running FC4/rawhide nscd on RHEL4 could work too.
RHEL4 U2 initial glibc testing RPMs that should address also this problem uploaded to ftp://people.redhat.com/jakub/glibc/2.3.4-2.10/
According to comment #8, this fix has been in rawhide for three months now, but still now FC 3 update. What's the status?
It is in FC3 testing updates ATM.
This ticket is listed as closed, but there's still no FC 3 update. Is this ever going to come out of rawhide?
Just got another update saying that a clone of this bug (BugID 164812) was fixed... But there's still no FC 3 update. I suppose FC 3 will simply become unsupported soon, and be forgotten entirely.