Putting this back on list since it may be relevant.

On 24 February 2011 15:16, Dimitri Maziuk <dmaz...@bmrb.wisc.edu> wrote:
> On 2/24/2011 1:55 AM, Brett Delle Grazie wrote:
>>
>> Hi,
>
>> Timeouts (connect, bind and retry count) can also be specified in
>> ldap.conf.
>> Can you use a caching daemon (nscd or preferably nslcd) to avoid your ls
>> -l
>> problem?
>
> Yes and yes. However,
> a) you can't set timeouts below tcp timeouts (well, you can, but it doesn't
> make sense), and the latter are set system-wide. Reducing them will affect
> every tcp/ip application, which may or may not cause problems.
> b) The problem with cache is consistency. It works great when nothing ever
> changes, when e.g. someone changes their password, the caches have to be
> invalidated all over the place. Which is not how it works. You can reduce
> retention intervals, but then you're back to square 1.

I don't think you can get around this without caching of some sort -
NSCD / NSLCD both have Time To Live (TTL) values for positive and
negative results.

1) I cache only group and passwd information (i.e. user IDs, group IDs), never
shadow or hosts (see below)/
2) I purposefully disable permanent caching (in memory only, restart
clears cache).
3) TTL for positive results I set to 5 minutes, negative to 1 minute YMMV.

This solution means you're at most 5 minutes away from being able to login with
a newly created user. While at the same time reducing network traffic
and load on
LDAP directory.

For DNS, I'd consider a local caching resolver that correctly honours TTLs.

>
> Irix and solaris come with nscd enabled by default (on irix it's called
> something else). On both systems I had to manually restart nscd after a dns
> change (record updated or deleted), a password change, locking user account,
> etc., every time.

As I indicated - I disable the 'hosts' cache for this very reason. DNS
is one of those
things you don't want local caching without properly honouring TTL
values - and NSCD is
notorious for bugs / issues / problems with its hosts and shadow
caching capabilities.
Admittedly ... things should have improved with more recent versions
but I haven't
been tempted to check.

>
> We had problems ("shell freezes") with one-server openldap setup after
> initial ldap migration. 2nd server didn't help, but switching to
> active/passive "R1" cluster did. For roughly the same amount of setup as 2
> servers with syncrepl and fine-tuning tcp parameters.

Most likely just caching passwd / group with low fixed TTL values (5
min +ve, 1min -ve)
would resolve this.

Good luck.

>
> Dima
>


-- 
Best Regards,

Brett Delle Grazie
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to