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.