On 4/5/22 17:34, Norman Gray wrote:
I've never used slapd.conf, and I'm worried I'm missing something, or
that there's an interestingly different perspective on how to
configure openldap, which I could usefully learn about.
Don't worry about missing something magical. slapd.conf and cn=config
are supposed to be identical regarding features.
If I want to set up a new (testing?) instance, or test a tweaked
configuration, then I blow away any pre-existing slapd.d, slapadd
slapd.ldif, upload a dump of the live database (which takes a few
seconds with -q), start slapd, and off we go.
All of the configuration is in that single slapd.ldif file.
Basically you're imitating the behaviour of a static configuration by
using some extra command-line step. IMHO that's fine if it already works
for you. And it allows clean staging.
I can see that there's a way of working where the 'live' cn=config
tree is the source of truth, and one backs that up carefully, but
that doesn't seem an entirely comfortable way of working, to me.
Not comfortable for me either.
And I can see that if there were a very high volume of writes, then
the few seconds of primary-server downtime here could become
intricate. But if one had a setup like that, then presumably one has
a multi-master configuration, so that the primaries could have their
configurations updated from a single slapd.ldif in rotation.
The latter has been also my argument for years.
Well, depending on which schema changes you're doing updating replicas
one after the other might not work. But this also applies to updating
the live config.
I'm not really sure what devops-friendly means here.
All config management systems comes with a decent templating engine for
creating text files, let a service validate them and have a notification
system for restarting the service in case of a config change. This is
very simple to understand and idempotent without extra procedure.
Ciao, Michael.
