Hi there,
I'm trying to proxy and cache some ldap queries which would otherwise go to an IBM Tivoli Directory Server or another kind of ldap-server. Therefore I'm trying to use the pcache (proxycache) overlay in openldap 2.3.39.
Is there a problem with that setup so far? Would it need special adjustments to proxy another kind of ldap server than just openldap?
I'm having the problem, that I only get back on ldapsearch against the proxy --- # search result search: 2 result: 32 No such object ---
which seems to get as far as getting the user authenticated as I get another error if I enter wrong credentials ;). Needless to say that everything is returned correctly if I just change the hostname to the direct ldap server.
My config is as follows with is directly derived from the configuration:
--- # proxycache settings database ldap suffix "o=domainname" rootdn "cn=Manager,o=domainname" uri ldap://hostname/o=domainname overlay pcache proxycache bdb 100000 1 1000 100 proxyAttrset 0 mail postaladdress telephonenumber proxyTemplate (sn=) 0 3600 proxyTemplate (uid=) 0 3600 proxyTemplate (&(sn=)(givenName=)) 0 3600 proxyTemplate (&(departmentNumber=)(secretary=*)) 0 3600
cachesize 20 directory /usr/local/openldap-proxycache/var/openldap-data/db.2.a index objectClass eq index cn,sn,uid,mail pres,eq,sub ---
Any ideas about this issue? Any way to further diagnose the problem? I assume that every non-cacheable query is sent to the proxied ldap server anyway and its results are returned directly?
Thanks in advance,
Thomas
Hello,
Thomas Seifert thomas-lists@mysnip.de writes:
Hi there,
I'm trying to proxy and cache some ldap queries which would otherwise go to an IBM Tivoli Directory Server or another kind of ldap-server. Therefore I'm trying to use the pcache (proxycache) overlay in openldap 2.3.39.
Is there a problem with that setup so far? Would it need special adjustments to proxy another kind of ldap server than just openldap?
Depending on schemas you might have to rewrite attribute types.
I'm having the problem, that I only get back on ldapsearch against the proxy
# search result search: 2 result: 32 No such object
[...]
Any ideas about this issue? Any way to further diagnose the problem? I assume that every non-cacheable query is sent to the proxied ldap server anyway and its results are returned directly?
yes that is correct, but still you should run slapd -d pcache to get more infortion.
-Dieter
Hi Dieter,
thanks for your reply.
Dieter Kluenter schrieb:
Depending on schemas you might have to rewrite attribute types.
ouch, what a fun :(.
I'm having the problem, that I only get back on ldapsearch against the proxy
# search result search: 2 result: 32 No such object
[...]
Any ideas about this issue? Any way to further diagnose the problem? I assume that every non-cacheable query is sent to the proxied ldap server anyway and its results are returned directly?
yes that is correct, but still you should run slapd -d pcache to get more infortion.
Hmm, what kind log-level is this? I only found numeric ones. Trying the command given is only telling "unrecognized log level "pcache"" either.
Thanks,
thomas
Thomas Seifert thomas-lists@mysnip.de writes:
Hi Dieter,
thanks for your reply.
Dieter Kluenter schrieb:
Depending on schemas you might have to rewrite attribute types.ouch, what a fun :(.
It is not that complicated, see man slapo-rwm(5)
Any ideas about this issue? Any way to further diagnose the problem? I assume that every non-cacheable query is sent to the proxied ldap server anyway and its results are returned directly? yes that is correct, but still you should run slapd -d pcache to get more infortion.Hmm, what kind log-level is this? I only found numeric ones. Trying the command given is only telling "unrecognized log level "pcache"" either.
This loglevel is defined in pcache.c, it is not known to slapd at start, thats why the error.
-Dieter
Thomas Seifert wrote:
Hi there,
I'm trying to proxy and cache some ldap queries which would otherwise go to an IBM Tivoli Directory Server or another kind of ldap-server. Therefore I'm trying to use the pcache (proxycache) overlay in openldap 2.3.39.
Is there a problem with that setup so far?
No.
Would it need special adjustments to proxy another kind of ldap server than just openldap?
Maybe, depends on how willing to cooperate the proxied server is.
I'm having the problem, that I only get back on ldapsearch against the proxy
# search result search: 2 result: 32 No such object
which seems to get as far as getting the user authenticated as I get another error if I enter wrong credentials ;). Needless to say that everything is returned correctly if I just change the hostname to the direct ldap server.
The above error seems to indicate that the proxy is unable to determine what database can handle the requested search base. But you don't provide enough information to help tracking your issue. A log of the request by the proxy at "stats" level would have provided the required information.
My config is as follows with is directly derived from the configuration:
# proxycache settings database ldap suffix "o=domainname" rootdn "cn=Manager,o=domainname" uri ldap://hostname/o=domainname
^^^^ this is incorrect. As the man page clearly states, no "DN" portion must be provided in the URI (you should have gotten a warning about it, but who cares about warnings, eh? Next version it'll error out).
overlay pcache proxycache bdb 100000 1 1000 100 proxyAttrset 0 mail postaladdress telephonenumber proxyTemplate (sn=) 0 3600 proxyTemplate (uid=) 0 3600 proxyTemplate (&(sn=)(givenName=)) 0 3600 proxyTemplate (&(departmentNumber=)(secretary=*)) 0 3600
cachesize 20 directory /usr/local/openldap-proxycache/var/openldap-data/db.2.a index objectClass eq index cn,sn,uid,mail pres,eq,sub
Any ideas about this issue? Any way to further diagnose the problem?
See above.
I assume that every non-cacheable query is sent to the proxied ldap server anyway and its results are returned directly?
Correct.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Thanks Pierangelo, you gave the needed hint!
Pierangelo Masarati schrieb:
The above error seems to indicate that the proxy is unable to determine what database can handle the requested search base. But you don't provide enough information to help tracking your issue. A log of the request by the proxy at "stats" level would have provided the required information.
Thats it. The ibmslapd seems to assume a default search base while I had to enter one for openldap in ldap.conf or on the command-line. Now I'm getting the expected results back!
^^^^ this is incorrect. As the man page clearly states, no "DN" portion must be provided in the URI (you should have gotten a warning about it, but who cares about warnings, eh? Next version it'll error out).
Well, yeah. That didn't help directly either, but see above, it works now. Could someone please fix the html-docs too if the manpages are the reference? http://www.openldap.org/doc/admin23/proxycache.html It shows at least the wrong uri-syntax and the wrong name for the overlay.
Regards,
thomas
Thomas Seifert wrote:
Thats it. The ibmslapd seems to assume a default search base while I had to enter one for openldap in ldap.conf or on the command-line. Now I'm getting the expected results back!
:)
^^^^ this is incorrect. As the man page clearly states, no "DN" portion must be provided in the URI (you should have gotten a warning about it, but who cares about warnings, eh? Next version it'll error out).
Well, yeah. That didn't help directly either, but see above, it works now. Could someone please fix the html-docs too if the manpages are the reference? http://www.openldap.org/doc/admin23/proxycache.html It shows at least the wrong uri-syntax and the wrong name for the overlay.
Good catch! Apparently that doc was crafted from an example using back-meta as the proxy; in fact, back-meta needs the DN portion. Please file an ITS for this http://www.openldap.org/.
Thanks, p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org
-
Dieter Kluenter -
Pierangelo Masarati -
Thomas Seifert