On 26 Mar 2010, at 07:46, masarati@aero.polimi.it wrote:

On 25 Mar 2010, at 01:15, Howard Chu wrote:

overlay pcache
proxycache bdb 100 2 6 1m
proxyattrset 0 uid userPassword uidNumber gidNumber gecos
cn homeDirectory loginShell objectClass
proxyattrset 1 cn userPassword gidNumber memberUid
uniqueMember objectClass
proxytemplate    (&(objectclass=)(uid=)) 0 3600
proxytemplate    (&(objectclass=)(uidnumber=)) 0 3600
proxytemplate    (&(objectclass=)(gidnumber=)) 1 3600
proxytemplate    (&(objectclass=)(|(memberuid=)(uniquemember=))) 1 3600
response-callback head

Your temporary fix is probably fine. Though, I'd consider this a bug: the
case should not matter. I suggest you file an ITS.

I think I'm starting to see the light now (yeah - like I thought a few posts ago...). The thing that Howard's config fixed (for me) wasn't the templates, as I first thought - it was the attribute sets for the queries. Our company schema needs to map a few attributes to alternative names (we don't use uniqueMember, we use plain old member instead; and our Unix login names go under the attribute llnwUnixUsername rather than uid). Fine - no problem there - nssov maps the names trivially.

However, the pcache will cache a query (and results) if the attribute set specified is a subset of the pcacheAttrSet - so clearly I needed to add those attributes to their relevant attribute sets. With that done, getent group <foo> and getent passwd <bar> would indeed cause results to be cached in the local DB.

What I was missing, it seems, was a couple of pCacheTemplates capable of triggering on the results for the searches prompted by nssov_passwd_all() and nssov_group_all() (e.g., when someone calls getent group, or getent passwd). So I added

and both the complete passwd db and group db ended up being cached as well. Great stuff (although maybe not a good idea for a very large company).

I don't think this is buggy behaviour, but it lead me to some unexpected results (ie, groups that weren't empty appearing to be so - meaning that the groups were cached, but their members were not in cache). I'm still hacking away on it, but it does seem that the relevant subset of our directory is being cached on my laptop outside of the office - so that's a major plus. Apologies to all for the false starts and so on, but perhaps my findings will help others make this step more easily. Especially when combined with sudo-ldap, it does make for a really good enterprise AAA system - even for partially connected use.