Howard Chu wrote:
The proxytemplate directive has gotten a bit cumbersome, with optional negative TTL and sizelimit TTL added on. This would be the natural place to add the TTR config as well. Should there be independent TTR for negative and sizelimit too? (And it seems we should move from positional arguments to named arguments here...)
But that gets awkward fast too, just like the syncrepl config. I think in both cases, it would have been better to make them child-entries of the main config object. That would also simplify altering individual parameters of a particular config.
As a side point, I'd prefer more consistency in the config keyword names, we should have used "pcache" as the prefix for all the keywords...
pcache<database> ... pcacheattrset<index> ... pcachemaxqueries<queries> pcachevalidate<bool> pcachepersist<bool> pcacheset template=<string> attrset=<index> ttl=<secs> [negttl=<secs>] ... pcacheposition (head|tail)
I've made these changes, keeping the old keyword / attribute names as aliases for now. I didn't change pcacheTemplate to key-value format yet, but it looks like that's going to be the best way forward.
For Bind caching I want to specify some additional parameters, and they all need to be associated to a given pcacheTemplate: search base, scope, and TTR. Given that we already have 7 positional parameters for pcacheTemplate I'm not keen to make it 10 now.
Upon receiving a Bind request, pcache will first perform a search using the template's filter and attrset, with the configured base and scope. (Yes, we could just do a base-scope search on the Bind DN, but that would isolate it into its own cached query. By using the same base and scope as e.g. an NSS lookup uses, the results will go into a cached query that will also satisfy the anticipated NSS lookup.)
If the query was not already cached, or the cached query has exceeded its TTL, then this will cause a remote search to occur, and the results of that should get cached. (Unless some entry limit got exceeded, etc.) Otherwise, this should just retrieve the cached result.
If the cached result has a hashed userPassword and it is within the TTR age, then the Bind will be validated against the cached userPassword. If the hash is older than the TTR, or there is no hash, the Bind will be passed thru to the remote target and if it succeeds, it will be hashed and cached.
So, actually implementing the Bind caching is pretty straightforward. Cleaning up the config syntax, not so much...