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.

If it helps - OpenLDAP 2.4.21 running on Ubuntu Karmic amd64, BDB 4.7.

Cheers,

Neil




NEIL DUNBAR
Systems Architect

(602) 850-5783 work
+44 7976 616583 mobile
+1 (602) 535-6914 US mobile