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.
Regards Jerome ________________________________ De : Norman Gray <[email protected]> Envoyé : jeudi 16 novembre 2023 11:32 À : Ben Poliakoff <[email protected]> Cc : [email protected] <[email protected]> Objet : Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments? 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. 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 configuration file, reload the data, and restart; then do the same with the replicas. 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. 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 querying the server * because they're both generated from the same source, I know for sure that 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 intended. But this route feels more direct, and thus more intelligible to me. The first advantage seems the key one, to me. Best wishes, Norman -- Norman Gray : https://nxg.me.uk
