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:

Hi,

On Thu, 27 Mar 2014, Sven Jourgensen wrote:

...

Is there a tool to perform the reverse operation, and convert the newer cn=config configuration back into a slapd.conf?

no. This is currenty a one way street and is expected to stay that way.

Is there any special reason you would like to have this ?

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:

Sounds like a job for diff:

slapcap -n0 -F <path_to_existing_slapd.d> > $TMP/slapd-portable.ldif

mkdir $TMP/slapd.d.generic slaptest -f <path_to>/slapd.conf.generic -F $TMP/slapd.d.generic slapcat -n0 -F $TMP/slapd.conf.generic > $TMP/generic-portable.ldif

diff -ruN $TMP/slapd-portable.ldif $TMP/generic-portable.ldif

Compare the output, and adjust your generic slapd.conf, then rinse, lather, and repeat until you get the same output.

-- Dan White

On Thu, 27 Mar 2014, Sven Jourgensen wrote:

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.

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:

On 03/27/2014 04:38 PM, Aaron Richton 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...)

I can give my reason:

• it's more readable than the ldif slapcat is producing
• I can put comments on it
• I can go back to a previous configuration just by a cp o editing back the

contents

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

Hi,

On Fri, 28 Mar 2014, Nick Milas wrote:

On 28/3/2014 1:25 ??, Christian Kratzer wrote:

...

I consider cn=config superior once you get your head wrapped around it.

On 28/3/2014 12:53 ??, Simone Piccardi wrote:

...

• I can put comments on it

Christian,

Please allow me to intervene in the thread to say that your comments are very valid, but still, Simone's need for comments is beyond doubt.

Here is a long discussion done in 2012 about this (this link points to my own message, but it is a long thread with valuable info):

http://www.openldap.org/lists/openldap-technical/201203/msg00214.html

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.

I take the opportunity to repeat here that, IMHO it is vital to have (at least) correct ordering of ACLs and the ability to add comments anywhere in the config. Also see other usability issues mentioned in the above thread and elsewhere.

Ordering is already implemented. +1 for the rest.

I hope that now, when 2.5 branch has started, such issues may be addressed!

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

All the best, Nick

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

On 03/28/2014 01:16 PM, Nick Milas wrote:

On 28/3/2014 1:25 μμ, Christian Kratzer wrote:

...

I consider cn=config superior once you get your head wrapped around it.

On 28/3/2014 12:53 μμ, Simone Piccardi wrote:

...

• I can put comments on it

Christian,

Please allow me to intervene in the thread to say that your comments are very valid, but still, Simone's need for comments is beyond doubt.

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

Frantisek Hanzlik franta@hanzlici.cz writes:

Or are somewhere prepared simple and working config. files as examples?

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