One problem, is that old versions did support this ordering on uid and cn. So upgrade caused something that was working to no longer function. Specifically this effect anyone using openldap as outlook 2003 address book.
Maybe there should be a configure switch here.
Edward
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