Howard Chu writes:
Hallvard B Furuseth wrote:
(...) 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.
Well, yes, but it's not currently well enough documented to say that, unless the recommendation for now is to not try anything creative which isn't documented.
[Skipping the "OK, good" parts]
(...) OK, so the following is stuff to send in Gavin's direction... ;) (...)
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.
Yes, for two reasons. First, it would conform to the LDAP spec if a change to the cn=config LDAP data is atomic but the effect on slapd happens gradually. E.g. existing connections might be immune from a tightened olcIdleTimeout, olcTLSCipherSuite or BDB olcDbSearchStack.
Second, OpenLDAP does break the LDAP spec on occation. Sometimes blatantly like with "userPassword: {hash method}...". Someitmes when interaction between various modules gets too hairy. And cn=config is just about the hairiest of all. It'd be unsurprising to see slapd need time to adjust to some changes it handles at run-time. (Changes due to restart are of course seen as atomic:-)
Do changes that succeed take effect immediately (unless otherwise stated)? (...)
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.
That doesn't say "immediately", in particular as in "by the time the operation has returned success to the client". Like the change which started this thread, and my olcIdleTimeout example above.
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.
And check the code, in case something works just accidentally or only in cases when it's easy for slapd to do (again like the change which started this thread).
The intent for cn=config was for everything to Just Work, so we should only need to document where limitations exist. (E.g., olcIndexSubstr*)
That's great. And that's the statement I was asking for this time, instead of the details of each individual attribute. Follow it with the advice (above) not to try anything unless documented, and together they'll give a good feel for how to use back-config.
Perhaps the doc should mark[*] all attrs for which it Just Works, or for which it doesn't always Just Work.