[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Best Practices for configuration management with cn=config?

--On Friday, February 03, 2012 1:57 PM -0500 "Charles T. Brooks" <brooksct@hbcs.org> wrote: 


Quanah, could you elaborate at little on this comment?


The cn=config method IS a database, not a set of flat text files.
Modifications to the configuration are immediate with the exception of
changes to olcSecurity.


I'm just starting to convert a heavily replicated environment to
cn=config, and I (apparently stupidly) thought that slapd.d was a live
database.  Is the cn=config database held by sleepycat then, mixed up
with my user and system data in /var/lib/ldap?  Or is it in memory only?
cn=config is indeed a live database, so thinking that is in no way stupid ;). My point was, that you cannot just go and edit the cn=config database with something like 'vi'. The correct method is to use something like ldapmodify, etc. 


Also, the olcSecurity exception - why aren't changes to security also
immediate?
Because it requires restarting slapd to take effect, due to the way in which it affects the connection handler. AFAIK, this is the only exception. Security changes to acls (such as SSF lines) are immediate. 


I'll appreciate any insights you can share - I prefer slapd.conf
personally, but I want to proceed in the direction the code authors
favor, since they almost certainly have a clearer vision of what's
optimal for the future of the software than I do.

Currently I make changes by shutting down slapd, deleting slapd.d,
rebuilding slapd.d from my slapd.conf with slaptest, and restarting
slapd.  Works for me right now, but I hope to progress past it.
That definitely is not the correct approach. You should just be using ldapmodify or similar to update the cn=config db. ;) 

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration