lists.arthurdejong.org
RSS feed

[nssldap] Re: Re: disconnected nss_ldap

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

[nssldap] Re: Re: disconnected nss_ldap



On Sat, 2009-10-24 at 03:49 -0400, Ryan Lynch wrote:
> So nscd IS caching shadow info (password hashes), for you?

As you discovered, no.  I am using kerberos for authentication.

> I'm using some pretty high TTLs on disconnected machines,

The problem with high TTLs is that changes you make to your LDAP NSS
data takes too long (i.e. the TTL -- which needs to be like 30 days to
avoid dropping entries before you really want to) to get updated to the
nscd-running machines despite being connected to the LDAP server.

> 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

Yeah.  I talked about this bug in one of my previous posts here and
also, as you've probably noticed, I commented on that bug, but Mr.
Drepper seems to be simply ignoring the real-world evidence that his
proposed solution, "reload-count unlimited" just doesn't work.

> nscd drops a cached name if the TTL expires without it b eing
> requested, regardless of the 'reload-count' setting.

Yeah.  So what's the point of "reload-count", then really, yes?

> 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.

Which is just silly.

> So basically, you have to set your TTLs
> pretty high,

And let your cached data get stale, despite having easy access to the
fresh data.

> or you need to convince Ulrich Drepper to make nscd
> smarter.

Well, bug 2132 sure doesn't give anyone any warm fuzzies that he's
actually willing to listen to how nscd works (or doesn't as the case may
be) in the real world vs. how he thinks it's suppose to operate.  He is
simply ignoring the evidence that demonstrates that he's wrong.

I wonder how difficult the fix is to not drop records who's TTL expires
before they are re-requested.  I can't imagine terribly so.  I wonder if
he'd be more (or at all) responsive to a patch than he has been to the
presentation of evidence that his solution simply doesn't work in the
real world.

b.