Support OpenLDAP 2.4 configuration.

[jof]

It seems that all the necessary steps are being taken on debian platforms to setup OpenLDAP to have an ocl-style config directory in /etc/ldap/slapd.d: https://github.com/opscode-cookbooks/openldap/blob/master/recipes/server.rb#L84

However, the defaults file for the init script isn't setup to point there.

Fix this template to actually do the right thing.

[jof]

OpenLDAP significantly changes how configuration of an OpenLDAP server is handled.
More detail here: http://www.openldap.org/doc/admin24/slapdconf2.html

The short version is that the slapd.conf configuration file is being deprecated, and instead, all the configuration for slapd will come from an LDIF-backed LDAP database (LDAP configuring an LDAP server.... how meta).
With this new scheme, the running configuration of the database may be changed on the fly. Changes will be saved to the LDIF back (/etc/ldap/slapd.d, for example), but not reflected in the slapd.conf file.

This is a problem with the current state of the openldap::master recipe, because as the online configuration changes over time, if any change is made to slapd.conf, it will attempt to "convert" the config into /etc/ldap/slapd.d, but merging in the changes, potentially leading to an un-restart'able database.

I propose we make a few changes:

• Add some attributes to branch the configuration behavior depending on the package version.
• If greater than 2.4:
  -- Update the init script defaults options to use slapd.d (as this issue started to do)
  -- Either:
  --- Explicitly not support online configuration changes to cn=config in conjunction with this cookbook. Switch execute[slapd-config-convert] to also empty out the destination directory before converting.
  --- Include a chef_gem like net-ldap and start applying attributes to the running system by using LDAP directly.

Personally, given the level of effort, I would probably select the option of explicitly not supporting online configuration changes.
However, in the long run, this will be the OpenLDAP default and we will have to integrate a chef-level LDAP client to configure the server at some point.

[tas50]

I'd like to tackle this as part of the rewrite of this cookbook. My first goal is to remove all the client auth setup from the cookbook since that doesn't really have anything to do with openldap other than the LDAP part. After that's complete I'm going to investigate writing LWRPs to handle more robust server installs.

[cheeseplus]

This one has been open for a while but I'll give an update on the state of things and what we can do from here.

Background: I managed one of the largest OpenLDAP clusters in higher education and personally did the conversion from 2.3 -> 2.4 so strong opinions abound.

• The tacit support in the cookbook cor cn=config up until 3.0.0 was fundamentally broken as the init scripts still pointed at the slapd.conf

We've removed that entirely since it never really worked and has significant issues regarding future runs. We've been on OpenLDAP 2.4 for 7 years, both administrators and distros still use slapd.conf because it's fundamentally easier to deal with in an automated fashion. We've explicitly stopped supporting slapd.d/cn=config entirely and we're also not going to worry much about 2.3 because as stated earlier, 2.4 has been out for a bit.

If we want to look at properly implementing cn=config then we should take a look at an existing implementation such as https://github.com/threatstack/ts-ldap which makes use of net-ldap. We'll keep this as a feature request and happily review PRs for said functionality but currently we only support slapd.conf for configuration.

[cheeseplus]

After some discussion with @iennae we've decided that at the very least we should add a note to the readme explaining this so that it's easily searchable and once that is done, close this issue, and implement this as a project breaking it down into smaller issues as tasks.

[jof]

+1 on your proposed path forward, @cheeseplus.
I think having very explicit textual configuration makes a lot more sense for configuration management than to support online configuration changes, which opaquely live in a database.

Calling out this choice in the README seems like the right thing to do.