Hi, I'm experimenting a strange behaviour using back-meta + slapo-pcache + glue, I have a configuration similar to this:
database meta subordinate advertise suffix "dc=ext,dc=blabla,dc=com" rootdn "cn=Manager,dc=blabla,dc=com" overlay pcache proxycache bdb 10000 3 100 100 ... uri "ldap://10.0.0.1/dc=dir1,dc=ext,dc=blabla,dc=com" suffixmassage "dc=dir1,dc=ext,dc=blabla,dc=com" "dc=w2k3,dc=blabla,dc=local" pseudorootdn "cn=Administrator,cn=Users,dc=w2k3,dc=blabla,DC=local" pseudorootpw blabla
database bdb suffix "dc=blabla,dc=com" rootdn "cn=Manager,dc=blabla,dc=com" rootpw blabla
If I do a search under "dc=dir1,dc=blabla,dc=com" and this search is not in cache, everything works ok, but if the search is obtained from cache, I obtain two different answers to the same 'search' request from slapd, one of them with result code '0' (success) and another one with code 53 (unwilling to perform), although I also obtain the correct result entries. Digging a bit with gdb, I see that the 'unwilling to perform' error is sended in backglue.c (glue_op_search function). Am I maybe doing something wrong on the configuration or is that a normal behaviour?
Thank you,
Dani.
I fear intermixing slapo-glue and back-meta that way could cause some trouble. Is it really indispensable? Anyway, I'll have a look at it, since it might unveil some other issue, and I?m right now very interested in back-meta :).
Hi, I'm experimenting a strange behaviour using back-meta + slapo-pcache + glue, I have a configuration similar to this:
database meta subordinate advertise suffix "dc=ext,dc=blabla,dc=com" rootdn "cn=Manager,dc=blabla,dc=com" overlay pcache proxycache bdb 10000 3 100 100 ... uri "ldap://10.0.0.1/dc=dir1,dc=ext,dc=blabla,dc=com" suffixmassage "dc=dir1,dc=ext,dc=blabla,dc=com" "dc=w2k3,dc=blabla,dc=local" pseudorootdn "cn=Administrator,cn=Users,dc=w2k3,dc=blabla,DC=local" pseudorootpw blabla
database bdb suffix "dc=blabla,dc=com" rootdn "cn=Manager,dc=blabla,dc=com" rootpw blabla
If I do a search under "dc=dir1,dc=blabla,dc=com" and this search is not in cache, everything works ok, but if the search is obtained from cache, I obtain two different answers to the same 'search' request from slapd, one of them with result code '0' (success) and another one with code 53 (unwilling to perform), although I also obtain the correct result entries. Digging a bit with gdb, I see that the 'unwilling to perform' error is sended in backglue.c (glue_op_search function). Am I maybe doing something wrong on the configuration or is that a normal behaviour?
Thank you,
Dani.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. 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 ------------------------------------------
In my scenario I need to do top-level searches to local database and external directories via back-meta, under the same naming context, so I supposed that subordinating back-meta would be a possible solution.
In fact, the behaviour I comment is not very critical, because although slapd returns two answers for the search request, the client (using libldap) seems to take the 'succesful' one, and the result entries are also obtained ok.
I've also tried the same configuration glueing some back-ldap's instead back-meta, and I also obtain the same behaviour.
Regards,
Dani.
2006/10/26, Pierangelo Masarati ando@sys-net.it:
I fear intermixing slapo-glue and back-meta that way could cause some trouble. Is it really indispensable? Anyway, I'll have a look at it, since it might unveil some other issue, and I?m right now very interested in back-meta :).
Hi, I'm experimenting a strange behaviour using back-meta + slapo-pcache + glue, I have a configuration similar to this:
database meta subordinate advertise suffix "dc=ext,dc=blabla,dc=com" rootdn "cn=Manager,dc=blabla,dc=com" overlay pcache proxycache bdb 10000 3 100 100 ... uri "ldap://10.0.0.1/dc=dir1,dc=ext,dc=blabla,dc=com" suffixmassage "dc=dir1,dc=ext,dc=blabla,dc=com" "dc=w2k3,dc=blabla,dc=local" pseudorootdn "cn=Administrator,cn=Users,dc=w2k3,dc=blabla,DC=local" pseudorootpw blabla
database bdb suffix "dc=blabla,dc=com" rootdn "cn=Manager,dc=blabla,dc=com" rootpw blabla
If I do a search under "dc=dir1,dc=blabla,dc=com" and this search is not in cache, everything works ok, but if the search is obtained from cache, I obtain two different answers to the same 'search' request from slapd, one of them with result code '0' (success) and another one with code 53 (unwilling to perform), although I also obtain the correct result entries. Digging a bit with gdb, I see that the 'unwilling to perform' error is sended in backglue.c (glue_op_search function). Am I maybe doing something wrong on the configuration or is that a normal behaviour?
Thank you,
Dani.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. 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
Daniel Montero Motilla wrote:
Hi, I'm experimenting a strange behaviour using back-meta + slapo-pcache + glue, I have a configuration similar to this:
database meta subordinate advertise suffix "dc=ext,dc=blabla,dc=com" rootdn "cn=Manager,dc=blabla,dc=com" overlay pcache proxycache bdb 10000 3 100 100 ... uri "ldap://10.0.0.1/dc=dir1,dc=ext,dc=blabla,dc=com" suffixmassage "dc=dir1,dc=ext,dc=blabla,dc=com" "dc=w2k3,dc=blabla,dc=local" pseudorootdn "cn=Administrator,cn=Users,dc=w2k3,dc=blabla,DC=local" pseudorootpw blabla
database bdb suffix "dc=blabla,dc=com" rootdn "cn=Manager,dc=blabla,dc=com" rootpw blabla
If I do a search under "dc=dir1,dc=blabla,dc=com" and this search is not in cache, everything works ok, but if the search is obtained from cache, I obtain two different answers to the same 'search' request from slapd, one of them with result code '0' (success) and another one with code 53 (unwilling to perform), although I also obtain the correct result entries. Digging a bit with gdb, I see that the 'unwilling to perform' error is sended in backglue.c (glue_op_search function). Am I maybe doing something wrong on the configuration or is that a normal behaviour?
Looks like the pcache overlay and backglue are both sending results back to the client. This is probably a bug in the pcache overlay.
openldap-software@openldap.org
-
Daniel Montero Motilla -
Howard Chu -
Pierangelo Masarati