On Tue, 3 Nov 2020 02:50:37 -0500
Steve Litt <slitt@???> wrote:

> On Thu, 29 Oct 2020 16:53:43 +0000
> g4sra via Dng <dng@???> wrote:
>

> > On 29/10/2020 13:44, Michael Neuffer wrote:  
> > > On 10/29/20 2:27 PM, dng@??? 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 <edmonds@???> Sun, 09 Aug 2020 19:39:01 -0400

Best

fraser