Re: Handling bad cn=config updates

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

-- 
Regards,
Hallvard