Hallvard B Furuseth wrote:
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?
That seems like a pretty silly question. cn=config is so potentially dangerous that in OpenLDAP 2.3 we restricted it to only be usable by its rootDN. How careful should one be - you can never afford to be careless.
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.)
OK, so the following is stuff to send in Gavin's direction... ;)
Are there any config options specific to back-config? Does it honor access controls? (No .SH CONFIGURATION nor ACCESS CONTROL section.)
No, yes. back-config would be unusable if it had any backend-specific options. The chicken'n'egg problem would be unresolvable.
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.)
That's implicit to LDAP, doesn't bear further mention.
Do changes that succeed take effect immediately (unless otherwise stated)? How are operations that are already progress affected?
The former doesn't bear mention, it is already advertised as such. (E.g. the Admin Guide: The LDAP configuration engine allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect.
There are never any other operations in progress when changes take effect in cn=config.
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.)
Changing the olcIndexSubstr parameters will require a full re-run of slapindex. Removing attributes and objectclasses will not impair the currently running server, although it may cause problems on a subsequent restart. (Deleting schema elements at runtime only makes them inaccessible to users; their definitions remain in memory because there may still be active references to them at runtime. Any attempt to create new references to them will of course fail.)
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.)
I guess someone will have to walk thru them all and try them out. The intent for cn=config was for everything to Just Work, so we should only need to document where limitations exist. (E.g., olcIndexSubstr*)
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.
OK. The cn=config design actually has very few dependencies on the underlying backend, but it currently uses back-ldif for two main reasons - back-ldif has only one relevant config directive (olcDbDirectory) and its storage format is human readable. Is it safe to assume that no other backend offers this simplicity and we will therefore never change it? I believe so, so it's fair to at least mention that back-config uses back-ldif.
What are those {x} "indexes" in DNs and attributes?
Already documented in the Admin Guide.
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.
Right.
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.
I guess that description was only true for slapd.conf and initial startup. Changes to the frontend made at runtime don't get propagated to all other databases. I wonder if they should. Probably one would expect changes to the frontend/global ACLs to take effect for all other backends.