--On Tuesday, December 22, 2015 2:10 PM -0500 Michael mlstarling31@hotmail.com wrote:

I could really use some help here if anyone can sort my questions it would be greatly appreciated..I'll even through in a bundt cake and/or canned ham since it's the holidays and all.

Modifying core schema is rarely a good idea, and often frowned upon.

There are a number of reasons why doing sorting on the server side is an extremely bad idea. It's generally a much better idea to do the sorting in the client.

--Quanah

__________________________________________________

From: mlstarling31@hotmail.com To: openldap-technical@openldap.org Subject: Server Side Searching Overlay Date: Mon, 21 Dec 2015 19:27:01 -0500

So I have a request from developers to enable the sssvlv overlay. They would like the server to return sorted searches on

I enabled the overlay and then to test the functionality I added the following "ordering" rule to the core.schema.

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' ORDERING caseIgnoreOrderingMatch SUP name )

The following ldapsearch works as expected and returns the "sn" attribute in alphabetical order.

ldapsearch -x -ZZ -D cn=root,dc=testlott,dc=lott -w password objectclass=person -E sss=sn sn

Based on this information I have several questions.

1. Will I be violating any RFC by modifying the core.schema?
2. The developers want the same functionality with the "cn" attribute. Is

this supported or even possible? 3. They also request this functionality on a couple of attributes in a custom schema. Is adding an "ordering" rule as I did with the "sn" attribute the proper way to do this?

Thanks.

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

From: mlstarling31@hotmail.com To: quanah@zimbra.com; openldap-technical@openldap.org Subject: RE: Server Side Searching Overlay Date: Tue, 22 Dec 2015 14:18:04 -0500

Date: Tue, 22 Dec 2015 11:13:13 -0800 From: quanah@zimbra.com To: mlstarling31@hotmail.com; openldap-technical@openldap.org Subject: RE: Server Side Searching Overlay

--On Tuesday, December 22, 2015 2:10 PM -0500 Michael mlstarling31@hotmail.com wrote:

...

I could really use some help here if anyone can sort my questions it would be greatly appreciated..I'll even through in a bundt cake and/or canned ham since it's the holidays and all.

Modifying core schema is rarely a good idea, and often frowned upon.

There are a number of reasons why doing sorting on the server side is an extremely bad idea. It's generally a much better idea to do the sorting in the client.

--Quanah

---

...

From: mlstarling31@hotmail.com To: openldap-technical@openldap.org Subject: Server Side Searching Overlay Date: Mon, 21 Dec 2015 19:27:01 -0500

So I have a request from developers to enable the sssvlv overlay. They would like the server to return sorted searches on

I enabled the overlay and then to test the functionality I added the following "ordering" rule to the core.schema.

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' ORDERING caseIgnoreOrderingMatch SUP name )

The following ldapsearch works as expected and returns the "sn" attribute in alphabetical order.

ldapsearch -x -ZZ -D cn=root,dc=testlott,dc=lott -w password objectclass=person -E sss=sn sn

Based on this information I have several questions.

1. Will I be violating any RFC by modifying the core.schema?
2. The developers want the same functionality with the "cn" attribute. Is

this supported or even possible? 3. They also request this functionality on a couple of attributes in a custom schema. Is adding an "ordering" rule as I did with the "sn" attribute the proper way to do this?

Thanks.

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration

Thanks Quanah, and I understand the best way to do this is to have the client do the sorting. However, with that said I still need to provide a proof of concept for the development team before I try and persuade them otherwise. Is it possible to enable sssvlv for the CN attribute?

Well, I simply don't understand the way this technical list operates sometimes. The feature is there so there must be some worthy use cases for implementing it. At the very least, simply because the documentation on sssvlv as it relates to OpenLDAP is sparse at best, could someone please point me to some comprehensive documentation on the subject. Perhaps some concrete reasons as to when and why you do/don't want to implement server side sorting? The OpenLDAP Administration guide briefly touches on sssvlv and the man pages aren't any more detailed.

From: quanah@zimbra.com Subject: Re: Server Side Searching Overlay Date: Tue, 22 Dec 2015 19:20:15 -0600 To: mlstarling31@hotmail.com CC: openldap-technical@openldap.org

On Dec 22, 2015, at 3:50 PM, Michael mlstarling31@hotmail.com wrote:

