Re: Handling bad cn=config updates

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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?  Expanding on that a bit:

[Copying from an earlier message]

Howard Chu wrote:
>Hallvard B Furuseth wrote:
>> BTW, unless I've missed something the doc says very little about how
>> back-config itself works.  Mostly the slapd-config(5) and the config
>> parts of the admin guide describe the _contents_ of cn=config.
>
> 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.)


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

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.)

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

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.)

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.)

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.

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

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.

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.

-- 
Hallvard