Adam Tauno Williams wrote:
On Thu, 2010-02-18 at 08:29 -0500, Adam Tauno Williams wrote:
On Fri, 2010-01-15 at 11:27 -0200, Diego Lima wrote:
I have enabled the server-side sorting overlay and I received the following error on a search: sssvlv: no ordering rule specified and no default ordering rule for attribute uid <= get_ctrls: n=1 rc=18 err="serverSort control: No ordering rule" send_ldap_result: conn=1000 op=7 p=3 send_ldap_response: msgid=8 tag=101 err=18 ber_flush2: 50 bytes to sd 13 Where should I specify the ordering rule for the uid attribute? The core schema?
I believe I have this issue as well. Since upgrading to OL 2.4.20 our OpenFire XMPP server has been logging an unending stream of - 2010.02.15 11:02:26 [org.jivesoftware.openfire.ldap.LdapManager.retrieveList(LdapManager.java:1709)] javax.naming.directory.InvalidSearchFilterException: [LDAP: error code 18 - serverSort control: No ordering rule]; remaining name '' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source) at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source) No changes were made to the OpenFire configuration, so the issue must be do to a change in OL schema. Browsing our DSA's schema and cn and uid have no ordering rule.
Setting the OpenFire server property "ldap.clientSideSorting" to "true" seems to have cleared up this issue. Without that property OpenFire was requesting the control 1.2.840.113556.1.4.473 on the "uid" attribute.
Not sure what you're pointing out here. OpenLDAP doesn't advertise server-side sorting by default, you have to explicitly configure the overlay to get it. So there's no way that just upgrading to 2.4.20 would have suddenly caused this problem to start.