[Date Prev][Date Next] [Chronological] [Thread] [Top]

Securing cn=config and allowing micro-engineering



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