Nick Milas wrote:
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)
Not intentionally. Some errors could lead to an assert() failing, which would cause slapd to stop.
Zytrax.com is not a reliable source of OpenLDAP documentation. Most of what they advise is misguided or flat wrong.
2/ LDAP Server will continue to operate but, if stopped, when restarted it will not be able to restart?
This has been known to happen a few times in the past due to bugs in the config code. In general, no.
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)?
Where do you get this "knowledge"? From Zytrax? slaptest tests "the server configuration" - it doesn't matter whether it is in slapd.conf or slapd.d.
*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?
Manually editing slapd.d files is the surest way of causing a problem that prevents slapd from restarting.
(In one such test I did, I changed - directly in "cn=config.ldif" file - olcLogLevel as follows: Initial state:
olcLogLevel: Config olcLogLevel: SyncNew state (removed one attribute value and changed the other):
olcLogLevel: -1and 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"!
It is always desirable to not make a mistake that blows your foot off (or ankle or leg, for that matter).
In this case, that means ensuring that any changes you want to make are checked for syntax and other such constraints, so that you're not stuck with a non-working config.
Obvious approach: slapcat -n0 -F old/slapd.d > config.ldif edit config.ldif slapadd -n0 -F new/slapd.d -l config.ldif test using new/slapd.d deploy...
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?
Ask your buddies at Zytrax, they seem to think so.
As far as the OpenLDAP Project is concerned, conversion from slapd.conf to slapd.d is a one-way trip. Migrate everything else forward.