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.