I'm using slapd-meta to merge a proxied AD (proxy is OL running on 'hidden' port) with a external OL server (running on separate host).
The meta seems to work, using '(uid=kpxb140)' (which is my UNIX account name at work) gives me two results, one from the AD and one from the external OL server. This is verified, because the objects look different (and comparing them with the 'original' source verifies this as well).
But on top (tail) of that, I'm using pcache...
The afformentioned search gives:
QUERY NOT ANSWERABLE QUERY CACHEABLE
each time (i.e., it doesn't actually write to the cache). A modified search
'(&(objectClass=account)(uid=kpxb140))'
or
'(&(objectClass=person)(uid=kpxb140))'
gives only ONE hit (the first from the OL server, the second from AD). This time I get the correct behaviour - it is cached into BDB...
Is this expected behaviour or a bug? If the latter, ITS# and expected fix?
On Tue, 20 Sep 2011, turbo@bayour.com wrote:
The meta seems to work, using '(uid=kpxb140)' (which is my UNIX account name at work) gives me two results, one from the AD and one from the external OL server. This is verified, because the objects look different (and comparing them with the 'original' source verifies this as well).
But on top (tail) of that, I'm using pcache...
The afformentioned search gives:
QUERY NOT ANSWERABLE QUERY CACHEABLE
each time (i.e., it doesn't actually write to the cache). A modified search
'(&(objectClass=account)(uid=kpxb140))'
or
'(&(objectClass=person)(uid=kpxb140))'
gives only ONE hit (the first from the OL server, the second from AD). This time I get the correct behaviour - it is cached into BDB...
Is this expected behaviour or a bug? If the latter, ITS# and expected fix?
The answer depends on how you configured the proxycache. For example, if you set an entry limit of 1, then it'll never cache the query that returns multiple answers. I think there are other possibilities that would explain what you're seeing too.
Philip
openldap-technical@openldap.org