Re: nslcd and nscd

[Arthur de Jong <arthur [at] arthurdejong.org>]

On Thu, 2016-03-03 at 17:06 +0100, Arnau wrote:
> some processes in my system triggers a nslcd query with "group(all)":
> [...]
> nslcd: [3c9869] <group(all)> DEBUG: ldap_result(): end of results (0
> total)
> [...]
> 
> In our environment a "group all" query takes minutes (cause we use
> nested groups and we have a huge list of groups), so I'm wondering if
> there is a way to tell nslcd to pass that query to nscd (in other
> words, why is group=(all) not being served by nscd?)

I think neither classic nscd or unscd can cache (all) queries due to
their nature. I think they always fall back to the NSS backend (though
there could be some aggressive caching options that could help).

It's not clear to me how a query that returns 0 results as seen in your
log output can take very long.

> In order to improve nslcd I think that nss_getgrent_skipmembers
> / nss_disable_enumeration could improve the performance of the
> service. Could someone give me some feedback (pros/cons) about those
> options? In both cases the man page says :" This option is not
> recommended for most configurations."

The problem is that some applications list all users and groups for
legitimate purposes or can get confused if groups don't have any
members. I know nscd caches the results of these lookups (then again I
don't think it only uses the cache for the get-me-the-groups-for-this-
user queries). You should probably test carefully before enabling this
in production.

> Also, I have a question about nslcd cache: the man page does not say
> too much about it's size, how many entries it can keep, etc...can it
> beahve as a replacement of nscd?

It does not replace nscd. The only thing that it caches is the DN to
uid lookups. If you have groups that use the member attribute nslcd
needs to perform an extra lookup per DN value to get the uid value. It
tries to be smart about this and use the uid attribute from the DN if
it is mentioned there but otherwise it needs to do an extra lookup. The
cache will not be used at all if the LDAP server supports the deref
control.

Hope this clarifies things,

-- 
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org/ --

-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/