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

Re: Handling bad cn=config updates

Hallvard B Furuseth wrote:
Howard Chu wrote:
Hallvard B Furuseth wrote: 
So let me step back a bit: I'd like slapd to send the ModifyResponse
_after_ the change has taken effect (or failed to take effect).

That's actually the way it has been implemented. Just that in this
case, we weren't validating the olcDbDirectory argument before trying
to use it. This is now being done in HEAD.


Great.

As for bad changes shutting down the server - that was also a
conscious decision; the kinds of errors that can cause this failure
are presumably the type that we cannot rollback and recover from.


I presume you mean badness that is discovered too late to be able to
reject or undo during the cn=config update request?  If so, fair enough.
Though that's one thing which needs some documentation - how careful
should one be with cn=config changes?

That seems like a pretty silly question. cn=config is so potentially dangerous that in OpenLDAP 2.3 we restricted it to only be usable by its rootDN. How careful should one be - you can never afford to be careless.

For the most part, internal implementation details never get
documented. Only developers need to know, and they can just read the
code.


No, we are talking about user-visible effects here, even if the
explanation dives into the internals.

Here are some things it would be useful for the manpage to answer.
(Note, I'm listing questions, not asking them.  I'm in no hurry at
the moment, I know some answers wonder about otheres.)


OK, so the following is stuff to send in Gavin's direction... ;)

Are there any config options specific to back-config?  Does it honor
access controls?  (No .SH CONFIGURATION nor ACCESS CONTROL section.)

No, yes. back-config would be unusable if it had any backend-specific options. The chicken'n'egg problem would be unresolvable.

Are changes atomic as seen by clients, i.e. they won't see the affected
database or whatever in a temporary state when the config change is in
progress?  (Like I wondered with moving olcDbDirectory, for example.)


That's implicit to LDAP, doesn't bear further mention.

Do changes that succeed take effect immediately (unless otherwise
stated)?  How are operations that are already progress affected?

The former doesn't bear mention, it is already advertised as such. (E.g. the Admin Guide:
The LDAP configuration engine allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect.

There are never any other operations in progress when changes take effect in cn=config.

In a number of cases, it'll break the database to edit slapd.conf and
restart slapd.  To what degree are the same changes safe to try with
cn=config (either because it'll handle it or the modify operation will
return failure)?  E.g. adding an index works.  How about changing
olcIndexSubstrAnyLen?  Removing olcAttributeOptions or object classes
that are is in use in the database?  Removing an unused attribute
allowed by some objectClass?  (I know these could be documented under
the individual options' docs, but a general guideline would be good.
Might fit best in the EXAMPLES section, depends on how firm principles
are involved.)

Changing the olcIndexSubstr parameters will require a full re-run of slapindex. Removing attributes and objectclasses will not impair the currently running server, although it may cause problems on a subsequent restart. (Deleting schema elements at runtime only makes them inaccessible to users; their definitions remain in memory because there may still be active references to them at runtime. Any attempt to create new references to them will of course fail.)

Related, could use an indication of how "magical" cn=config changes are.
Like my open/close database question, or modify olcLogFile to contain
its current value after rotating the file to make it open and close
that, etc.  (Haven't tried.  Point is, there are a _lot_ of things like
that to try out, it'd be useful to have a general feel for how much to
expect.)

I guess someone will have to walk thru them all and try them out. The intent for cn=config was for everything to Just Work, so we should only need to document where limitations exist. (E.g., olcIndexSubstr*)

If I've broken my configuration so slapd won't start, and want to fix it
instead of starting from scratch, what to do?  Just edit the cn=config
LDIFs, or is there some extra magic to look out for?  The manpage
doesn't even mention that the config is stored in an LDIF database,
which might be going a bit far in the "don't document internals"
direction.

OK. The cn=config design actually has very few dependencies on the underlying backend, but it currently uses back-ldif for two main reasons - back-ldif has only one relevant config directive (olcDbDirectory) and its storage format is human readable. Is it safe to assume that no other backend offers this simplicity and we will therefore never change it? I believe so, so it's fair to at least mention that back-config uses back-ldif.

What are those {x} "indexes" in DNs and attributes? 

Already documented in the Admin Guide.

Security issues: Remind users that since an attacker can make slapd
perform various OS and filesystem actions as well as access the LDAP
databases.  So remember to restrict cn=config access tightly, and it
gets more important not to run slapd as root.


Right.

Some but all attributes get defaulted when created from slapd.conf, so
presumably changing the default later in the frontend won't affect them.
Yet at least in the case of olcReadOnly, I could delete the attribute
with ldapmodify.  So why does it get defaulted, what's going on?
slapd-config(5) says:
    GLOBAL DATABASE OPTIONS
    Options in this section may be set in the special "frontend"
    database and inherited in all the other databases.  These options
    may be altered by further settings in each specific database. (...)
That doesn't look quite true, maybe some get copied from the frontend
upon database creation and others inherit at runtime, I don't know.

I guess that description was only true for slapd.conf and initial startup. Changes to the frontend made at runtime don't get propagated to all other databases. I wonder if they should. Probably one would expect changes to the frontend/global ACLs to take effect for all other backends.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/