Hello list.
I managed to get a correct relay backend configured, so as to remap attributes, thanks to previous help from people here. It works OK through ldapsearch. However, I still can't use it with the target cisco appliance, as pagedResult control doesn't work: Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SRCH base="ou=telephony,dc=msr-inria,dc=inria,dc=fr" scope=2 deref=3 filter="(objectClass=inetOrgPerson)" Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SRCH attr=uid givenname initials sn manager departmentnumber telephonenumber mail title homephone mobile pager Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SEARCH RESULT tag=101 err=12 nentries=0 text=critical control unavailable in context
When debug level is set to 1, I get this: Oct 2 14:16:15 etoile slapd[6002]: => get_ctrls Oct 2 14:16:15 etoile slapd[6002]: => get_ctrls: oid="1.2.840.113556.1.4.319" (critical) Oct 2 14:16:15 etoile slapd[6002]: <= get_ctrls: n=1 rc=0 err=""
Reading ITS 5191, I understand it is supposed to have been fixed in 2.4 release. However, I'm using 2.4.11, and I'm still getting the problem. Should I reopen the ticket ?
Here's my configuration, if that matters. Trying to make the relay database subordinate to the other one doesn't change the problem.
database relay suffix ou=telephony,dc=msr-inria,dc=inria,dc=fr overlay rwm rwm-suffixmassage ou=users,dc=msr-inria,dc=inria,dc=fr
rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber
database bdb suffix "dc=msr-inria,dc=inria,dc=fr" rootdn "cn=root,dc=msr-inria,dc=inria,dc=fr"
--On Thursday, October 02, 2008 2:43 PM +0200 Guillaume Rousse Guillaume.Rousse@inria.fr wrote:
Hello list.
I managed to get a correct relay backend configured, so as to remap attributes, thanks to previous help from people here. It works OK through ldapsearch. However, I still can't use it with the target cisco appliance, as pagedResult control doesn't work:
Reading ITS 5191, I understand it is supposed to have been fixed in 2.4 release. However, I'm using 2.4.11, and I'm still getting the problem. Should I reopen the ticket ?
I'm not sure ITS#5191 applies to back-relay.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
The issue you see is related to control criticality: if the control is marked as non-critical in the request, it works as intended. In fact, back-relay can only expose the underlying database's controls support, but this currently fails because of the way supported controls are exposed. Please file an ITS.
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 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati a écrit :
The issue you see is related to control criticality: if the control is marked as non-critical in the request, it works as intended. In fact, back-relay can only expose the underlying database's controls support, but this currently fails because of the way supported controls are exposed. Please file an ITS.
Done, that's ITS #5724
openldap-software@openldap.org