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