>>> "Paul B. Henson" <[email protected]> schrieb am 01.02.2014 um 02:20 in >>> Nachricht <[email protected]>: >> 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
