Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Mike Jackson wrote:
I have built a fully automated installation system directly using cn=config. I have a file called config.ldif which contains a lot of %%MACROS%% and a tiny perl script that replaces those macros with actual values depending on the details of the particular installation. So, there isn't any of this silliness of creating slapd.conf, converting it into cn=config, and then continuing - that's an unnecessary step.
After I generate the real config.ldif from the template config.ldif, I simply load it with slapadd to build my cn=config hierarchy.
slapadd \ -n0 \ -v \ -F ${CONF_DIR} \ -l ldifs/config.ldif
When using slapadd to fully load cn=config you have to stop your slapd during that. So this is definitely *not* how cn=config is supposed to be operated.
Perfectly fine for bootstrapping the initial config though.
But the main argument for cn=config in this discussion is *modifying* the configuration of a running server without taking it down. So Mike's arguing with boot-strapping with slapadd is clearly a contradiction.
IMO this is one of the main problems of OpenLDAP admins with cn=config, besides lack of comments, missing support for deletion etc.: Many of the instructions on the mailing list how to use back-config are not really consequent. And sorry that I have to repeat my statement, this is a bit consequence of the design. And i might be worth to rethink some aspects of it.
In this post I believe you're the one who has missed the point. The point is the cn=config format serves both needs - you can create a slapd configuration in pure LDIF, and you can dynamically modify it. You seem to be arguing that cn=config is only useful for dynamic modification, which implies that you use some other format for your seed configs, which is, frankly, stupid.