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

Re: Securing cn=config and allowing micro-engineering

Nick Milas wrote:

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

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:

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
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: 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

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

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

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.

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/