Re: (ITS#6647) Overlay sssvlv is always loaded

[masarati@aero.polimi.it]

> On 14/09/2010 11:33, clem.oudot@gmail.com wrote:
>> Full_Name: Clement OUDOT
>> Version: 2.4.23
>> OS: GNU/Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (83.145.72.122)
>>
>>
>> Hi,
>>
>> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from
>> http://www.ltb-project.org). Overlays are not compiled as modules.
>>
>> Overlay sssvlv is compiled, but not activated in configuration
>>
>> But:
>> * SSS and VLV controls are displayed in RootDSE
>> * SSS control is taken into account if present in an LDAP search
>> operation
>>
>> For example, a search with SSS control on cn (which has no ordering
>> rule)
>> gives:
>> result: 18 Inappropriate matching
>> text: serverSort control: No ordering rule
>>
>>
>> The error would be normal if overlay has been activated, but I think
>> control
>> should be ignored if overlay is not active.
>
> I hit this exact same issue just last week - it seems that when the
> overlay is compiled in, the SSS control is displayed in the rootDSE.
>
> In my case, this caused a client to attempt to use the control, then
> fail with a similar message as above. Without the overlay compiled in,
> the client just doesn't use the control, and the client's operation
> suceeded.
>
> My point is that I agree this probably shouldn't be activated by
> default, or at the very least a clear warning added in the documentation.

This behavior is common to all overlays that register a general feature,
like controls, extended ops or even just a bit of custom schema: the
registration is done when the module is loaded (or at startup, if the
module is statically built into slapd).  As a consequence, the feature is
advertised because slapd knows about it, but since it is not explicitly
configured, does not know how to handle it.

In the end, slapd's behavior is correct: it recognizes the feature, it
recognizes requests for the feature, but does not know how to handle them,
thus returns an appropriate error.  This looks pretty consistent with
RFC4511 and specifications of each feature, although I understand it could
be disappointing.

Perhaps we could modify this behavior so that the module initialization
does nothing or so, and only the first instantiation of the feature causes
the real initialization.  This was discussed in the past, and I recall it
created trouble when part of the initialization was needed earlier (e.g.
registering schema items that need to be used later in the configuration
or so; a clear case was back-monitor, which registers schema items that
are needed by other backends when registering custom monitoring; if
back-monitor startup didn't occur early enough, one had to instantiate it
before any database that wanted to register custom monitoring).

In conclusion: the current behavior is consistent; on a case by case
basis, feature instantiation could perhaps be deferred as much as
possible, unless this conflicts with other features.

p.