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?