Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
--On Friday, December 1, 2023 1:02 PM -0800 Christopher Paul wrote: In summary, I see great value to continuing to support the slapd.conf file-based config, especially for production, and I see a lot of risk induced by deprecating it and forcing people to use OLC. OpenLDAP project, would you please consider to not deprecate slapd.conf? As has been noted numerous times, slapd.conf is unordered and a constant source of configuration errors and unexpected behavior since people routinely throw statements in the wrong place. I would also note that you are literally running a cn=config system with slapd.conf, even if it doesn't appear that way to you, since slapd just automatically turns slapd.conf into a cn=config db (although it may not function as desired due to preceding note). For myself, being able to update the servers on the fly has allowed me to: a) Push ACL changes w/o restart b) Push indexing changes w/o restart c) Push schema changes w/o restart d) Push log level changes w/o restart (Particularly useful when debugging problems in a live environment) I keep my cn-config db in git & use a test environment confirm changes prior to pushing them live in production. --Quanah
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
--On Friday, December 1, 2023 11:04 PM +0100 Geert Hendrickx wrote: databaseconfig rootdn cn=config This is the default value as noted in slapd.conf(5). No need to specify it explicitly. rootpw . May be better to set up cert auth and do a SASL mapping if you need to make config changes from an external host. If you don't need an external host, use LDAPI + EXTERNAL with a mapping for the root user or similar. --Quanah
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
On Fri, Dec 01, 2023 at 13:02:03 -0800, Christopher Paul wrote: > The one and only advantage I see to OLC is that you can make some changes on > the fly, without restarting the server. But is this ever necessary, or even > advisable in a production environment? I prefer the traditional slapd.conf as well, but one very good use case of dynamic configuration is being able to add indexes on a (very) large directory on-line. It can take many hours on a 100 GB directory, and if you have to do that while slapd is down, it also needs to catch up with many hours of replication afterwards, before you can use it again. So being able to do this on-line is really convenient. We use a hybrid approach to achieve this: we use a traditional slapd.conf (under version control), but when we need to add an index, we temporarily enable a config database in slapd.conf *without a persistent backend*: > database config > rootdncn=config > rootpw. This exposes our slapd.conf configuration as LDIF, and lets us modify it, but in a non-persisent manner. So we can dynamically add an olcDbIndex entry to create a new index on-line, and then add that same index in our slapd.conf for persistent use after slapd restart. Best of both worlds? Geert
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
On Thu, 30 Nov 2023 at 16:06, Bastian Tweddell wrote: Please also note [1]: ``` The older style slapd.conf(5) file is still supported, but its use is deprecated and support for it will be withdrawn in a future OpenLDAP release. ``` Is this already on the roadmap when this will happen? I really hope this never happens. The one and only advantage I see to OLC is that you can make some changes on the fly, without restarting the server. But is this ever necessary, or even advisable in a production environment? In production, people want LDAP servers to be perfectly stable and reliable software-as-an-appliances. They will run 10 (even 20) years this way. Production configuration should be immutable. The configuration should not need to change from day to day within production. And even when it does, if clients are configured correctly, there is the ability to restart individual servers without impacting the entire service. As for sync'ing cn=config, I've tried it. I don't see the advantage of it over having one configuration file (or maybe one each for providers and another for consumers) and then deploying each from source control, and controlled with file signature monitoring, for extra security. You can have the best of both worlds by enabling the config database, but not converting to it. This "converts" your slapd.conf into the memory-based OLC which can be updated on the fly, but not persisted. To me this is the ideal, but then even still, within many of theses setups, I have never needed to use the OLC for on-the-fly-changes, so in retrospect, do not see the necessity of this. In summary, I see great value to continuing to support the slapd.conf file-based config, especially for production, and I see a lot of risk induced by deprecating it and forcing people to use OLC. OpenLDAP project, would you please consider to not deprecate slapd.conf? Chris Paul | Rex Consulting | https://www.rexconsulting.net
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
Hi, We wonder about that deprication as well! When will that happen..? How long can we continue to drive the more comfortable road? :-) Have a nice weekend to all! On Thu, 30 Nov 2023 at 16:06, Bastian Tweddell wrote: > > Please also note [1]: > ``` > The older style slapd.conf(5) file is still supported, but its use is > deprecated and support for it will be withdrawn in a future OpenLDAP > release. > ``` > > Is this already on the roadmap when this will happen? > >
