Yes, we've been using the cn=config method since we upgraded our machines a year or two back, and it's created problems that we didn't have with a single flat config file. We don't need the ability to change config on the fly, so we're going to convert back. I have my generic slapd.conf for our machines but I'd like to compare it. s. On Thu, 27 Mar 2014, Christian Kratzer wrote:

Thanks Dan, I did not realise slapcat could be used in this way, that looks ideal. s. On Thu, 27 Mar 2014, Dan White wrote:

On Thu, 27 Mar 2014, Sven Jourgensen wrote: Would you mind documenting your concerns/experiences for the benefit of the list? (And, for that matter, if there are outright flaws they should be tracked in OpenLDAP's ITS...)

Hi, On Fri, 28 Mar 2014, Simone Piccardi wrote: yes it is a very different concept. But after setting up several projects with cn=config I quite enjoy the new style of doing things: 1. I have ldiff snippets with nicely edited and commented acl configs and scheme deinitions that I apply with ldapmodify 2. I use ldapvi for quick changes 3. I replicate cn=config between members of a cluster and only apply changes to one of them 4. I have a bootstrapping config with :include: directives for pulling in standard schema. I do not use slaptest for bootstrapping anymore. 5. I have setup personal admin accounts that have permission to edit both the main dit and cn=config 6. I archive daily, weekly and monthly dumps of the configuration that I can easily diff if needed 7. I very much enjoy chaning the loglevel runtime in case I need detailed output 8. I also greatly enjoy the mostly consistent ordering of the config 9. When I goof up I delete slapd.d and reimport a known good config with slapadd -n0 -F slapd.d -l config.ldif cn=config does take some time getting used to and I myself also resisted for some time. It has a steeper learning curve and we need to document best practices and provide improved documentation for getting started. slapd.conf is not going away in the very near future at least not until the rough edges and bugs in cn=config have been sorted out. I consider cn=config superior once you get your head wrapped around it. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de 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/

Hi, On Fri, 28 Mar 2014, Nick Milas wrote: yes cn=config needs some work and polishing. As we already have ordering in acl and such comments should not bee too hard to add. We still have the problem of formatting of individual attributes like olcAccess and olcSyncrepl which have tons of information. That's why I currently maintain my acl externally and version them using svn which allows me to keep my indentation, comments and formtting. I consider this quite similar to the way I maintain cisco router and asa firewall configs and specific acl on a tftp server and use copy tftp running-config to apply them. Ideally I would like to fire up ldapvi and see my comments and my formatting of large attributes such as olcSyncrepl and olcAccess perhaps split up over multiple lines. This of course poses challenges as the attributes are plain ascii strings. The best approach needs thiniking. Ordering is already implemented. +1 for the rest. I would suppose that patches and discussion is welcome. As a cn=config user I am equally interested in getting full usablity. Kind of like havin feature parity between ipv4 and ipv6 is so important in other areas. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de 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/

Hi, On Fri, 28 Mar 2014, Nick Milas wrote: 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 -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de 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/

On 03/28/2014 01:16 PM, Nick Milas wrote: It's not only about comments, it's also about readability. The ACL order is a problem, but also having what were directives prefixed by olc make the output far less readable, brain is not fast as sed to remove unuseful (for human understanding) prefixes. Just think what an apache or bind configuration file will look if you prepend "olc" to almost all keywords. Simone -- Simone Piccardi Truelite Srl piccardi(a)truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-1032433 50142 Firenze http://www.truelite.it Tel. +39-055-7879597 Fax. +39-055-7333336

Frantisek Hanzlik <franta(a)hanzlici.cz&gt; writes: Hi, I'd start with $ sudo -u openldap mkdir /etc/ldap/slapd.d /srv/ldap/dc=example,dc=org $ sudo -u openldap /usr/sbin/slapadd -F /etc/ldap/slapd.d -n 0 -l config.ldif where config.ldif contains something like the following (based on the default Debian config; at least the paths must be adapted to your installation and init script): dn: cn=config objectClass: olcGlobal olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 dn: cn=module,cn=config objectClass: olcModuleList olcModulePath: /usr/lib/ldap olcModuleLoad: back_mdb dn: cn=schema,cn=config objectClass: olcSchemaConfig include: file:///etc/ldap/schema/core.ldif include: file:///etc/ldap/schema/cosine.ldif include: file:///etc/ldap/schema/nis.ldif include: file:///etc/ldap/schema/inetorgperson.ldif dn: olcBackend=mdb,cn=config objectClass: olcBackendConfig dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: to dn.exact="" by * read olcAccess: to dn.base=cn=Subschema by * read olcSizeLimit: 500 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDbDirectory: /srv/slapd/dc=example,dc=org olcSuffix: dc=example,dc=org olcAccess: to attrs=userPassword by self write by anonymous auth by * none olcAccess: to dn.base="" by * read olcAccess: to * by self write by * read olcRootDN: cn=admin,dc=example,dc=org olcRootPW: secret olcDbMaxSize: 1073741824 olcDbIndex: objectClass eq -- Regards, Feri.