Hi, I'm obtaining a strange (almost for me) behaviour with pcache overlay (openldap 2.3.27), I have a configuration similar to this one:
proxyattrset 0 uid cn sn mail description proxyattrset 1 cn description proxytemplate (&(objectClass=)(uid=)) 0 3600 proxytemplate (&(objectClass=)(cn=)) 1 3600
With this configuration, I perform this search:
(&(objectClass=groupOfNames)(cn=mygroup)) cn description
but I obtain "NOT ANSWERABLE" and "NOT CACHEABLE".
Digging on pcache.c, I see that the problem is that 'get_attr_set' function doesn't look for a proxyattrset that _exactly_ matches with my search attribute set, it instead looks for a proxyattrset that is a _superset_ of the search attribute set.
On my example, my search attribute set (cn, description) is a subset of proxyattrset '0', so 'get_attr_set' returns '0'. Then, the application looks for a proxytemplate whose proxyattrset equals the one obtained with 'get_attr_set' (0), so it obtains the template '(&(objectClass=)(uid=))' and compares it with my search template '(&(objectClass=)(cn=))', so I get 'NOT CACHEABLE'.
As a workaround I have inverted the proxyattrset index numbers so 'get_attr_set' finds first the most specific proxyattrset, but i'm curious about if this behaviour is the intended one or if I should fill an ITS with a patch (the change in code would be minimal), what do you think?
Thanks,
Dani
Daniel Montero Motilla wrote:
Hi, I'm obtaining a strange (almost for me) behaviour with pcache overlay (openldap 2.3.27), I have a configuration similar to this one:
proxyattrset 0 uid cn sn mail description proxyattrset 1 cn description proxytemplate (&(objectClass=)(uid=)) 0 3600 proxytemplate (&(objectClass=)(cn=)) 1 3600
With this configuration, I perform this search:
(&(objectClass=groupOfNames)(cn=mygroup)) cn description
but I obtain "NOT ANSWERABLE" and "NOT CACHEABLE".
Digging on pcache.c, I see that the problem is that 'get_attr_set' function doesn't look for a proxyattrset that _exactly_ matches with my search attribute set, it instead looks for a proxyattrset that is a _superset_ of the search attribute set.
Yes, that's a recent change. I guess we call it an undocumented feature, please file an ITS against the documentation.
On my example, my search attribute set (cn, description) is a subset of proxyattrset '0', so 'get_attr_set' returns '0'. Then, the application looks for a proxytemplate whose proxyattrset equals the one obtained with 'get_attr_set' (0), so it obtains the template '(&(objectClass=)(uid=))' and compares it with my search template '(&(objectClass=)(cn=))', so I get 'NOT CACHEABLE'.
As a workaround I have inverted the proxyattrset index numbers so 'get_attr_set' finds first the most specific proxyattrset, but i'm curious about if this behaviour is the intended one or if I should fill an ITS with a patch (the change in code would be minimal), what do you think?
No, just delete the other proxyattrset directive, you don't need it at all.
openldap-software@openldap.org