On Fri, Jan 15, 2010 at 1:30 PM, Diego Lima <li...@diegolima.org> wrote:
> Hi,
>
> 2010/1/15 Quanah Gibson-Mount <qua...@zimbra.com>
>>
>> --On Friday, January 15, 2010 12:06 PM -0500 Edward Capriolo
>> <edlinuxg...@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
