[Date Prev][Date Next]
Re: (ITS#6647) Overlay sssvlv is always loaded
> 2010/9/14 <firstname.lastname@example.org>:
>>> On 14/09/2010 11:33, email@example.com wrote:
>>>> Full_Name: Clement OUDOT
>>>> Version: 2.4.23
>>>> OS: GNU/Linux
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (220.127.116.11)
>>>> 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
>>>> * SSS and VLV controls are displayed in RootDSE
>>>> * SSS control is taken into account if present in an LDAP search
>>>> For example, a search with SSS control on cn (which has no ordering
>>>> result: 18 Inappropriate matching
>>>> text: serverSort control: No ordering rule
>>>> The error would be normal if overlay has been activated, but I think
>>>> 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
>>> 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
>> 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). =A0As a consequence, the feature
>> 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
>> thus returns an appropriate error. =A0This looks pretty consistent with
>> RFC4511 and specifications of each feature, although I understand it
>> 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
>> the real initialization. =A0This was discussed in the past, and I recall
>> 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
>> 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.
> I understand your point of view. Indeed, recompiling OpenLDAP without
> sssvlv overlay works.
> The fact is that for people compiling OpenLDAP with --enable-overlays,
> we have a 'regression' with overlay sssvlv, because LDAP clients are
> now using the control and get errors.
> Maybe the issue can be retargeted to sssvlv overlay: if an LDAP client
> is using the SSS control in a non-critical mode, OpenLDAP should
> return search results (unsorted) even if the control fails (because of
> missing ordering rule for requested attribute). If the control is
> critical, then the error must be returned.
Please try this (nearly blind) patch
and report through the ITS. Thanks, p.