On Mon, 2008-10-13 at 22:17 +0200, Arthur de Jong wrote: > I will try to investigate this some more but help is appreciated with > this.
I have been able to reproduce the same behaviour with nss_ldap. If you
freshly mount a filesystem while the LDAP server is unavailable the
kernel will not re-ask idmapd to look up the usernames until the timeout
has expired.
I have dug a little through the code (nfs-utils, libnfsidmap and kernel)
and from what I understand is that the kernel should not cache negative
lookups. But idmapd seems to map IDMAP_STATUS_LOOKUPFAIL to
IDMAP_STATUS_SUCCESS which causes the kernel to remember the mapping.
This is done in:
nfs-utils-1.1.3/utils/idmapd/idmapd.c:674:
/* XXX: I don't like ignoring this error in the id->name case,
* but we've never returned it, and I need to check that the client
* can handle it gracefully before starting to return it now. */
if (im.im_status == IDMAP_STATUS_LOOKUPFAIL)
im.im_status = IDMAP_STATUS_SUCCESS;
Not sure who made the comment and if this still a valid comment. If this
is fixed this would result in negative entries not being cached at all
(except by nscd if it is enabled but the kernel would ask idmapd which
would ask nscd).
By looking though the kernel code (fs/nfs/idmap.c) there is no way to
flush the cache. Also, the value of /proc/sys/fs/nfs/idmap_cache_timeout
at the time the cache entry was created is used so it's no use in
lowering the value after the fact.
That means that I think the only way to fix this is in the short term is
to remove the LOOKUPFAIL to SUCCESS mangling from idmapd.c (which could
have other side effects) or to apply the workaround as described before.
Note that I have only read code and not done extensive debugging by
deploying modified versions of either kernel of idmapd.
There is one thing that is remaining a little puzzling in the kernel
code is the question about the cache retry. I can't explain the strange
timeout if you set the cache value really low like 1 jiffy. Then again I
don't know enough about jiffies and kernel internals to go hunting that
problem anyway.
What nss-ldapd could do is document that the Cache-Expiration option be
set. Perhaps a check could be implemented with a debconf note during
package installation.
Another option would be to start nslcd before nfs-common. This however
would probably break an environment where /usr is mounter over NFS. Also
that would cause problems because it is best to start nslcd after slapd.
--
-- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
