[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: BECOT_Jérôme <jbecot () itsgroup ! com>
Date: 2023-11-16 10:50:31
Message-ID: DU2P194MB2199B025C5E8D16463BD178DB1B0A () DU2P194MB2199 ! EURP194 ! PROD ! OUTLOOK ! COM
[Download RAW message or body]
We use automatio,n that abstracts the setuo complexity a lot. Any changes n=
eeded is made to the automation code, with the history tracked into git sid=
e.
Regards
Jerome
________________________________
De : Norman Gray <gray@nxg.name>
Envoy=E9 : jeudi 16 novembre 2023 11:32
=C0 : Ben Poliakoff <benp@reed.edu>
Cc : openldap-technical@openldap.org <openldap-technical@openldap.org>
Objet : Re: Transitioning from slapd.conf to slapd.d, best practices for ma=
intaining configuration comments?
ATTENTION : Cet e-mail provient de l'ext=E9rieur de l'organisation. Ne cliq=
uez pas sur les liens et n'ouvrez pas les pi=E8ces jointes =E0 moins que vo=
us ne reconnaissiez l'exp=E9diteur et que vous sachiez que le contenu est s=
=FBr.
Ben, hello.
On 15 Nov 2023, at 18:58, Ben Poliakoff wrote:
> Looking for any tips about how
> best to annotate slapd configuration, in a slapd.d/olc world. Does anyone
> have a practice that they find works well for them?
What works for me (in a primary+replicas setup) is to maintain a slapd.ldif=
file with structured comments in it (ie, #@PRIMARY@ and #@REPLICA@ marking=
different variants), and when changes need to be made to the configuration=
, I stop the primary server (leaving things to replicas), slapcat the data,=
rebuild the slapd.d from scratch with the appropriate version of the confi=
guration file, reload the data, and restart; then do the same with the repl=
icas.
This isn't ideal, but it works for me because the window when no-one can wr=
ite, because the primary is off, is acceptably small.
The advantages are
* I can version-control (and of course densely comment) the configuration=
, with all the attendant advantages
* I know exactly what the configuration of the server is, without queryin=
g the server
* because they're both generated from the same source, I know for sure th=
at the primary and replicas have compatible configurations
* that means I can have a test server (including scratch regression-test =
servers) with a duplicate configuration
I can see how I could achieve most of these things using slapd.d as intende=
d. But this route feels more direct, and thus more intelligible to me. Th=
e first advantage seems the key one, to me.
Best wishes,
Norman
--
Norman Gray : https://nxg.me.uk
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} \
</style> </head>
<body dir="ltr">
<div class="elementToProof">We use automatio,n that abstracts the setuo complexity a \
lot. Any changes needed is made to the automation code, with the history tracked into \
git side.</div> <div class="elementToProof"><br>
</div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, \
Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, \
0, 0);">Regards</span></div> <div class="elementToProof"><span style="font-family: \
Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);">Jerome</span></div> <div \
class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, \
Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, \
0, 0);"><br> </span></div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, \
Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, \
0, 0);"><br> </span></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, \
Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, \
0, 0);"> <br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" \
style="font-size:11pt" color="#000000"><b>De :</b> Norman Gray \
<gray@nxg.name><br> <b>Envoyé :</b> jeudi 16 novembre 2023 11:32<br>
<b>À :</b> Ben Poliakoff <benp@reed.edu><br>
<b>Cc :</b> openldap-technical@openldap.org \
<openldap-technical@openldap.org><br> <b>Objet :</b> Re: Transitioning from \
slapd.conf to slapd.d, best practices for maintaining configuration comments?</font> \
<div> </div> </div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">ATTENTION : Cet e-mail provient de l'extérieur de \
l'organisation. Ne cliquez pas sur les liens et n'ouvrez pas les pièces jointes à \
moins que vous ne reconnaissiez l'expéditeur et que vous sachiez que le contenu est \
sûr.<br> <br>
Ben, hello.<br>
<br>
On 15 Nov 2023, at 18:58, Ben Poliakoff wrote:<br>
<br>
> Looking for any tips about how<br>
> best to annotate slapd configuration, in a slapd.d/olc world. Does anyone<br>
> have a practice that they find works well for them?<br>
<br>
What works for me (in a primary+replicas setup) is to maintain a slapd.ldif file with \
structured comments in it (ie, #@PRIMARY@ and #@REPLICA@ marking different variants), \
and when changes need to be made to the configuration, I stop the primary server \
(leaving things to replicas), slapcat the data, rebuild the slapd.d from scratch \
with the appropriate version of the configuration file, reload the data, and restart; \
then do the same with the replicas.<br> <br>
This isn't ideal, but it works for me because the window when no-one can write, \
because the primary is off, is acceptably small.<br> <br>
The advantages are<br>
<br>
* I can version-control (and of course densely comment) the configuration, \
with all the attendant advantages<br> * I know exactly what the configuration \
of the server is, without querying the server<br> * because they're both \
generated from the same source, I know for sure that the primary and replicas have \
compatible configurations<br> * that means I can have a test server (including \
scratch regression-test servers) with a duplicate configuration<br> <br>
I can see how I could achieve most of these things using slapd.d as intended. \
But this route feels more direct, and thus more intelligible to me. The first \
advantage seems the key one, to me.<br> <br>
Best wishes,<br>
<br>
Norman<br>
<br>
<br>
--<br>
Norman Gray : <a href="https://nxg.me.uk">https://nxg.me.uk</a><br>
</div>
</span></font></div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]