Re: ITS#3781 back-config doesn't work with xxx

[h.b.furuseth@usit.uio.no]

hyc@symas.com writes:
>ando@sys-net.it wrote:
>>> Is there a description somewhere of what it means to support
>>> back-config?  For example, how would back-perl do it?  The admin can
>>> write a Perl config() function which defines new slapd.conf directives;
>>> only a few directives are hardcoded.
>>
>> I suggest that backends like back-perl just define a "perl-" directive
>> that allows arbitrary length and args which are passed to the
>> user-provided config routine.  I see it a bit harder to implement "emit"
>> in a consistent way, though.
>
> That implies that you'll only have a single attributeType for back-perl
> config directives.  I guess it would work, but it pretty much means
> implementing a table-driven config engine in perl, to manage things from
> there (assuming you want to support LDAP_MOD_DELETE and have full
> runtime reconfigurability).

Well, assume one doesn't want to support that for now then:-)

> Or maybe a set of perl hooks for constructing schema tables that can
> be passed to config_register_schema(), so that the perl module can
> properly define its config items. I think either way this is a fair
> chunk of perl XS code.

Seems a pity to put this in XS, other programmable backends could
have use for it.

Maybe I just don't know back-config well enough yet, but I don't
get the problem with the single directive approach.  Keeping
general programmable backends in mind, I imagine something like -

* Make a general olcStatement attribute.  OCTET STRING, X-ORDERED.

* Pass slapd.conf statements or olcStatement values to the current
  bi->bi_db_config() as usual.  If that succeeds from slapd.conf,
  save the raw statement as a new olcStatement value.

* Do not accept run-time configuration operations by default,
  since that might confuse existing Perl programs.

Here is where I imagine I may be departing from how back-config
thinks, but anyway -

If/when someone feels like implementing run-time configuration:

* Allow a new perl routine "dyn_config" which takes a modification
  request to config parameters as an argument and returns success
  or failure.

  To perform a config modification request, block future config
  modifications, check that the change would be valid as far as
  back-ldif is concerned (by simulating the change with the noop
  control?), call dyn_config(), perform the back-ldif
  modification, and cancel the blocking.

* Create a Perl routine "read_config" which the Perl program can
  call, which returns the current config statements - or the
  statements matching an optional parameter to read_config.

* There could be a "config-option" statement to describe config
  options the database will accept.  In that case, generate
  database-specific - not backend-specific - config attributes,
  with OIDs generated from the option name and some reserved
  prefix.  That would provide some syntax checking but otherwise
  be treated just like olcStatement.
  If a database has no config-option statements, or if there is
  a 'config-option *' statement, fall back on olcStatement.

-- 
Hallvard