From: mlstarling31@hotmail.com To: quanah@zimbra.com; openldap-technical@openldap.org Subject: RE: Server Side Searching Overlay Date: Tue, 22 Dec 2015 14:18:04 -0500

Date: Tue, 22 Dec 2015 11:13:13 -0800 From: quanah@zimbra.com To: mlstarling31@hotmail.com; openldap-technical@openldap.org Subject: RE: Server Side Searching Overlay

--On Tuesday, December 22, 2015 2:10 PM -0500 Michael mlstarling31@hotmail.com wrote:

...

I could really use some help here if anyone can sort my questions it would be greatly appreciated..I'll even through in a bundt cake and/or canned ham since it's the holidays and all.

Modifying core schema is rarely a good idea, and often frowned upon.

There are a number of reasons why doing sorting on the server side is an extremely bad idea. It's generally a much better idea to do the sorting in the client.

--Quanah

---

...

From: mlstarling31@hotmail.com To: openldap-technical@openldap.org Subject: Server Side Searching Overlay Date: Mon, 21 Dec 2015 19:27:01 -0500

So I have a request from developers to enable the sssvlv overlay. They would like the server to return sorted searches on

I enabled the overlay and then to test the functionality I added the following "ordering" rule to the core.schema.

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' ORDERING caseIgnoreOrderingMatch SUP name )

The following ldapsearch works as expected and returns the "sn" attribute in alphabetical order.

ldapsearch -x -ZZ -D cn=root,dc=testlott,dc=lott -w password objectclass=person -E sss=sn sn

Based on this information I have several questions.

1. Will I be violating any RFC by modifying the core.schema?
2. The developers want the same functionality with the "cn" attribute. Is

this supported or even possible? 3. They also request this functionality on a couple of attributes in a custom schema. Is adding an "ordering" rule as I did with the "sn" attribute the proper way to do this?

Thanks.

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration

Thanks Quanah, and I understand the best way to do this is to have the client do the sorting. However, with that said I still need to provide a proof of concept for the development team before I try and persuade them otherwise. Is it possible to enable sssvlv for the CN attribute?

Well, I simply don't understand the way this technical list operates sometimes. The feature is there so there must be some worthy use cases for implementing it. At the very least, simply because the documentation on sssvlv as it relates to OpenLDAP is sparse at best, could someone please point me to some comprehensive documentation on the subject. Perhaps some concrete reasons as to when and why you do/don't want to implement server side sorting? The OpenLDAP Administration guide briefly touches on sssvlv and the man pages aren't any more detailed.

For compatibility with broken applications written by clueless developers mainly. It is an extension pushed by MS for their not really LDAP AD servers. Somewhat necessary to have as an option for the Samba project so it can use OpenLDAP as an AD replacement. Does that help? :). Ponder what will happen on an LDAP server where it had 10million objects it is having to sort and hold in memory. Particularly on a memory constrained system. --Quanah

Yes it does help. So I'll assume CN can't be modified in the schema for a reason without recompiling. :) I'll use this information to try and build a compelling case to have the developers do their sorting at the client level.

Thank you.

Date: Wed, 23 Dec 2015 09:16:07 +0100 From: dieter@dkluenter.de To: openldap-technical@openldap.org Subject: Re: Server Side Searching Overlay

Am Tue, 22 Dec 2015 14:10:50 -0500 schrieb Michael mlstarling31@hotmail.com:

...

I could really use some help here if anyone can sort my questions it would be greatly appreciated..I'll even through in a bundt cake and/or canned ham since it's the holidays and all.

From: mlstarling31@hotmail.com To: openldap-technical@openldap.org Subject: Server Side Searching Overlay Date: Mon, 21 Dec 2015 19:27:01 -0500

So I have a request from developers to enable the sssvlv overlay. They would like the server to return sorted searches on I enabled the overlay and then to test the functionality I added the following "ordering" rule to the core.schema. attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' ORDERING caseIgnoreOrderingMatch SUP name ) The following ldapsearch works as expected and returns the "sn" attribute in alphabetical order. ldapsearch -x -ZZ -D cn=root,dc=testlott,dc=lott -w password objectclass=person -E sss=sn sn

[...]

There is no need to modify core schema. Design the search string to your requirements. If you read RFC2891 and ldapsearch(1) carefully, you will realise that the attribute type can be extended by adding an ordering rule OID, which for caseIgnoreOrderingMatch is 2.5.13.2

-Dieter

-- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

Thank you for pointing me in the right direction.