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

Re: Olc deployment vs slapd.conf based deployment

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.

-- 
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Systems Development and Support
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><