Hello, thank you for reading this post!
Is it possible to configure openldap to cache the search operation necessary to perform mapped bind rewrites? The slapo-pcache man page has given me hope but I'm stuck making it happen.
I'm able to map and rewrite a bind, cache binds, and cache search results. But I'm stuck trying to cache the search operation that openldap completes for looking up a mapped attribute. For example I can bind with a string like:
mail=pfoo@somedomain.com,ou=Students,dc=domain,dc=com
slapd.conf maps that through overlay rwm like:
rwm-rewriteMap ldap source2dn "ldap:///ou=Students,dc=TEST_HOST,dc=TEST_COM?dn?sub"
rwm-rewriteContext bindDN
rwm-rewriteRule "(.+,)?dc=TEST_HOST,dc=TEST_COM" "$1dc=TEST_HOST,dc=TEST_COM" ":"
to an actual DN of:
cn=Foo, Peter (pfoo),ou=Students,dc=domain,dc=com
and some pcache definitions will cache binds and certain searches - this works great.
In reviewing the openldap log and network packets to confirm caching, I noticed search requests to attr=1.1. So I tried to define a pcachetemplate for those requests like this:
pcacheAttrset 0 1.1
pcacheTemplate (mail=) 0 1800
When I search for attribute 1.1 and bind using a dn that doesn't need to be rewritten, I get search results and they are cached. However, when I search for 1.1 and bind using a dn that needs to be rewritten, the server complains of a segmentation fault.
conn=1000 fd=12 ACCEPT from IP=127.0.0.1:54533 (IP=0.0.0.0:389)
conn=1000 op=0 BIND dn="mail=pfoo@somedomain.com,ou=Students,dc=TEST_HOST,dc=TEST_COM" method=128
conn=1001 fd=14 ACCEPT from IP=127.0.0.1:54534 (IP=0.0.0.0:389)
conn=1001 op=0 SRCH base="ou=Students,dc=TEST_HOST,dc=TEST_COM" scope=2 deref=0 filter="(mail=pfoo@somedomain.com)"
conn=1001 op=0 SRCH attr=1.1
query template of incoming query = (mail=)
Entering QC, querystr = (mail=pfoo@somedomain.com)
Lock QC index = 0xa2d8798
Not answerable: Unlock QC index=0xa2d8798
QUERY NOT ANSWERABLE
QUERY CACHEABLE
Segmentation fault
Since you get a SIGSEGV I suggest you: 1) file an ITS http:/www.openldap.org/its 2) provide further information according to http://www.openldap.org/faq/data/cache/56.html 3) provide a simple configuration (slapd.conf, minimal ldif data for the database, and exact operation that produces the problem, possibly using command-line tools from OpenLDAP) that produces the issue.
p.