Re: Handling bad cn=config updates
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