"Paul B. Henson" henson@acm.org schrieb am 01.02.2014 um 02:20 in Nachricht
070e01cf1eeb$ded56ab0$9c804010$@acm.org:
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.
Why not check-in the config directory? It shouldn't change that often. You could check in the "slapcat" also, but ordering of entries may be somewhat, well, chaotic. Personally I wrote a program that postprocesses the slapcat LDIF output to write the entries in a structured directory (similar to slapd.d) while avoiding line breaks in the LDIF. I wonder whether it would make sense to sort the attribute namess of an entry (I already have one file per entry)...
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.
Well maybe you'd need another tool, like LDIF-diff-to-ldapmodify ;-)
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 experimenting with importing LDAP database backups into Git with structured LDIFs as described above. Anybody else?
Regards, Ulrich