On Tue, 3 Nov 2020 02:50:37 -0500 Steve Litt <sl...@troubleshooters.com> wrote:
> On Thu, 29 Oct 2020 16:53:43 +0000 > g4sra via Dng <dng@lists.dyne.org> wrote: > > > On 29/10/2020 13:44, Michael Neuffer wrote: > > > On 10/29/20 2:27 PM, d...@d404.nl wrote: > > --snip-- > > >> To ease the maintenance of those servers i intend to migrate them > > >> to docker containers. I wonder people on this list have > > >> experience on this subject? > > > > > > > > > You might want to take a look at this project: > > > > > > https://github.com/mailserver2/mailserver > > > > Please correct me if I am mistaken, I thought 'unbound' was tied to > > 'systemd creep' nowadays and have been avoiding it for that reason > > alone. I want to avoid creating a dependency on something I don't > > already have only to need to purge it next year ... > > I'm as anti-systemd as the next guy, but I use unbound on a constant, > everyday basis. Let me explain... > > Here are two lines from my unbound.conf: > > ====================================================== > # Guard against future default changes: no systemd ever! > use-systemd: no > ====================================================== > > As far as I can see, if I had set use-systemd to "yes", unbound would > have reported its success in starting in the systemd approved way, and > would not have backgrounded itself. So if you use sysvinit, you just > say use-systemd: no and whatever option that makes it background > itself. If you use runit or s6, say systemd: no and whatever makes it > NOT background itself. > > So basically, there's a little, probably completely separate part of > unbound with minimal linkage, that if told to, will send out a > systemd-approved "I am functional now" message. But as far as I know, > unbound uses no systemd facilities and would only require or suggest > systemd as a result of a systemd-infected distro configuring unbound > that way. Not sure if it is relevant or not, but during a dist-upgrade to ceres today, got the following notification: unbound (1.11.0-1) unstable; urgency=medium The default Debian config file shipped in the unbound package has changed from using the "include:" directive to using the "include-toplevel:" directive in order to include the config file fragments in /etc/unbound/unbound.conf.d/*.conf into the unbound configuration. The "include-toplevel:" directive has been newly introduced in unbound 1.11.0 and it requires that any included config file fragment begin its own clause (e.g., "server:"). The existing "include:" directive that was used in previous Debian releases of the unbound package only performed textual inclusion, and it was possible to construct a set of config file fragments that depended on the presence or ordering of specific config file fragments in order to parse correctly. For instance, a config file fragment could have specified an option that can only appear in the "server:" clause, and rely on a previously included config file fragment to begin that clause. This behavior is no longer allowed by the use of the "include-toplevel:" directive because it is not robust against config file fragments being added, removed, or reordered. If you are upgrading the unbound package and you have installed any config file fragments into /etc/unbound/unbound.conf.d/ you should check that each config file fragment begins its own clause (e.g., "server:") and update each config file fragment as necessary to be compatible with the behavior of the "include-toplevel:" directive. If needed, the previous behavior can be restored by changing the following line in /etc/unbound/unbound.conf: include-toplevel: "/etc/unbound/unbound.conf.d/*.conf" to its previous setting: include: "/etc/unbound/unbound.conf.d/*.conf" -- Robert Edmonds <edmo...@debian.org> Sun, 09 Aug 2020 19:39:01 -0400 Best fraser _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
