Will I need the -e 
"2.16.840.1.113730.3.4.9" since in the example below the attribute type I want 
to use is "-E sss=displayname", or will I still need the "-e" 
option to correspond with the "-E" options?

Best Regards,Auteria Winzer Jr.

>________________________________
> From: Aaron Richton <rich...@nbcs.rutgers.edu>
>To: Auteria W. Winzer Jr. <wwin...@yahoo.com> 
>Cc: "openldap-technical@openldap.org" <openldap-technical@openldap.org> 
>Sent: Tuesday, February 18, 2014 1:35 PM
>Subject: Re: ldapsearch error - Unknown error (60)
> 
>
>On Tue, 18 Feb 2014, Auteria W. Winzer Jr. wrote:
>
>> Aaron,
>> 
>> If the sort attribute is "displayname" which is how it's configured within 
>> Oracle/Sun Directory Server VLV Browsing Index (dn=display_browsing_index) 
>> the vlvFilter that's defined is
>> "(&(objectClass=groupOfUniqueNames)(displayname=*))".
>> 
>> With in your example below, can you explain in detail "-E sss=heightInCm -E 
>> vlv=0/1/0/1"? What's an example for "heightInCm", and what does "0/1/0/1" 
>> represent?
>
>In OpenLDAP ldapsearch(1) -E takes the form extension=parameter.
>
>So for the SSS extension, see RFC2891, where section 1.1 shows the 
>controlValue must include at least one attributeType (and optionally more 
>parameters too, which I elected not to put in my example). So "heightInCm" is 
>my example, feel free to substitute the 
>attributeType/orderingRule/reverseOrder you actually desire for your 
>application. (Particularly important since I made "heightInCm" up and I don't 
>believe that's been registered anywhere...)
>
>And for vlv, see the I-D I linked to, 0/1/0/1 is my example that gets 
>automagically encoded properly by ldapsearch(1) to refer to the controlValue 
>defined in Section 6.1. Again you should feel free to substitute the 
>parameters you actually desire for your application.
>
>> With Best Regards,
>> Auteria Winzer Jr.
>> 
>> _______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>>       From: Aaron Richton <rich...@nbcs.rutgers.edu>
>>       To: Auteria W. Winzer Jr. <wwin...@yahoo.com>
>>       Cc: "openldap-technical@openldap.org" <openldap-technical@openldap.org>
>>       Sent: Tuesday, February 18, 2014 1:05 PM
>>       Subject: Re: ldapsearch error - Unknown error (60)
>> 
>> On Tue, 18 Feb 2014, Auteria W. Winzer Jr. wrote:
>> 
>> > To the members of the mailing list,
>> >
>> > Upon a test search I'm getting the following error:
>> >
>> > $ ldapsearch -LLL -v -z none -x -e "2.16.840.1.113730.3.4.9" -h 
>> > bugsbunny.bar -p 9999 -b "ou=foo,o=bar" -D "uid=xxx,ou=foo,o=bar" -w 
>> > "xxxxxxxx" "(&(objectClass=groupOfUniqueNames)(displayname=*))" displayname
>> > ldap_initialize( ldap://bugsbunny.bar:9999 )
>> > filter: (&(objectClass=groupOfUniqueNames)(displayname=*))
>> > requesting: displayname
>> > Unknown error (60)
>> > Additional information: VLV Control
>> >
>> > When looking up the error I noticed the following:
>> >
>> > LDAP_SORT_CONTROL_MISSING - 60 (x'3C) - Unused in standards. Sun LDAP 
>> > Directory Server only. Server did not receive a required server-side 
>> > sorting control.
>> >
>> > Can someone that has experience with this type of LDAP search criteria 
>> > assist me to obtain a final resolution?
>> 
>> See the relevant I-D 
>> http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09
>> 
>> per section 6.1, you need to have a SSS control in addition to the VLV 
>> control. You're missing that, hence the server says it didn't receive the 
>> requirement. Make sure your requests comply with the I-D.
>> 
>> Also, the controlValue has precise requirements, and I don't see an example 
>> of that above.
>> 
>> Using OpenLDAP's ldapsearch(1) I believe this would go something like:
>> 
>> ldapsearch -z none -x -E sss=heightInCm -E vlv=0/1/0/1 -b cn=foo -h 
>> ldap.example.com (uid=user)
>> 
>> another example from the archives:
>> 
>> http://www.openldap.org/lists/openldap-technical/201005/msg00087.html
>> 
>> 
>> 
>> 
>> 
>
>
>

Reply via email to