Securing cn=config and allowing micro-engineering

[Nick Milas <nick@eurobjects.com>]

Hello,

Having migrated from slapd.conf, I would like to ask some questions 
regarding cases/scenarios where someone - unintentionally - breaks the 
configuration.

So, let's assume that, due to some misspelling or use of wrong values 
(esp. when using a graphical LDAP Browser - like JXplorer - to maintain 
the configuration DIT), we have added/modified a setting that would 
break the installation without warning.

*Question 1*:
Are there cases where:
1/ LDAP Server will stop immediately? (It is stated that "Beware: You 
can configure cn=config to an unusable state.", ref. with example: 
http://www.zytrax.com/books/ldap/ch6/slapd-config.html)
2/ LDAP Server will continue to operate but, if stopped, when restarted 
it will not be able to restart?

If the answer to Q1.2 above is yes:
*Question 2*:
How can we test at any given point the current configuration to make 
sure it will be OK if/when restarted (AFAIK, slaptest only tests 
slapd.conf and not slapd.d configuration)?

*Question 3* (especially critical if the answer to Q1.1 or Q1.2 above is 
yes):
If the server is stopped, how can we change manually the config settings 
(e.g. by editing slapd.d/ files) to attempt to correct it?

(In one such test I did, I changed - directly in "cn=config.ldif" file - 
olcLogLevel as follows:
Initial state:

   olcLogLevel: Config
   olcLogLevel: Sync

New state (removed one attribute value and changed the other):

   olcLogLevel: -1

and when I tried to start I got:

   ldif_read_file: checksum error on
   "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif"

so I had to re-edit the file and change the values as they were 
initially, which allowed the server to start.

So (to *repeat Question 3*), how can we "re-engineer" cn=config settings 
when off-line? It is always desirable to be able to do some "low-level 
engineering" to the configuration (under administrator's or system 
engineer's responsibility) in case something goes wrong. This is also 
important in cases of "cloning" the server where we want a copy of the 
config but we need to change a few settings in the new context. We need 
to avoid things like "checksum error"!

Finally, there might be cases where - after having migrated and worked 
for a period using cn=config - business/technical needs require the use 
of overlay(s) or other modules like SLAPI, which would not be supported 
by cn=config and someone would need to move to slapd.conf configuration 
(at least temporarily). If such a need arises,
*Question 4*:
Is there a tool/method to "migrate" to slapd.conf from a slapd.d 
configuration?

Thanks in advance,
Nick