Jim van Keulen wrote:
Howard Chu wrote:
w.van.keulen@few.vu.nl wrote:
masarati@aero.polimi.it wrote:
Here are slapd.conf and proxycache.conf as attachments.
I just wanted to feed back before I leave for a few days. I don't see anything critical in your files. You explicitly give the rootdn write permissions, which is useless, but apart from this everything looks fine.
I've tested a simple setup and it works as expected. I used HEAD and re24 code; the latter is nearly identical to 2.4.17. I also tested with TLS.
At this point, I'm a bit clueless. There must be something we're overlooking.
Here is some more info, that I just discovered. If my filter rule is '(&(objectClass=sambaSamAccount)(uid=wvk))' the data is cached the first time, but not returned the second and later time. However when my filter rule is (&(objectClass=posixAccount)(uid=wvk))' it works as expected.
Sounds like you may have already had the entry in the cache DB but with an incompatible objectclass before, and the attempt to update it with the new objectclass failed. This seems to be related to ITS#6242 which was recently fixed in HEAD. Can you please retest with the latest overlays/pcache.c?
As you requested I retested with HEAD. However the cache is still not working correctly.
When my filter rule is: '(&(objectClass=posixAccount)(uid=<who>))' the named attributes are cached and correctly returned from the cache for every uid from the existing user base When my filter rule is: '(&(objectClass=sambaSamAccount)(uid=<who>))' the named attributes are cached and correctly returned from the cache for a subset of the existing user base only. For all uid's the query is cached (according to the log), but for some no data is returned.
Sounds more like a schema config issue then. Most likely you don't have the matching schema in the proxy server, so it is unable to store the entries it has received.