Re: Handling bad cn=config updates

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

Howard Chu writes:
> The Modify operation has already completed though, there's nothing to
> "return" an error message to by then.

I see.

> We do as much pre-checking as possible to validate the syntax of changes
> before committing them. But here you've got an input with perfectly valid
> syntax. The only way to know that it's bad is to commit the change.
>
> We already undo bad changes when we can detect them...

That's good, but that also means that a success response doesn't
indicate that the change was made to cn=config.

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


How can a program currently wait for a cn=config change to take effect?
Just loop and read the directory, waiting for either an expected visible
change or for the cn=config change to disappear (if it gets undone)?

> For this particular case, ITS#4829 needs to be considered as
> well. What is the definition of a "broken directory"? If you specify a
> directory that doesn't exist, the backend ought to just create it and
> use it. In that case, you'll end up with an empty context in the
> server. That might be what was intended, and also might not be; we
> have no way to tell. Therefore there is no sensible pre-check that we
> can perform.

"Slapd does not want to try to guess what you want to happen" seems a
sensible enough error to check for.

Beyond that, I guess we need some way to tell slapd what we want to
happen.  A control, or an attribute sent as part of the entry over the
protocol but which is not written to cn=config.  (I expect this is
getting into an old discussion, but I'm not going to look that up now.)


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.

-- 
Hallvard