Hi,
We are currently redesigning our OpenLDAP server setup. Until now we used one primary server with four replicas, which gets synced with syncrepl. Each server is using a slapd.conf (Which is deployed via a central config management). Using this setup, we can define one ACL entry set for our primary server and another set for our replicas. Also, this makes viewing and understanding these ACLs quite easy.
As part of our redesign, I've looked up the documentation, which states: "slapd.conf(5) has been deprecated and should only be used if your site requires one of the backends that hasn't yet been updated to work with the newer slapd-config(5) system."
Now my question is, is the slapd.conf going to be removed in future OpenLDAP versions, or will it remain in OpenLDAP? Should we move our configuration to the new slapd-config system?
Kind regards,
Christopher Schenk
Christopher, hello.
On 14 Oct 2025, at 13:49, christopher.schenk@uni-paderborn.de wrote:
Now my question is, is the slapd.conf going to be removed in future OpenLDAP versions, or will it remain in OpenLDAP?
I can't definitively answer this part of the question (though I'd guess the answer would be that it would be removed at some point).
Should we move our configuration to the new slapd-config system?
Probably, yes. But I'm chipping here, on-list, to suggest that there is a middle ground, which preserves the advantages of the single-file slapd.conf (which I get the impression is what you're regretting soon losing).
What I do is have a file slapd.ldif which is the single-file master version of the configuration, which lives under version control. To make changes to the deployed configuration, I have a script which stops the primary server, slapcats the database, nukes the server, slapadds the slapd.ldif with `slapadd -n 0 -F .../slapd.d -l slapd.ldif`, reloads the data, and restarts the server.
This is obviously somewhat clumsy, in comparison with the slickness of the live updates to the server configuration, that are what the documentation describes. It involves brief downtime for the primary (but that's what replicas are for) and it might become burdensome if the data volumes got a _lot_ bigger. I feel a bit grubby about this!
But it has the key advantage that I can keep that configuration under version control, and (as a consequence) know, when I test server configuration changes, either in unit tests or dev environments, that I'm using the identical configuration to the production service. I have thought about developing a workflow involving live updates to a server configuration, slapcatting of the cn=config, version-controlling diffs, etc, etc, but it rapidly seemed fragile the more I thought about the details.
In fact the primary and the replicas share a slapd.ldif.in, which has some extra (slightly hacky) markup within it, which is the source for the slapd.ldif for both the primary and the replicas. So there's really only one configuration file for all the servers.
Best wishes,
Norman
On 10/14/2025 9:25 AM, Norman Gray wrote:
Christopher, hello. > > On 14 Oct 2025, at 13:49,
christopher.schenk@uni-paderborn.de wrote: > >> Now my question is, is the slapd.conf going to be removed in >> future OpenLDAP versions, or will it remain in OpenLDAP? > > I can't definitively answer this part of the question (though I'd > guess the answer would be that it would be removed at some point). > >> Should we move our configuration to the new slapd-config system? > > Probably, yes. But I'm chipping here, on-list, to suggest that > there is a middle ground, which preserves the advantages of the > single-file slapd.conf (which I get the impression is what you're > regretting soon losing). IMO:
1. The OLC is not a good practice for production, where you want to strictly control changes. 2. The slapd.conf, especially when indented for human readability, vastly easier for a human to read. 3. There is an another middle ground. Enable the config backend (OLC) in the slapd.conf. This provides the capability to do non-persistent changes on the fly (without rebooting), in the case of emergency or near-emergency. The idea is that any "emergency" changes that are needed for the long term, will be implemented through the configuration management pipeline that builds production servers and servers' slapd.confs.
openldap-technical@openldap.org
-
Christopher Paul -
christopher.schenk＠uni-paderborn.de -
Norman Gray