Howard Chu wrote:
> 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.
I understand that pretty well. Really no need to explain that.
> You seem to be arguing that cn=config is only useful for dynamic
> modification,
Nope.
My impression of this thread was that dynamic modification is used as the
strongest argument *for* cn=config. And therefore IMO pointing to using
slapadd as a configuration tool is a contradiction.
> which implies that you use some other format for your seed
> configs, which is, frankly, stupid.
At LDAPcon we already agreed that we slightly disagree. ;-)
But you confirmed that slapd.conf will not be hunked out of 2.5.
So I'm perfectly fine with that.
Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature