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