Re: Server-Side Sort Overlay ordering problems

[Edward Capriolo <edlinuxguru@gmail.com>]

On Fri, Jan 15, 2010 at 1:30 PM, Diego Lima <lists@diegolima.org> wrote:
> Hi,
>
> 2010/1/15 Quanah Gibson-Mount <quanah@zimbra.com>
>>
>> --On Friday, January 15, 2010 12:06 PM -0500 Edward Capriolo
>> <edlinuxguru@gmail.com> wrote:
>>
>>> Diego,
>>>
>>> You and I have the same issue. UID and CN are not in the schema they
>>> are compiled into LDAP some how, so there is no way to apply an
>>> ordering rule. I can not find if this is possible, or what is involved
>>> in making it happen.
>
> I'm currently testing a quick and dirty hack that I made to
> servers/slapd/schema_prep.c:
> --- schema_prep.c.ori 2010-01-15 13:28:04.000000000 -0200
> +++ /root/openldap-2.4.21/servers/slapd/schema_prep.c 2010-01-15
> 13:04:56.000000000 -0200
> @@ -915,6 +915,7 @@ static struct slap_schema_ad_map {
>   offsetof(struct slap_internal_schema, si_ad_name) },
>   { "cn", "( 2.5.4.3 NAME ( 'cn' 'commonName' ) "
>   "DESC 'RFC4519: common name(s) for which the entity is known by' "
> + "ORDERING caseIgnoreOrderingMatch "
>   "SUP name )",
>   NULL, 0,
>   NULL, NULL,
> @@ -924,6 +925,7 @@ static struct slap_schema_ad_map {
>   "DESC 'RFC4519: user identifier' "
>   "EQUALITY caseIgnoreMatch "
>   "SUBSTR caseIgnoreSubstringsMatch "
> + "ORDERING caseIgnoreOrderingMatch "
>   "SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )",
>   NULL, 0,
>   NULL, NULL,
>
> By making these changes I've been able to get around my current problem, but
> it might not be as stable as you expect.
>
>>
>> You can find these attributes defined in the code in servers/slapd.
>>
>> However, I will note, the definitions of these attributes are RFC defined.
>> They have no ORDERING rule on purpose.
>>
>> --Quanah
>
> Thanks for the input Quanah, but the problem is we have some legacy
> applications that used a really old LDAP server where this was allowed. I'm
> trying to migrate the server (that's a fedora directory from fedora 6) to a
> new openldap-based one. I must, however, maintain compatibility with the
> existing applications.
> Is there any problem (despite not being RFC-compliant) on enabling ordering
> on these attributes?
>
> --
> Diego Lima
>

So I have implemented this patch.

Now my client greats me with: Unavailable critical extension
I see this in the log


@400000004b5a1ea4146c62cc => get_ctrls: oid="1.2.840.113556.1.4.473"
(noncritical)
@400000004b5a1eb912121b34 => get_ctrls: oid="1.2.840.113556.1.4.473" (critical)

I find this as advice:

http://www.openldap.org/lists/openldap-software/200408/msg00321.html

access to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.319
   by * none


Yet this does not work:

@400000004b5a2339219ce584 /usr/local/openldap/etc/openldap/slapd.conf:
line 44: attr "supportedControl" does not have an EQUALITY matching
rule.

This address book thing is totally whipping my rear.

I am configured like so:

 addConfOpt  "--prefix=/usr/local/openldap"  #base of the installation
  addConfOpt  "--enable-debug=yes"
  addConfOpt  "--enable-ip6=no"
  addConfOpt  "--enable-crypt=yes"
  addConfOpt  "--enable-wrapper=yes"
  addConfOpt  "--enable-module=yes"
  addConfOpt  "--enable-bdb=yes"
  addConfOpt  "--enable-shell=yes"
  addConfOpt  "--enable-null=yes"
  addConfOpt  "--enable-overlays=yes"
  addConfOpt  "--enable-shared=yes"
  addConfOpt  "--with-threads=yes"
  addConfOpt  "--with-tls"
  addConfOpt  "--enable-sssvlv" # need this for server side sorting
outlook address book

Unless someone else can tell me they have this working I will give up.

Thanks,
Ed