I recently came across the nfsidmap -c option. I haven't thoroughly
tried to reproduce the problem but nslcd 0.9.1-1 in experimental has an
option to flush various caches. You could put
reconnect_invalidate nfsidmap
in nslcd.conf. I'm not 100% sure if this fixes the problem but can you
reproduce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 14 Oct 2008, Patrick Schoenfeld wrote:
That does not seem to be the root of the problem. I've built nfs-utils
with these lines commented out on one of my systems and disabled the
workaround in idmapd and the problem persists.
Thanks for i
Hi Arthur,
On Tue, Oct 14, 2008 at 12:18:11AM +0200, Arthur de Jong wrote:
> 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 gra
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
retitle 500778 nss-ldapd: problem resolving groups and users with nfs4
severity 500778 important
tags 500778 + help
thanks
On Mon, 2008-10-06 at 11:42 +0200, Patrick Schoenfeld wrote:
> 2008/10/3 Arthur de Jong <[EMAIL PROTECTED]>:
> > Patrick, does adding "Cache-Expiration = 10" to /etc/idmapd.co
Hi,
2008/10/3 Arthur de Jong <[EMAIL PROTECTED]>:
> Patrick, does adding "Cache-Expiration = 10" to /etc/idmapd.conf in the
> [General] section help at all in your setup? (the correct values should
> be loaded sooner)
very good. This betters the situation a lot. Its a good workaround.
Now if you'
(Cc-ing the nfs-utils maintainers, perhaps they have some insight that
could solve this)
On Sat, 2008-10-04 at 09:52 +0200, Patrick Schoenfeld wrote:
> > My guess is that name lookups are cached in idmapd. Can you check that
> > by restarting idmapd (/etc/init.d/nfs-common restart) the problem goe
Hi,
On Fri, Oct 03, 2008 at 12:18:47AM +0200, Arthur de Jong wrote:
> If using nfs4 (I've been doing some reading up but still no first-hand
> experience) is that if the user doesn't exist it is generally mapped to
> nobody:nogroup.
right.
> The mapping is done by idmapd but at some point in com
On Thu, 2008-10-02 at 10:28 +0200, Patrick Schoenfeld wrote:
> attached is a log, while the problem exists.
>
> [EMAIL PROTECTED] ~ % ls -l test
> -rw-rw-r-- 1 schoenfeld nogroup 0 12. Sep 09:49 test
>
> Interesting enough: The symptom is similar to the system behaviour, if
> nslcd is _not_ runni
Hi,
On Wed, Oct 01, 2008 at 10:27:04PM +0200, Arthur de Jong wrote:
> Can you produce logs of nslcd? It should report whether the LDAP server
> was reachable or not. If you can run nslcd with the -d option it should
> report more information that will help in tracking this down.
attached is a log
Hi Arthur,
On Wed, Oct 01, 2008 at 10:27:04PM +0200, Arthur de Jong wrote:
> On Wed, 2008-10-01 at 13:11 +0200, Patrick Schoenfeld wrote:
> > Our setup is a mixed Windows/Linux environment with a LDAP server, for
> > central authentication. Linux clients use libnss-ldapd for resolution of
> > user
On Wed, 2008-10-01 at 13:11 +0200, Patrick Schoenfeld wrote:
> Our setup is a mixed Windows/Linux environment with a LDAP server, for
> central authentication. Linux clients use libnss-ldapd for resolution of
> usernames and groups.
Could you provide some more details? Is the LDAP server on the sy
Package: libnss-ldapd
Severity: serious
Version: 0.6.5
Hi,
since we use libnss-ldapd we have a problem that is quiet serious for
us, as it effectively affects login and group ACLs. However we couldn't
yet track down this issue to a specific component, therefore we didn't
report it yet.
The setup
13 matches
Mail list logo
