lists.arthurdejong.org
RSS feed

Re: [nssldap] Re: disconnected nss_ldap

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: [nssldap] Re: disconnected nss_ldap



On Sat, Oct 24, 2009 at 02:17, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
> On Sat, 2009-10-24 at 01:38 -0400, Brian J. Murrell wrote:
>>
>> But as soon as the LDAP server is available again, ssh to the node works
>> just fine.
>
> I fixed this.  This is because of pam_unix's account mode.  It wants to
> verify the shadow entry when the passwd entry contains a "x" for the
> password -- hence my previous thread about fixing this in nss_ldap.
> Adding broken_shadow to pam_unix's entry in the account mode works
> around it.

So nscd IS caching shadow info (password hashes), for you? I didn't
think it would handle that, but I guess it makes sense. In that case,
I'm not sure if there's an advantage to useing 'pam_ccreds' and
'pam_ldap' over nscd's shadow caching.


>> Indeed.  My experiments were that even with unlimited, the passwd entry
>> for the current, logged in user disappeared.  I was going to demonstrate
>> on my Ubuntu Karmic laptop but I can't seem to reproduce this here.
>
> I spoke too soon/didn't wait long enough.
>
> Witness my laptop, where I am logged in (as brian), have nscd running
> with:
>        reload-count            unlimited
>        positive-time-to-live   passwd          60
>
> $ id brian
> id: brian: No such user
>
> I also have a user "keith" in my LDAP directory mapped into the NSS
> passwd map which I was testing with before when I thought it was
> working.  All this to say that "keith" should definitely be in nscd's
> persistent cache as I was executing "id keith" repeatedly, watching for
> it to disappear, and now, like the "brian" entry, it has:
>
> $ id keith
> id: keith: No such user
>
> So for whatever reason, NSCD is expiring entries from it's persistent
> cache despite the "reload-count unlimited".  ~sigh~

I'm using some pretty high TTLs on disconnected machines, and some
Kerberos house-keeping scripts that generally make sure nscd's cache
gets hit more often than the TTL time. There's a reason for the
enormous TTLs, too, which it looks like you may have already
discovered?

    http://sources.redhat.com/bugzilla/show_bug.cgi?id=2132

nscd drops a cached name if the TTL expires without it b eing
requested, regardless of the 'reload-count' setting. To effectively
use it for disconnected operations, you need to be reasonably certain
that some local activity will trigger a lookup on each cached name
more often than the TTL time. So basically, you have to set your TTLs
pretty high, or you need to convince Ulrich Drepper to make nscd
smarter.

-Ryan