Hello,
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 ldap_write: want=50, written=50 0000: 30 30 02 01 08 65 2b 0a 01 12 04 00 04 24 73 65 00...e+......$se
0010: 72 76 65 72 53 6f 72 74 20 63 6f 6e 74 72 6f 6c rverSort control
0020: 3a 20 4e 6f 20 6f 72 64 65 72 69 6e 67 20 72 75 : No ordering ru
0030: 6c 65 le
conn=1000 op=7 do_search: get_ctrls failed
Where should I specify the ordering rule for the uid attribute? The core schema?
Thank you
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.
As you can see uid is commented in the schema file as is cn
#attributetype ( 0.9.2342.19200300.100.1.1 # NAME ( 'uid' 'userid' ) # DESC 'RFC1274: user identifier' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
In the past this was possible, or the attributes had an ordering. I do not know when this changed.
On Fri, Jan 15, 2010 at 8:27 AM, Diego Lima lists@diegolima.org wrote:
Hello, 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 ldap_write: want=50, written=50 0000: 30 30 02 01 08 65 2b 0a 01 12 04 00 04 24 73 65 00...e+......$se
0010: 72 76 65 72 53 6f 72 74 20 63 6f 6e 74 72 6f 6c rverSort control
0020: 3a 20 4e 6f 20 6f 72 64 65 72 69 6e 67 20 72 75 : No ordering ru
0030: 6c 65 le
conn=1000 op=7 do_search: get_ctrls failed Where should I specify the ordering rule for the uid attribute? The core schema? Thank you -- Diego Lima
--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.
As you can see uid is commented in the schema file as is cn
# attributetype ( 0.9.2342.19200300.100.1.1 # NAME ( 'uid' 'userid' ) # DESC 'RFC1274: user identifier' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
In the past this was possible, or the attributes had an ordering. I do not know when this changed.
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
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
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.
Adam Tauno Williams awilliam@opengroupware.us writes:
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 -
I am running 2.4.21 and don't receive any errors. What attribute type and ordering rule did you define as sortkeylist? I just tested with ldapsearch. ldapsearch -E'!sss=sn:2.5.13.3' -Y DIGEST-MD5 -U user -w passwd -H ldap://localhost:9004 -b searchbase "(filter)" attributes
# search result search: 3 result: 0 Success control: 1.2.840.113556.1.4.474 false MAMKAQA= sortResult: (0) Success
-Dieter
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.
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.
openldap-technical@openldap.org
-
Adam Tauno Williams -
Diego Lima -
Dieter Kluenter -
Edward Capriolo -
Howard Chu -
Quanah Gibson-Mount