Paul B. Henson wrote: >> From: Quanah Gibson-Mount >> Sent: Thursday, January 30, 2014 1:09 PM >> >> Having used both methods for years, I disagree. It is a learning curve to >> understand the cn=config backend, but once you do, it is far superior to >> the old flat file, and to me, much easier to use. > > My main issue with the cn=config method is how to integrate it into our > revision control and approval system. > > Currently, with the flat file, the authoritative configuration is stored in > a revision control system. When there are any changes to be made, they are > made in a development branch, tested, then reviewed and approved to be > merged into the production branch, at which point they are pushed out to the > system. I'm not really sure how to do that with the dynamic cn=config > method. > > For example, currently our revision control system could tell us exactly > what configuration was in place seven weeks ago. How would you do that with > cn=config? I suppose you could have a change log document in revision > control, but unlike the actual configuration file in revision control, > there's no way to say whether or not the changes made dynamically via > cn=config are exactly matched to the changelog. Unless perhaps the ldif > executing the change is maintained in revision control? I'm also working with a configuration pulled from revision control system and pushed to the systems with automated orchestration system. As Howard confirmed on this mailing list static configuration will still be available in OpenLDAP 2.5.x. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature