[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Securing cn=config and allowing micro-engineering
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: 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"!
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/