--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
We use puppet here... for openldap, it's ONLY useful for initial config. For modifications of openldap config, there's no mechanism to enable that, and any mechanism that DID exist would have to be aware of the current state.
- chris
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah Gibson-Mount Sent: Friday, February 03, 2012 11:01 AM To: Charles T. Brooks Cc: openldap-technical Subject: 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
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
--On Friday, February 03, 2012 12:27 PM -0700 Chris Jacobs Chris.Jacobs@apollogrp.edu wrote:
We use puppet here... for openldap, it's ONLY useful for initial config. For modifications of openldap config, there's no mechanism to enable that, and any mechanism that DID exist would have to be aware of the current state.
@ Zimbra we wrote our own state engine that queries the current cn=config values, and compares them to a set of variables that user can modify. If they differ, it updates cn=config to match the user variables. We don't use puppet at all however.
--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
Quanah Gibson-Mount wrote:
--On Friday, February 03, 2012 12:27 PM -0700 Chris Jacobs Chris.Jacobs@apollogrp.edu wrote:
We use puppet here... for openldap, it's ONLY useful for initial config. For modifications of openldap config, there's no mechanism to enable that, and any mechanism that DID exist would have to be aware of the current state.
@ Zimbra we wrote our own state engine that queries the current cn=config values, and compares them to a set of variables that user can modify. If they differ, it updates cn=config to match the user variables. We don't use puppet at all however.
And where is the "set of variables that user can modify" stored?
Ciao,Michael.
--On Friday, February 03, 2012 9:14 PM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Friday, February 03, 2012 12:27 PM -0700 Chris Jacobs Chris.Jacobs@apollogrp.edu wrote:
We use puppet here... for openldap, it's ONLY useful for initial config. For modifications of openldap config, there's no mechanism to enable that, and any mechanism that DID exist would have to be aware of the current state.
@ Zimbra we wrote our own state engine that queries the current cn=config values, and compares them to a set of variables that user can modify. If they differ, it updates cn=config to match the user variables. We don't use puppet at all however.
And where is the "set of variables that user can modify" stored?
In a utility local to the system. Most end clients do not know or understand how to modify LDAP or any number of the software programs shipped with Zimbra, so it allows them the ability to configure LDAP, Postfix, etc, in a simple way.
--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
openldap-technical@openldap.org
-
Chris Jacobs -
Michael Ströder -
Quanah Gibson-Mount