2.4.18 releases slapo-sssvlv. Now my servers are advertising
VLV/sortKeyList as supportedControls. Thing is, I don't specify "overlay
sssvlv" so they're not really "supported" in any meaningful way.
that specify the controls just error out fast. I'm not particularly
inclined to enable the feature, but I'm not sure if somebody else might
want it in their installation, so I'd prefer to keep it compiled in.
This is the case with all overlays across the board. For example,
configure --enable-modules --enable-overlays=mod and syncprov isn't
advertised in test000. But if you just ./configure and run test000, you
see 22.214.171.124.4.1.4126.96.36.199.1 despite the fact that there's no way test000
could provide LDAP Sync as configured. (Recall that --enable-syncprov
defaults to yes.)
To me it's counterintuitive and "false advertising": unless there's an
"overlay syncprov" in slapd.1.conf, I don't see why that should show up in
This is not in violation of LDAP specs. Note that advertising a
feature/control/etc. does not imply that the corresponding feature is
always supported for whatever operation. For example, as you say, VLV
would be supported by the database that instantiates that overlay but not
by others. Or PagedResults would be supported by back-bdb/hdb but not by
other backends, and so on. The advertisement via rootDSE mechanism is
inherently flawed, and should be taken as it is: a mention of the fact
that the feature in general could be supported, or at least recognized.
In fact, OpenLDAP's slapd used to advertise this feature way before it was
actually implemented, and it would simply refuse to use it, after
acknowledging that the feature was recognized. This is perfectly inline
with LDAP specs.