> 2010/9/14 <[email protected]>: >>> On 14/09/2010 11:33, [email protected] 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). =A0As 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. =A0This looks pretty consistent with >> RFC4511 and specifications of each feature, although I understand it >> coul= > d >> 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 >> cause= > s >> the real initialization. =A0This 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. >> > > 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 <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.patch> and report through the ITS. Thanks, p.
