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.