[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Run-time registered controls

> At 03:17 AM 1/25/2005, Pierangelo Masarati wrote:
>>I'm working at dynamically registering the Chaining Behavior control by
>>the chain overlay, and I noticed that there seems to be no mechanism to
>>dynamically register controls in the bi_controls array.
>
> See ppolicy.c.

OK, I missed that.  But it essentially works as syncprov, i.e. it calls
register_supported_control(), which, among other things, adds the control
OID to the list of known controls in slapd.  That's why controls
registered via this mechanism are happily parsed by the frontend. 
However, this call does nothing to add the OID to the list of the controls
supported by a backend.  Since one of the aims of an overlay that
implements a control is to be backend independent, it should be able to
add the OID of the control(s) it implements to the list of the controls
supported by the backend.  If the OID is not in the list, although
successfully parsed it is rejected by the frontend when
backend_check_controls() is called; but this occurs only if the
criticality flag is set.

>
>>This is necessary
>>to pass the backend_check_controls() then the criticality flag is set
>>(also, I note that test should be reworked as per ITS#3308; I'll also
>> look
>>at that).

> ITS#3308 reports that slapd(8) improperly returns
> unavailableCriticalExtension for a recognized and
> appropriate control.  This code should only be
> returned for controls which are unrecognized or
> inappropriate for the operation they are attached
> to.  I committed a fix for ITS#3308 (backend.c 1.298).

Sounds good, thanks.  One thing I note is that you removed the test on the
criticality of the control, as the comment that was there was suggesting. 
Unless I was erroneously reading the code, now syncprov should stop
working...

[masarati@mbdyn tests]$ ./run test019
Cleaning up test run directory leftover from previous run.
Running ./scripts/test019-syncreplication-cascade...
running defines.sh
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd (pid=6550) is running...
Waiting 5 seconds for slapd to start...
Using ldapadd to create the context prefix entry in the master...
Starting R1 slave slapd on TCP/IP port 9012...
Using ldapsearch to check that R1 slave slapd (pid=6560) is running...
Waiting 5 seconds for R1 slapd to start...
Starting R2 slave slapd on TCP/IP port 9013...
Using ldapsearch to check that R2 slave slapd (pid=6568) is running...
Waiting 5 seconds for R2 slave slapd to start...
Starting P1 slave slapd on TCP/IP port 9014...
Using ldapsearch to check that P1 slave slapd (pid=6576) is running...
Waiting 5 seconds for P1 slave slapd to start...
Starting P2 slave slapd on TCP/IP port 9015...
Using ldapsearch to check that P2 slave slapd (pid=6584) is running...
Waiting 5 seconds for P2 slave slapd to start...
Starting P3 slave slapd on TCP/IP port 9016...
Using ldapsearch to check that P3 slave slapd (pid=6592) is running...
Waiting 5 seconds for P3 slave slapd to start...
Using ldapadd to populate the master directory...
Waiting 25 seconds for syncrepl to receive changes...
Using ldapmodify to modify master directory...
Waiting 25 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from the master...
Using ldapsearch to read all the entries from the R1 slave...
ldapsearch failed at R1 slave (32)!

[masarati@mbdyn tests]$ grep 'control' testrun/slapd.1.log
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=2 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=3 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=4 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=5 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=6 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=8 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=9 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=10 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=12 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context
send_ldap_result: err=53 matched="" text="control unavailable in context"
conn=13 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=control
unavailable in context


>
>>To keep things simple,
>>Of course, I might be missing a much cleaner and simpler solution, or
>>overlooking other side effects...
>
> I guess I don't see what functionality we're missing.

See above.  We didn't notice this earlier because the run-time registered
controls either required the control to be non critical (ppolicy) or
required/allowed it to be non-critical (syncrepl).

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497