[prev in list] [next in list] [prev in thread] [next in thread]
List: openldap-technical
Subject: Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
From: Christopher Paul <chris.paul () rexconsulting ! net>
Date: 2023-12-01 21:02:03
Message-ID: 782ee37d-71c7-45ce-8365-30e198e5b882 () rexconsulting ! net
[Download RAW message or body]
> On Thu, 30 Nov 2023 at 16:06, Bastian Tweddell
> <b.tweddell@fz-juelich.de> wrote:
>
>
> Please also note [1]:
> ```
> The older style slapd.conf(5) file is still supported, but its use is
> deprecated and support for it will be withdrawn in a future OpenLDAP
> release.
> ```
>
> Is this already on the roadmap when this will happen?
>
I really hope this never happens.
The one and only advantage I see to OLC is that you can make some
changes on the fly, without restarting the server. But is this ever
necessary, or even advisable in a production environment?
In production, people want LDAP servers to be perfectly stable and
reliable software-as-an-appliances. They will run 10 (even 20) years
this way.
Production configuration should be immutable. The configuration should
not need to change from day to day within production. And even when it
does, if clients are configured correctly, there is the ability to
restart individual servers without impacting the entire service.
As for sync'ing cn=config, I've tried it. I don't see the advantage of
it over having one configuration file (or maybe one each for providers
and another for consumers) and then deploying each from source control,
and controlled with file signature monitoring, for extra security.
You can have the best of both worlds by enabling the config database,
but not converting to it. This "converts" your slapd.conf into the
memory-based OLC which can be updated on the fly, but not persisted. To
me this is the ideal, but then even still, within many of theses setups,
I have never needed to use the OLC for on-the-fly-changes, so in
retrospect, do not see the necessity of this.
In summary, I see great value to continuing to support the slapd.conf
file-based config, especially for production, and I see a lot of risk
induced by deprecating it and forcing people to use OLC. OpenLDAP
project, would you please consider to not deprecate slapd.conf?
Chris Paul | Rex Consulting | https://www.rexconsulting.net
[Attachment #3 (text/html)]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<blockquote type="cite"
cite="mid:CAAGWQu-bbTpRRsQmrMtFCQJkVCJ=vicFN7Z+xYpjcksNCUnsTQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 30 Nov 2023 at
16:06, Bastian Tweddell <<a
href="mailto:b.tweddell@fz-juelich.de"
moz-do-not-send="true" \
class="moz-txt-link-freetext">b.tweddell@fz-juelich.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><br> Please also note [1]:<br>
```<br>
The older style slapd.conf(5) file is still supported, but
its use is <br>
deprecated and support for it will be withdrawn in a future
OpenLDAP <br>
release.<br>
```<br>
<br>
Is this already on the roadmap when this will happen?<br>
</blockquote>
</div>
</div>
</blockquote>
<p>I really hope this never happens.</p>
<p>The one and only advantage I see to OLC is that you can make some
changes on the fly, without restarting the server. But is this
ever necessary, or even advisable in a production environment?<br>
</p>
<p>In production, people want LDAP servers to be perfectly stable
and reliable software-as-an-appliances. They will run 10 (even 20)
years this way.<br>
</p>
<p>Production configuration should be immutable. The configuration
should not need to change from day to day within production. And
even when it does, if clients are configured correctly, there is
the ability to restart individual servers without impacting the
entire service.<br>
</p>
<p>As for sync'ing cn=config, I've tried it. I don't see the
advantage of it over having one configuration file (or maybe one
each for providers and another for consumers) and then deploying
each from source control, and controlled with file signature
monitoring, for extra security.<br>
</p>
<p>You can have the best of both worlds by enabling the config
database, but not converting to it. This "converts" your
slapd.conf into the memory-based OLC which can be updated on the
fly, but not persisted. To me this is the ideal, but then even
still, within many of theses setups, I have never needed to use
the OLC for on-the-fly-changes, so in retrospect, do not see the
necessity of this.</p>
<p>In summary, I see great value to continuing to support the
slapd.conf file-based config, especially for production, and I see
a lot of risk induced by deprecating it and forcing people to use
OLC. OpenLDAP project, would you please consider to not deprecate
slapd.conf?<br>
</p>
<p><span
style="mso-fareast-font-family:"Times New
Roman""><br>
Chris Paul | Rex Consulting | <a
href="https://www.rexconsulting.net"
class="moz-txt-link-freetext">https://www.rexconsulting.net</a></span>
<style type="text/css">body,div,table,thead,tbody,tfoot,tr,th,td,p { \
font-family:"Helvetica"; font-size:x-small }a.comment-indicator:hover + comment { \
background:#ffd; position:absolute; display:block; border:1px solid black; \
padding:0.5em; }a.comment-indicator { background:red; display:inline-block; \
border:1px solid black; width:0.5em; height:0.5em; }comment { display:none; \
}</style></p> <p><br>
</p>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic