Hi,
On Fri, 28 Mar 2014, Nick Milas wrote:
On 28/3/2014 3:59 ??, Christian Kratzer wrote:
Ordering is already implemented.
Thanks Christian for your feeback, but, as of v2.4.39 (which I am running), I
can't confirm correct ACL ordering.
As explained in the thread I provided, ordering (of ACL rule numbers) is
string-based and not number-based, so LDAP clients cannot display ACL rules
in correct order.
The current order of my 34 rules (as displayed by clients) is:
{0},{10},...{19},{1},{20},{21},...{29},{2},{30},...{34},{3},{4},{5},{6},{7},{8},{9}
which makes ACL listing very unfriendly.
strange I can see correct ordering of my acl and also of schema definitions in
both ldapvi and ldapsearch.
This is also on 2.4.39.
--snipp--
[ck@ldaptest1]$ ldapsearch -x -W -b cn={0}core,cn=schema,cn=config -o ldif-wrap=no '(objectClass=olcSchemaConfig)' olcAttributeTypes
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <cn={0}core,cn=schema,cn=config> with scope subtree
# filter: (objectClass=olcSchemaConfig)
# requesting: olcAttributeTypes
#
# {0}core, schema, config
dn: cn={0}core,cn=schema,cn=config
olcAttributeTypes: {0}( 2.5.4.2 NAME 'knowledgeInformation' DESC 'RFC2256:
knowledge information' EQUALITY caseIgnoreMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{32768} )
olcAttributeTypes: {1}( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last
(family) name(s) for which the entity is known by' SUP name )
olcAttributeTypes: {2}( 2.5.4.5 NAME 'serialNumber' DESC 'RFC2256: serial
number of the entity' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
olcAttributeTypes: {3}( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519:
two-letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE )
olcAttributeTypes: {4}( 2.5.4.7 NAME ( 'l' 'localityName' ) DESC 'RFC2256:
locality which this object resides in' SUP name )
olcAttributeTypes: {5}( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' ) DESC
'RFC2256: state or province which this object resides in' SUP name )
olcAttributeTypes: {6}( 2.5.4.9 NAME ( 'street' 'streetAddress' ) DESC
'RFC2256: street address of this object' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
olcAttributeTypes: {7}( 2.5.4.10 NAME ( 'o' 'organizationName' ) DESC 'RFC2256:
organization this object belongs to' SUP name )
olcAttributeTypes: {8}( 2.5.4.12 NAME 'title' DESC 'RFC2256: title associated
with the entity' SUP name )
olcAttributeTypes: {9}( 2.5.4.14 NAME 'searchGuide' DESC 'RFC2256: search
guide, deprecated by enhancedSearchGuide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
olcAttributeTypes: {10}( 2.5.4.15 NAME 'businessCategory' DESC 'RFC2256:
business category' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
olcAttributeTypes: {11}( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal
address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
olcAttributeTypes: {12}( 2.5.4.17 NAME 'postalCode' DESC 'RFC2256: postal code'
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{40} )
olcAttributeTypes: {13}( 2.5.4.18 NAME 'postOfficeBox' DESC 'RFC2256: Post
Office Box' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{40} )
olcAttributeTypes: {14}( 2.5.4.19 NAME 'physicalDeliveryOfficeName' DESC
'RFC2256: Physical Delivery Office Name' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
olcAttributeTypes: {15}( 2.5.4.20 NAME 'telephoneNumber' DESC 'RFC2256:
Telephone Number' EQUALITY telephoneNumberMatch SUBSTR
telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
--snipp--
Of course if your client tries to string sort the results after reading it will
mix things up.
If the clients leaves the order as it is, everything should be in correct order.
If the client desires to sort it would be trivial to focus on the braces and
numerically evaluate the value as sort order.
The problem with padding is how much to add. Do you want {000} or {00000000} or
whatever.
Both of my favourite clients ldapsearch and ldapvi leave the order untouched.
Greetings
Christian
If I remember right (I can't find the thread right now), I had proposed in
the past (as a simple solution) to switch numbering from {0}, {1},... to e.g.
{000}, {001},... or even {0000}, {0001},...so that clients can list them
correctly.
N
--
Christian Kratzer CK Software GmbH
Email: [email protected] Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
