Full_Name: Guillaume Rousse Version: 2.4.11 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.224.237.5) Here is a simple relay configuration: 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" However, queries with critical pagedResult control fails: 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 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=""
I have a fix for this issue when the relay database is configured *after* the relayed one. I'll commit it in a moment. However, this fix does not cure your case, where the virtual database needs to appear *before* the real one, and also does not cure similar issues related, for example, to run-time configuring modules that register controls on a real database (e.g. an overlay), which would not be echoed by the virtual database. 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 -----------------------------------
changed notes moved from Incoming to Software Bugs
ando@OpenLDAP.org wrote: > Log Message: > open database using the real structure (partial fix to ITS#5724) We need a virtual database to inherit controls from the real database. Sharing the array of known controls could be a solution, but it wouldn't allow the virtual database to have specific controls, e.g. registered by an overlay. A solution would be to let the real database know it's related to virtual ones, so that modifications to the real database via back-config can be propagated to the virtual ones. This, of course, poses the problem that if a virtual database is deleted, any reference to it must be removed from the list of related databases. I wonder if all of this is worth the effort of exposing real controls by the virtual database. 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 -----------------------------------
ando@sys-net.it wrote: > ando@OpenLDAP.org wrote: > >> Log Message: >> open database using the real structure (partial fix to ITS#5724) > > We need a virtual database to inherit controls from the real database. > Sharing the array of known controls could be a solution, but it wouldn't > allow the virtual database to have specific controls, e.g. registered by > an overlay. A solution would be to let the real database know it's > related to virtual ones, so that modifications to the real database via > back-config can be propagated to the virtual ones. This, of course, > poses the problem that if a virtual database is deleted, any reference > to it must be removed from the list of related databases. I wonder if > all of this is worth the effort of exposing real controls by the virtual > database. Since a single relay database may be configured to multiplex to many other databases, and they may not all support the same set of controls, this seems to be an exercise in futility. I guess it may be OK to just advertise a union of all the real database controls, and perform an extra restriction check before handing off processing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote: > ando@sys-net.it wrote: >> ando@OpenLDAP.org wrote: >> >>> Log Message: >>> open database using the real structure (partial fix to ITS#5724) >> >> We need a virtual database to inherit controls from the real database. >> Sharing the array of known controls could be a solution, but it wouldn't >> allow the virtual database to have specific controls, e.g. registered by >> an overlay. A solution would be to let the real database know it's >> related to virtual ones, so that modifications to the real database via >> back-config can be propagated to the virtual ones. This, of course, >> poses the problem that if a virtual database is deleted, any reference >> to it must be removed from the list of related databases. I wonder if >> all of this is worth the effort of exposing real controls by the virtual >> database. > > Since a single relay database may be configured to multiplex to many > other databases, and they may not all support the same set of controls, > this seems to be an exercise in futility. I guess it may be OK to just > advertise a union of all the real database controls, and perform an > extra restriction check before handing off processing. Sharing the pointer to the supported controls would allow to use the actual set. Something along the line struct BackendDB { char be_ctrlsbuf[SLAP_MAX_CIDS + 1]; char *be_ctrls; }; All backends would have be_ctrls = be_ctrlsbuf, but back-relay would set it to NULL, and temporarily set it to the relayed database's be_ctrlsbuf for the duration of an operation. Modules wouldn't be able to register new controls because the pointer is null otherwise. 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 -----------------------------------
ando@sys-net.it wrote: > Sharing the pointer to the supported controls would allow to use the > actual set. Something along the line > > struct BackendDB { > char be_ctrlsbuf[SLAP_MAX_CIDS + 1]; > char *be_ctrls; > }; > > All backends would have be_ctrls = be_ctrlsbuf, but back-relay would set > it to NULL, and temporarily set it to the relayed database's be_ctrlsbuf > for the duration of an operation. Modules wouldn't be able to register > new controls because the pointer is null otherwise. Of course, this wouldn't work since it implies modifying the BackendDB structure, which is read-only :( 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 -----------------------------------
changed notes
moved from Software Bugs to Development
ando@sys-net.it wrote: > ando@sys-net.it wrote: > >> Sharing the pointer to the supported controls would allow to use the >> actual set. Something along the line >> >> struct BackendDB { >> char be_ctrlsbuf[SLAP_MAX_CIDS + 1]; >> char *be_ctrls; >> }; >> >> All backends would have be_ctrls = be_ctrlsbuf, but back-relay would set >> it to NULL, and temporarily set it to the relayed database's be_ctrlsbuf >> for the duration of an operation. Modules wouldn't be able to register >> new controls because the pointer is null otherwise. > > Of course, this wouldn't work since it implies modifying the BackendDB > structure, which is read-only :( backover.c 1.91 appears to partially revert rev 1.84, thus breaking ITS#5346 again. Investigating now... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Partial
partially fixed in HEAD partially fixed in RE24