Hello,
I noticed that with OpenLDAP 2.4.30, a search request with a non criticical sss control on an attribute without ordering matching rule returns an error:
clement@ader:~/Programmes/openldap$ bin/ldapsearch -H ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b ou=people,ou=XXX -E sss=cn # extended LDIF # # LDAPv3 # with server side sorting control #
# search result search: 2 result: 18 Inappropriate matching text: serverSort control: No ordering rule
# numResponses: 1
Before, the error was only returned if the control was set to critical. This was discussed in this ITS: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6647
Is this behavior change intentional or is this a side effect of of recent commit?
Clément.
On 2011-09-08 I had set aside a note that this behaviour was intentional. So when upgrading to 2.4.25 or beyond you must take care to install the new schemas... Unfortunately, in the note is no link to the approp docu.
suomi
On 04/19/2012 09:20 AM, Clément OUDOT wrote:
Hello,
I noticed that with OpenLDAP 2.4.30, a search request with a non criticical sss control on an attribute without ordering matching rule returns an error:
clement@ader:~/Programmes/openldap$ bin/ldapsearch -H ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b ou=people,ou=XXX -E sss=cn # extended LDIF # # LDAPv3 # with server side sorting control #
# search result search: 2 result: 18 Inappropriate matching text: serverSort control: No ordering rule
# numResponses: 1
Before, the error was only returned if the control was set to critical. This was discussed in this ITS: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6647
Is this behavior change intentional or is this a side effect of of recent commit?
Clément.
Le 19 avril 2012 11:49, anax anax@ayni.com a écrit :
On 2011-09-08 I had set aside a note that this behaviour was intentional. So when upgrading to 2.4.25 or beyond you must take care to install the new schemas... Unfortunately, in the note is no link to the approp docu.
What are the new schemas your are talking about?
Clément.
Clément OUDOT wrote:
Hello,
I noticed that with OpenLDAP 2.4.30, a search request with a non criticical sss control on an attribute without ordering matching rule returns an error:
clement@ader:~/Programmes/openldap$ bin/ldapsearch -H ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b ou=people,ou=XXX -E sss=cn # extended LDIF # # LDAPv3 # with server side sorting control #
# search result search: 2 result: 18 Inappropriate matching text: serverSort control: No ordering rule
# numResponses: 1
Before, the error was only returned if the control was set to critical.
Looking back thru git, I see nothing to support this statement.
This was discussed in this ITS: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6647
Is this behavior change intentional or is this a side effect of of recent commit?
Please give the version number where you last saw it behaving as you describe. I'm not seeing it.
It looks to me like the current behavior is wrong; you should file an ITS.
Le 20 avril 2012 13:09, Howard Chu hyc@symas.com a écrit :
Clément OUDOT wrote:
Hello,
I noticed that with OpenLDAP 2.4.30, a search request with a non criticical sss control on an attribute without ordering matching rule returns an error:
clement@ader:~/Programmes/openldap$ bin/ldapsearch -H ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b ou=people,ou=XXX -E sss=cn # extended LDIF # # LDAPv3 # with server side sorting control #
# search result search: 2 result: 18 Inappropriate matching text: serverSort control: No ordering rule
# numResponses: 1
Before, the error was only returned if the control was set to critical.
Looking back thru git, I see nothing to support this statement.
This was discussed in this ITS: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6647
Is this behavior change intentional or is this a side effect of of recent commit?
Please give the version number where you last saw it behaving as you describe. I'm not seeing it.
I tested the patch proposed in ITS 6647 (applied on 2.4.23 version): ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.patch
It was doing the job: returning an error only if the control was critical.
Then I see in the changelog that this ITS was fixed in the 2.4.24 release:
Fixed slapo-sssvlv to not advertise when unused (ITS#6647)
But it seems that the real applied fix is: not declare sss control in RootDSE when the overlay was compiled in slapd (so not as a module) but not loaded in the configuration. Could you confirm?
It looks to me like the current behavior is wrong; you should file an ITS.
I will do that.
Thanks,
Clément.
openldap-technical@openldap.org
-
anax -
Clément OUDOT -
Howard Chu