[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: Ben Poliakoff <benp () reed ! edu>
Date: 2023-11-30 17:33:59
Message-ID: CAEamvFDWsj9o5SO=HU2cJaxY87JLrvLscb_+s5ET1-yDF-a_RA () mail ! gmail ! com
[Download RAW message or body]
On Wed, Nov 15, 2023 at 10:58 AM Ben Poliakoff <benp@reed.edu> wrote:
> This is more of a practical question than a technical one, but it's
> prompted by a technical change: I'm *very* **very** belatedly transitioning
> from flat file slapd.conf config to slapd.d/OLC.
>
> With flat file configuration, it was straightforward to include text
> comments (e.g. "# blah blah"), but as far as I know there isn't any sort of
> analog for comments, when using slapd.d. 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? Do people just maintain
> separate documents/wiki pages/etc that describe their servers' configs?
>
> Ben
>
Thank you all for your thoughts about this! I've resisted the olc config
route for many of the reasons mentioned in your responses. But after having
finally spent more time with it, I am particularly taken with one of the
features that it makes possible, namely the replication of cn=config. The
documents have certainly mentioned for years that the slapd.conf option
will go away at some point, and while it's not clear when that might
happen, it's enough for me in my own environment to try to move forward
with olc.
We use puppet in my environment, and I've looked at the now community
maintained puppet forge module (
https://forge.puppetlabs.com/modules/puppet/openldap/readme) but I really
don't love the extra layer of abstraction that it employs to manage
cn=config. I'm a bit reluctant to move away from a declarative
configuration management style for cn=config (I'm still using puppet for
all the *other* bits of the configuration of an openldap server), but not
so reluctant as to want to go all in with the puppet openldap module.
My current plan is to write a script that pulls the entire cn=config, and
writes it out to ldif files, much like what is rendered in slapd.d, but
with the attributes of each entry sorted. I can then insert
comments/documentation into these ldif files and track them all in a git
repo, so that my current config is documented, much as it is in
slapd.conf. I've written a separate script (that will be run via cron)
that pulls the *active* cn=config and compares it to the
commented/documented ldif files that I generated previously (stripping out
the comments). At this point a simple diff will show if changes have been
made, and if the changes are ones that I want to keep, I can updated the
commented ldif files. The sorting of the attributes in the ldif files is
key, since otherwise there's no guaranty that this diff-based method would
work. This approach feels a little bit backwards, coming from a file based
configuration management point of view, but for me it's a reasonable
compromise to move forward with cn=config.
Thanks again for all the discussion and comments!
Ben
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr">On Wed, Nov 15, 2023 at 10:58 AM Ben Poliakoff <<a \
href="mailto:benp@reed.edu">benp@reed.edu</a>> wrote:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This is \
more of a practical question than a technical one, but it's prompted by a \
technical change: I'm *very* **very** belatedly transitioning from flat file \
slapd.conf config to slapd.d/OLC. <div><br></div><div>With flat file configuration, \
it was straightforward to include text comments (e.g. "# blah blah"), but \
as far as I know there isn't any sort of analog for comments, when using slapd.d. \
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? Do people \
just maintain separate documents/wiki pages/etc that describe their servers' \
configs?</div><div><br></div><div>Ben</div></div></blockquote><div><br></div><div>Thank \
you all for your thoughts about this! I've resisted the olc config route for many \
of the reasons mentioned in your responses. But after having finally spent more time \
with it, I am particularly taken with one of the features that it makes possible, \
namely the replication of cn=config. The documents have certainly mentioned for years \
that the slapd.conf option will go away at some point, and while it's not clear \
when that might happen, it's enough for me in my own environment to try to move \
forward with olc. </div><div><br></div><div>We use puppet in my environment, and \
I've looked at the now community maintained puppet forge module (<a \
href="https://forge.puppetlabs.com/modules/puppet/openldap/readme">https://forge.puppetlabs.com/modules/puppet/openldap/readme</a>) \
but I really don't love the extra layer of abstraction that it employs to manage \
cn=config. I'm a bit reluctant to move away from a declarative configuration \
management style for cn=config (I'm still using puppet for all the *other* bits \
of the configuration of an openldap server), but not so reluctant as to want to go \
all in with the puppet openldap module.</div><div><br></div><div>My current plan is \
to write a script that pulls the entire cn=config, and writes it out to ldif files, \
much like what is rendered in slapd.d, but with the attributes of each entry sorted. \
I can then insert comments/documentation into these ldif files and track them all in \
a git repo, so that my current config is documented, much as it is in slapd.conf. \
I've written a separate script (that will be run via cron) that pulls the \
*active* cn=config and compares it to the commented/documented ldif files that I \
generated previously (stripping out the comments). At this point a simple diff will \
show if changes have been made, and if the changes are ones that I want to keep, I \
can updated the commented ldif files. The sorting of the attributes in the ldif files \
is key, since otherwise there's no guaranty that this diff-based method would \
work. This approach feels a little bit backwards, coming from a file based \
configuration management point of view, but for me it's a reasonable compromise \
to move forward with cn=config.</div><div><br></div><div>Thanks again for all the \
discussion and comments!</div><div><br></div><div>Ben</div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic