Re: syncrepl between 2.4.57.0.1 and 2.6.2-3
--On Thursday, November 16, 2023 2:50 PM + michael.fr...@airbus.com wrote: Meanwhile we have found a non - technical workaround to just skip the solaris scenario - this means that we can close this topic. Thanks you guys (also Stefan) for the support an your time ! Glad you got it resolved, not sure why Solaris behaves differently. --Quanah
Re: syncrepl between 2.4.57.0.1 and 2.6.2-3
Hi Quanah, no - we always replicate partly and not the entire db. Meanwhile I have achived to have a fully functional (partly) replication from 2.6.2-3 to 2.4.44 up and running reliable which can also be activated and deactivated. The difference is mainly that the 2.4.44 Instance is operated on an RHEL 7.x and not on Solaris. For still unknown reasons the 2.4.57.0.1 on Solaris behaves very different to the Rhel Instances. E.g. I tried to use the manager for replication to avoid permission issues, etc, etc etc Meanwhile we have found a non - technical workaround to just skip the solaris scenario - this means that we can close this topic. Thanks you guys (also Stefan) for the support an your time ! Best regards, micha
RE: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
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 Envoyé : jeudi 16 novembre 2023 11:32 À : Ben Poliakoff Cc : openldap-technical@openldap.org 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
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
On 11/15/23 1:58 PM, Ben Poliakoff 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 having jumped into LDAP after the switch to OLC started, i dove into the OLC configs and really tried to learn how the new mechanism worked. i like the benefit of the online updates where changes to the instance occur without having to stop/start. i use fedora, and it includes the file /usr/share/openldap-servers/slapd.ldif which serves as a base config example, with comments in it. i have modified that and then added its contents via slapadd or ldapadd. as a jumping off point, you might look at "slaptest -f file> -F ". this will actually convert from old to new format and may offer an opportunity to see what you flat config would look like in OLC format. when i wanted to add new object, entries, etc, i often create a purposefully named ldif file, and add the syntax to it that is needed for the specific purpose. i have a myriad of files named according to what the action is or the function of the ldif file is, like CacheModule.ldif and CacheOverlay.ldif. this helps me compartmentalize the configs and not be overwhelmed with everything else going on. i have found the phpLDAPAdmin project, which provides a browser based admin UI, to be invaluable. getting past the syntax of LDAP allows me to be focused on what i need to do, and not how i need to do it, though you do still need to have proper structure in the syntax you're working with. HTH brendan
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
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
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
Il 15/11/23 19:58, Ben Poliakoff ha scritto: 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? That's the main reason because I don't use slapd.d, and I revert to slapd.conf after installation, if it's used by default. I don't need the slapd.d features, using slapd.conf configuration is more readable, and I can revert any modification with a stop and a file replacement, automation and deploy is simpler. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597
