Hello everyone,
Are there any best practices for backing up ldap configuration? Our current approach is to run a nightly diff on the output of "slapcat -l -b cn=config' and if it has changed, the new ldif is comitted to svn.
Ideally, I'd like to just add the slapd.d directory to svn, and everytime it changes I'd checkin the new version. But I have a feeling that the ".svn" directories that will be created are going to cause trouble.
Is there better way of doing this?
Thanks, -- Khosrow
Khosrow Ebrahimpour wrote:
Ideally, I'd like to just add the slapd.d directory to svn, and everytime it changes I'd checkin the new version. But I have a feeling that the ".svn" directories that will be created are going to cause trouble.
Well, if you're already using a VCS why not just use static configuration files.
Ciao, Michael.
On Thu, Dec 13, 2012 at 3:25 PM, Michael Ströder michael@stroeder.comwrote:
Well, if you're already using a VCS why not just use static configuration files.
Ciao, Michael.
One reason against using static configuration is that the server needs to be stopped and started when making a simple ACL change. This becomes operationally cumbersome. Another is that slapd.conf is deprecated and may not be supported in future OpenLDAP releases.
cheers,
Ven
Venkat wrote:
On Thu, Dec 13, 2012 at 3:25 PM, Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote: Well, if you're already using a VCS why not just use static configuration files.
One reason against using static configuration is that the server needs to be stopped and started when making a simple ACL change.
If HA is really important I guess one has a load-balancer in front of several replicas. So restarting one after another results in zero downtime seen from the clients.
Personally I still prefer to use static configuration and fully automated installation/configuration (with puppet manifests pulled from SVN). That's really easy with text files compared to dealing with dynamic configuration.
Ciao, Michael.
On December 14, 2012 09:26:10 AM Michael Ströder wrote:
Venkat wrote:
On Thu, Dec 13, 2012 at 3:25 PM, Michael Ströder <michael@stroeder.com
mailto:michael@stroeder.com> wrote: Well, if you're already using a VCS why not just use static configuration files.
One reason against using static configuration is that the server needs to be stopped and started when making a simple ACL change.
If HA is really important I guess one has a load-balancer in front of several replicas. So restarting one after another results in zero downtime seen from the clients.
We do run a cluster of several replicas, but I'm still a fan of having a central repository of configuration not to mention a nice timeline of all the changes made on the configuration.
Personally I still prefer to use static configuration and fully automated installation/configuration (with puppet manifests pulled from SVN). That's really easy with text files compared to dealing with dynamic configuration.
I've seen this issue debated on this list many times, and although there are some who like the ease of use of a slapd.conf, it is deprecated and who knows if support for it will be dropped at some point or not.
Khosrow Ebrahimpour wrote:
but I'm still a fan of having a central repository of configuration not to mention a nice timeline of all the changes made on the configuration.
That's what SVN/puppet is for in my current project which generates static configuration files for all the nodes based on templates. We can specify as many MMR replica instances as needed and use the same Puppet manifests for MMR setups in different stages.
And that works *much* better than tracking changes to back-config because it is easier to automate configuration without an "internal" state change in a DB.
Personally I still prefer to use static configuration and fully automated installation/configuration (with puppet manifests pulled from SVN). That's really easy with text files compared to dealing with dynamic configuration.
I've seen this issue debated on this list many times, and although there are some who like the ease of use of a slapd.conf, it is deprecated and who knows if support for it will be dropped at some point or not.
IIRC the static configuration will be dropped not before 2.5.x is out.
Ciao, Michael.
Hi,
just an unfinished thought, but one important point seems to be that it's not easily possible to compare the current configuration state when using back-config with a defined config state stored in a configuration. Shouldn't ldapdiff (https://launchpad.net/ldapdiff) be able to do this (compare the state of cn=config with a known config state managed in a central repository)?
Yours Karsten
Karsten Heymann wrote:
just an unfinished thought, but one important point seems to be that it's not easily possible to compare the current configuration state when using back-config with a defined config state stored in a configuration. Shouldn't ldapdiff (https://launchpad.net/ldapdiff) be able to do this (compare the state of cn=config with a known config state managed in a central repository)?
I will write a decent ldapdiff within 15 min. myself. But reliably applying the config is the real problem if you think it to the end. And basically you'll end up doing the very same like maintaining a static configuration file.
The possibility of static configuration (with comments) is a big plus of OpenLDAP compared to other LDAP servers.
Ciao, Michael.
On December 14, 2012 07:06:13 PM Michael Ströder wrote:
That's what SVN/puppet is for in my current project which generates static configuration files for all the nodes based on templates. We can specify as many MMR replica instances as needed and use the same Puppet manifests for MMR setups in different stages.
And that works *much* better than tracking changes to back-config because it is easier to automate configuration without an "internal" state change in a DB.
But managing back-config using any config management tool remains an issue. I don't think I can just push the entire slapd.d directory using chef or puppet. That's why I thought of tracking the changes.
Having said all that I do agree with you that using a static configuration is better suited for this kind of thing.
IIRC the static configuration will be dropped not before 2.5.x is out.
That's good to know, though we are entirely on back-config now.
I found something interesting as well. Openldap seems to ignore dotfiles in slapd.d directory. This can help avoid having to check for config changes using a script and I can simply commit the entire slapd.d to my VCS.
-- Khosrow
Khosrow Ebrahimpour wrote:
On December 14, 2012 07:06:13 PM Michael Ströder wrote:
That's what SVN/puppet is for in my current project which generates static configuration files for all the nodes based on templates. We can specify as many MMR replica instances as needed and use the same Puppet manifests for MMR setups in different stages.
And that works *much* better than tracking changes to back-config because it is easier to automate configuration without an "internal" state change in a DB.
But managing back-config using any config management tool remains an issue. I don't think I can just push the entire slapd.d directory using chef or puppet.
Of course not. slapd.d is a slapd-internal private database. if you're doing any manipulation of its contents "You're Doing It Wrong."
Use slapcat -n0 / slapadd -n0. As Documented.
That's why I thought of tracking the changes.
Having said all that I do agree with you that using a static configuration is better suited for this kind of thing.
IIRC the static configuration will be dropped not before 2.5.x is out.
That's good to know, though we are entirely on back-config now.
I found something interesting as well. Openldap seems to ignore dotfiles in slapd.d directory. This can help avoid having to check for config changes using a script and I can simply commit the entire slapd.d to my VCS.
No. *Never* do anything with the files in slapd.d. Use the slapd management tools.
On December 14, 2012 10:47:29 PM Howard Chu wrote:
Khosrow Ebrahimpour wrote:
But managing back-config using any config management tool remains an issue. I don't think I can just push the entire slapd.d directory using chef or puppet.
Of course not. slapd.d is a slapd-internal private database. if you're doing any manipulation of its contents "You're Doing It Wrong."
Use slapcat -n0 / slapadd -n0. As Documented.
I think the thread got derailed a bit. I don't care about the static slapd.conf vs slapd.d debate. We're using back-config the "proper" way as far as I can tell.
My original question was to find out if anyone was managing their openldap configuration. We have a crude way using a VCS, but was wondering if others had a better way.
Having said that, I appreciate all the input so far.
-- Khosrow
Khosrow Ebrahimpour wrote:
On December 14, 2012 09:26:10 AM Michael Ströder wrote:
Venkat wrote:
On Thu, Dec 13, 2012 at 3:25 PM, Michael Ströder <michael@stroeder.com
mailto:michael@stroeder.com> wrote: Well, if you're already using a VCS why not just use static configuration files.
One reason against using static configuration is that the server needs to be stopped and started when making a simple ACL change.
If HA is really important I guess one has a load-balancer in front of several replicas. So restarting one after another results in zero downtime seen from the clients.
We do run a cluster of several replicas, but I'm still a fan of having a central repository of configuration not to mention a nice timeline of all the changes made on the configuration.
Personally I still prefer to use static configuration and fully automated installation/configuration (with puppet manifests pulled from SVN). That's really easy with text files compared to dealing with dynamic configuration.
I've seen this issue debated on this list many times, and although there are some who like the ease of use of a slapd.conf, it is deprecated and who knows if support for it will be dropped at some point or not.
Yes, this has been debated many times, and the debate is just as stupid and pointless today as it was the first N times.
If your tools can only deal with static config files, fine. Use "slapcat -n0" and go your merry way. The cn=config functionality is a total superset of the static config file. Anyone who thinks the existence of cn=config in any way limits their freedom of operation is just being ignorant.
In life there are many things that are a matter of opinion and open to debate. This is not one of them. It's cut and dry. Get over it, move on.
Le 15/12/2012 07:42, Howard Chu a écrit :
Yes, this has been debated many times, and the debate is just as stupid and pointless today as it was the first N times.
If your tools can only deal with static config files, fine. Use "slapcat -n0" and go your merry way. The cn=config functionality is a total superset of the static config file. Anyone who thinks the existence of cn=config in any way limits their freedom of operation is just being ignorant.
I don't think anyone is angry about the existence of cn=config, but rather about the potential removal of static configuration file support in an undefined future, as advertised in many places. And I don't think either anyone is convinced there is something you can't do with cn=config, rather than it just doesn't integrate with existing workflows. I'd personnaly add it's also more difficult to document and to understand, just see the various examples in the openldap manuel.
It would be more convincing to argue about the cost of maintaining two different configuration parsers rather than denying adverse position arguments.
On 14/12/12 00:24, Venkat wrote:
Another is that slapd.conf is deprecated and may not be supported in future OpenLDAP releases.
I would very much be against this.
An acceptable solution would be to include a *reliable* utility for conversion from (and possibly back to) a single slapd.conf file.
Reason:
Modular config suits some things - it works very well with Apache. Some people lik eit with exim, others including me hate it as it makes it really *hard* to scan over the whole config.
And in both cases, the way the config is modularised is under user control as it's all based on Include-ing other sections manually so one can structure it to suit the site.
Modular config can be a PITA with config management systems too.
openldap-technical@openldap.org
-
Guillaume Rousse -
Howard Chu -
Karsten Heymann -
Khosrow Ebrahimpour -
Michael Ströder -
Tim Watts -
Venkat