Re: Olc deployment vs slapd.conf based deployment

[Christopher Wood <christopher_wood@pobox.com>]

On Mon, Sep 18, 2017 at 08:01:31PM +0200, Michael Ströder wrote:
> Quanah Gibson-Mount wrote:
> > > So instead of writing a single file (in one FS transaction) after
> > > letting slaptest check it I have to write several files (multiple
> > > FS operations), diff that and then apply multiple LDAP operations.
> > 
> > Hm? How is this any different really than tracking slapd.conf in git?
> > And plenty of people break out slapd.conf into multiple files and use
> > "include" handling to pull, such as with schema, ACLs, etc.  I see no
> > difference here.
> 
> (Except the schema files) I break up slapd.conf in several *templates* but
> the config management (currently ansible) generates a single slapd.conf file
> on the target system. So after the includes in the template engine there is
> a single file transferred to the target and installed there.
> 
> > > Yeah, sounds really great regarding error handling.
> > 
> > How does this differ from slapd.conf?  You get no error handling with
> > that, either, if you modify it and commit it to git.
> 
> I had some detail issue with slaptest I have to revisit. But mainly I want
> to use "validate: slaptest..." in the ansible template task to avoid
> installing a broken slapd.conf. Yes, that's feasible even with a directory
> tree. But it needs much more work/caution without added value.
> 
> Ciao, Michael.
> 

It feels like it would be relatively trivial to run a cn=config managed by a configuration management system. I've already gotten puppet to stand up a multimaster pair where the replication Just Works (at two jobs now), so ensuring that the CM doesn't mess up the existing cn=config seems fairly trivial with the -F option to slapd.

The ingredients and sequence (I have a+b and that's fine for me right now):

a) ldif template, creates an ldif file on the host
b) slapadd exec which runs (only once) on the ldif to populate a specific cn=config directory, requires the ldif file to exist
c) exec which runs slaptest on that directory, requires the slapadd exec to ahve succeeded
d) init script template where -F points to that directory, service restart requires the slaptest to have succeeded

If I hook everything on to the template name then I would get:

1) the ldif

/etc/me/config_one.ldif

2) cn=config

/opt/openldap/etc/openldap/config_one/cn=config.ldif

3) init script (cut-down example)

stop() {
  kill `cat /var/run/openldap.pid`
}

start() {
  /opt/openldap/libexec/slapd -F /opt/openldap/etc/openldap/config_one
}

restart() {
  start
  stop
}

This seems like it would work because the init script stop doesn't rely on the cn=config directory being known, and every config change is a different template. I could also work out something deft with the commit hash of the git repository holding the templates combining with the template filename to make something more unique so that templates themselves could change, but you get the general idea.