On 7 Mar 2010, at 23:28, Howard Chu wrote:
And while nssov is really cute, since it exists in the same process space as
slapd, it doesn't end up triggering the pcache, which does gets fired upon
incoming LDAP requests from an external process (nslcd). It's probably that I
just suck, and didn't configure slapd quite right, but that's why I ended up
still using nslcd and slapd on the same box.
Hm, you probably have them configured in the wrong order. I specifically
designed nssov and pcache to work together, and they do.
OK - I'm stuck: yes - I realise I suck, but at the moment, I'm just spinning
on this one. Howard/Quanah/anyone - can you post a sample config which lashes
together nssov and pcache? At least it would help me see what's supposed to be
the order of events.
I think my config is about as simple as it gets, back-ldap proxying to our
real directory, then loading nssov, then pcache on a BDB backend (Although
I've tried reversing pcache and nssov to no avail). pcache configured to cache
the filters issued from nslcd/nssov.
The nssov overlay works perfectly - fetching passwd and group databases from
the directory like a champ.
Similarly, if I do an ldapsearch on the proxy, using the nslcd filters - all
is well, the local cache DB gets populated, with the right indices. If I fire
up nslcd pointing to ldapi:///, I get the both the system databases working
and caching working fine.
But nssov just doesn't seem to find its way through to the pcache. I can post
the config - but it's pretty much identical to the ones in Symas's AAA paper.
It's so annoying - I absolutely believe that I'm about a heartbeat away from
getting it cracked, but the final solution is beyond my tired brain.