--On Friday, September 15, 2017 12:49 AM +0200 Michael Ströder michael@stroeder.com wrote:
Personally I strongly prefer static configuration because it's so much easier to control it with the usual idempotent config management techniques (puppet, ansible, etc.) which you need for the rest of the system anyway.
Those are all systems designed to manage flat file configurations. cn=config is not a flat file configuration, so it makes sense they're fairly useless when confronted with a concept that's significantly more forward thinking.
I'd even state that it's a strong plus of OpenLDAP compared to other LDAP server implementations to still provide this configuration method.
I think it's a strong plus to be able to reconfigure a standalone server into an MMR cluster with zero downtime, along with other critical configuration bits, such as deploying new schema, additional overlays, etc. Being able to fully automate deployments w/o requiring restarts was an exceptional win for me.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
I think it's a strong plus to be able to reconfigure a standalone server into an MMR cluster with zero downtime,
I don't buy this argument. If you're really eager reaching high availability you have to implement a decent load-balancer and test correct fail-over anyway. And then your MMR cluster will have zero down-time (seen from the LDAP clients) during re-configuration even when restarting the replicas one after another.
Ciao, Michael.
On Fri, Sep 15 2017 at 09:09:19 +0200, Michael Ströder scribbled in "Re: Olc deployment vs slapd.conf based deployment":
Quanah Gibson-Mount wrote:
I think it's a strong plus to be able to reconfigure a standalone server into an MMR cluster with zero downtime,
I don't buy this argument. If you're really eager reaching high availability you have to implement a decent load-balancer and test correct fail-over anyway. And then your MMR cluster will have zero down-time (seen from the LDAP clients) during re-configuration even when restarting the replicas one after another.
Ciao, Michael.
I'm rather split between the two configuration options, but I agree that Quanah's example is not the best -- it's not the type of operation that is likely to be done regularly enough to make it important in the greater scheme of things.
I really do like the idea of being able to tweak and update the configuration without needing to HUP slapd (it's a shame there's no "reload" option, in addition to "restart"), especially for things like updating ACLs that are usually considered trivial/standard changes.
That said, I'm also a really big fan of plain text configuration files, centrally managed in a version controlled repository, and pushed/pulled around to systems as needs be. We use this mechanism for _all_ of our infrastructure estate and knowing that I can make a change _in_one_place_, and roll it out to "N" slapd hosts simply, really does help me sleep at night.
Compared to that, having to run ldapadd/ldapmodify on all those hosts is an awkward proposition.
What's missing, before we can seriously consider using slapd-config for production environments, is an administrative interface that fills the gap between the two configuration styles. We're far from being opposed to writing our own tools (much of our infrastructure management tooling is bespoke, just like any workplace with a hint of complexity) and indeed, looking at how to best integrate slapd-config based configurations is on my todo list for when our shipment of round tuits is delivered.
That said, I can't help thinking, however, that it would be more approachable to newcomers if, ideally, there was some functionality to assist environments like ours, without having to write it all in house.
Stating that slapd-config is not a flat-file system is a little unfair too, given that it's on disk in LDIF format (even if it should left alone). Our config management system can build LDIF using templating (can't they all?), the issue is running a diff against that, and the running cn=config, and applying the changes cleanly, idempotently, and atomically -- is there anything that will fill the pre-flight `slaptest` role when support for slapd.conf is removed?
Cheers.
Dameon.
Dameon Wagner wrote:
I really do like the idea of being able to tweak and update the configuration without needing to HUP slapd (it's a shame there's no "reload" option, in addition to "restart"),
SIGHUP is "reload". You probably refer to "restart=stop/start".
especially for things like updating ACLs that are usually considered trivial/standard changes.
In my setups ACLs changes are most times not trivial. They need a decent change management with staging and integration tests anyway.
Compared to that, having to run ldapadd/ldapmodify on all those hosts is an awkward proposition.
But that's the only way to change cn=config without stopping slapd.
Stating that slapd-config is not a flat-file system is a little unfair too, given that it's on disk in LDIF format (even if it should left alone). Our config management system can build LDIF using templating (can't they all?), the issue is running a diff against that, and the running cn=config, and applying the changes cleanly, idempotently, and atomically -- is there anything that will fill the pre-flight `slaptest` role when support for slapd.conf is removed?
1. You have to stop slapd to directly change LDIF files of cn=config.
2. According to OpenLDAP developers you must not tweak the LDIF files directly because they have checksums. The recommended way of dealing making LDIF changes to cn=config is to 1. slapcat -b cn=config, 2. make changes to LDIF, 3. stop slapd and 4. to re-import LDIF.
Note that if the config is broken for whatever reason step 1. will not work anymore leading to an operational dead-end.
3. Change config of running server is only possible via LDAP. I already though about writing an ansible module doing the idempotent diffs via LDAP. But the hard part is a roll-back or removing parts since back-config does not support delete operations in 2.4.x. IMO it's not worth the effort, also because one would have to keep a complete representation of cn=config as static file anway.
Ciao, Michael.
On Fri, Sep 15 2017 at 11:22:44 +0200, Michael Ströder scribbled in "Re: Olc deployment vs slapd.conf based deployment":
Dameon Wagner wrote:
I really do like the idea of being able to tweak and update the configuration without needing to HUP slapd (it's a shame there's no "reload" option, in addition to "restart"),
SIGHUP is "reload". You probably refer to "restart=stop/start".
Yes, sorry about that -- my use of HUP is bad slang for giving a process some form of kick.
I think we're on the same side as far as "slapd.conf vs. cn=config", I just didn't make it as clear as I could this morning...
especially for things like updating ACLs that are usually considered trivial/standard changes.
In my setups ACLs changes are most times not trivial. They need a decent change management with staging and integration tests anyway.
Maybe trivial wasn't the best word to use. Our ACL changes are also complex, and require testing. The context was more in relation to configuration changes such as changing the backend (definitely non trivial, and would clearly require stop/start, and lots of other work in between). In that context an ACL change is, or can be, (relatively) simple to affect, even if the ACL itself is quite complex.
<SNIP>
I already though about writing an ansible module doing the idempotent diffs via LDAP. But the hard part is a roll-back or removing parts since back-config does not support delete operations in 2.4.x. IMO it's not worth the effort, also because one would have to keep a complete representation of cn=config as static file anway.
Ciao, Michael.
I completely agree. I really hope that if/when slapd.conf support is removed there's already some form of "conventional" configuration management integration available.
Plain text config files are just so much easier to work with when you have an environment worthy of configuration management -- I'll leave the answer of what a "worthy environment" is unsaid, it's a common interview question :)
Cheers.
Dameon.
On Fri, Sep 15, 2017 at 10:55:10AM +0100, Dameon Wagner wrote:
On Fri, Sep 15 2017 at 11:22:44 +0200, Michael Ströder scribbled
I already though about writing an ansible module doing the idempotent diffs via LDAP. But the hard part is a roll-back or removing parts since back-config does not support delete operations in 2.4.x. IMO it's not worth the effort, also because one would have to keep a complete representation of cn=config as static file anway.
I completely agree. I really hope that if/when slapd.conf support is removed there's already some form of "conventional" configuration management integration available.
cn=config delete support exists in master, as well as slapmodify tools that work on cn=config and, with a tiny nudge (cn=config suffix itself is reserved for back-config), the underlying ldif database if you really do get into a bind. And slaptest works with cn=config just fine already. All that will have been firmly in place by the time slapd.conf is removed.
What you really need is ldif diff tools and you might have luck perusing the OpenLDAP source tree or elsewhere (ldapvi?).
I know LDAP TXN support for cn=config might be just what you'd see as the silver bullet but I don't see that happening, not yet, sorry.
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
In my opinion the most important, hard to attack, and even harder (impossible?) to disprove argument is: Transparency!
Call it strange, useless, insane, fine or whatever, but my customers (also anybody who's interested in using a distinct service) should be able to get a chance for a detailed view into the running configuration of each service - before and while using it. slapd's cn=config supports this, not perfectly but better than any other service I'm aware of. For further details see our paper from LDAPcon2011.
I don't understand the yearly, redundant, and just time consuming discussions regaring slapd.conf vs. cn=config.
cn=config represents, as Quanah said: "forward thinking". +1
So, please think about it.
On 15.09.2017 09:09, Michael Ströder wrote:
Quanah Gibson-Mount wrote:
I think it's a strong plus to be able to reconfigure a standalone server into an MMR cluster with zero downtime,
I don't buy this argument. If you're really eager reaching high availability you have to implement a decent load-balancer and test correct fail-over anyway. And then your MMR cluster will have zero down-time (seen from the LDAP clients) during re-configuration even when restarting the replicas one after another.
Ciao, Michael.
Daniel Pluta wrote:
Call it strange, useless, insane, fine or whatever, but my customers (also anybody who's interested in using a distinct service) should be able to get a chance for a detailed view into the running configuration of each service - before and while using it. slapd's cn=config supports this, not perfectly but better than any other service I'm aware of. For further details see our paper from LDAPcon2011.
I very well remember your interesting talk and that you give read access to olcRootDN to prove it's not set.
While I use old slapd.conf everywhere I also configure back-config on all of my system but just for read access (e.g. for monitoring agents).
I don't understand the yearly, redundant, and just time consuming discussions regaring slapd.conf vs. cn=config.
cn=config represents, as Quanah said: "forward thinking". +1
"Forward thinking" is never a sufficient argument in itself.
So, please think about it.
Dito.
Ciao, Michael.
On 16.09.2017 09:04, Michael Ströder wrote:
Daniel Pluta wrote:
Call it strange, useless, insane, fine or whatever, but my customers (also anybody who's interested in using a distinct service) should be able to get a chance for a detailed view into the running configuration of each service - before and while using it. slapd's cn=config supports this, not perfectly but better than any other service I'm aware of. For further details see our paper from LDAPcon2011.
I very well remember your interesting talk and that you give read access to olcRootDN to prove it's not set.
It was olcRootPw: to prove that it's not present and thus there is no slapd-BOFH (aka administrative man-in-the-middle).
I very well remember the shocked/laughing faces of (parts of) the audience right after I switched to the slide containing this at first surely suicidal seeming ACL.
Forget about it. It's sufficient to keep in mind that the future lies in cn=config. ;-)
Daniel Pluta wrote:
Forget about it. It's sufficient to keep in mind that the future lies in cn=config. ;-)
History provides enough examples where simple modernism resulted in dead-ends or even worse things.
Ciao, Michael.
On Sat, Sep 16, 2017 at 04:24:36PM +0200, Daniel Pluta wrote:
On 16.09.2017 09:04, Michael Str??der wrote:
Daniel Pluta wrote:
Call it strange, useless, insane, fine or whatever, but my customers (also anybody who's interested in using a distinct service) should be able to get a chance for a detailed view into the running configuration of each service - before and while using it. slapd's cn=config supports this, not perfectly but better than any other service I'm aware of. For further details see our paper from LDAPcon2011.
I'm jumping in late here. I'm curious about this talk. I see a YouTube playlist of LDAPCon 2011 talkshere; which one should I look at for these details?
https://www.youtube.com/playlist?list=PLXuMrj-t1hqGdOJvswPFvNtwZFHD5SODK
I very well remember your interesting talk and that you give read access to olcRootDN to prove it's not set.
It was olcRootPw: to prove that it's not present and thus there is no slapd-BOFH (aka administrative man-in-the-middle).
I very well remember the shocked/laughing faces of (parts of) the audience right after I switched to the slide containing this at first surely suicidal seeming ACL.
Forget about it. It's sufficient to keep in mind that the future lies in cn=config. ;-)
Am Mon, 18 Sep 2017 10:12:23 -0400 schrieb Brian Reichert reichert@numachi.com:
On Sat, Sep 16, 2017 at 04:24:36PM +0200, Daniel Pluta wrote:
On 16.09.2017 09:04, Michael Str??der wrote:
Daniel Pluta wrote:
Call it strange, useless, insane, fine or whatever, but my customers (also anybody who's interested in using a distinct service) should be able to get a chance for a detailed view into the running configuration of each service - before and while using it. slapd's cn=config supports this, not perfectly but better than any other service I'm aware of. For further details see our paper from LDAPcon2011.
I'm jumping in late here. I'm curious about this talk. I see a YouTube playlist of LDAPCon 2011 talkshere; which one should I look at for these details?
There is no video, but you may read the papers. https://ldapcon.org/2011/downloads/plutahommelweinert-paper.pdf
[...]
https://www.youtube.com/playlist?list=PLXuMrj-t1hqGdOJvswPFvNtwZFHD5SODK
I very well remember your interesting talk and that you give read access to olcRootDN to prove it's not set.
It was olcRootPw: to prove that it's not present and thus there is no slapd-BOFH (aka administrative man-in-the-middle).
I very well remember the shocked/laughing faces of (parts of) the audience right after I switched to the slide containing this at first surely suicidal seeming ACL.
Forget about it. It's sufficient to keep in mind that the future lies in cn=config. ;-)
-Dieter
openldap-technical@openldap.org
-
Brian Reichert -
Dameon Wagner -
Daniel Pluta -
Dieter Klünter -
Michael Ströder -
Ondřej Kuzník -
Quanah Gibson-Mount