I am comaintainer of Fedora unbound package. I was considering enabling
--enable-systemd and --enable-dnstap in our unbound. It is somehow
invasive however. Our unbound package has library part (unbound-libs)
and daemon package (unbound) separated. Daemon requires library package.
Both systemd and dnstap are linked into library itself. But I think
clients using unbound library cannot take any advantage from them.
I cannot find a reason why they should anyway. libunbound is popular for
DNSSEC verification. That is great. But is there a simple way to unbound
have only required dependencies like SSL, LZMA linked into? If I enable
those features, every package linking libunbound will depend also on
dnstap and systemd libraries. Is there any plan to move some libraries
only to unbound daemon? Is there reason why it is the current way? How
is it handled on other distributions?
I can't answer for the unbound developers, but I have a couple of
hackish ideas:
1. For the daemon package, build it with static linking and enable the
systemd and dnstap options when building. Then package this as the
"unbound" package. Next, rebuild, with dynamic linking, and leave out
the systemd and dnstap options, and package the libraries as
"unbound-libs". The downside here is that it can be confusing.
2. Build unbound with dynamic linking. For the first build, disable
systemd and dnstap, and package the libraries as "unbound-libs". Next,
build it again, with systemd and dnstap enabled, and create two
packages: "unbound" and "unbound-libs-heavy", and make "unbound" depend
on "unbound-libs-heavy".
This way, other applications can just keep using the "light" library
package called "unbound-libs", but the daemon can depend on the heavy
libs package, and nothing else should need it. But the big downside here
is that there would be name conflicts. If "unbound-libs" is already
installed, and then later a user wants to install unbound, and that
wants the heavy libraries, then you can't install them into the same
place, so the library files would probaby have to be renamed.
Yuck. Having written this down, I see that option #2 is quite
complicated. Option #1 is simpler, because the daemon doesn't depend on
anything else.
1. For the daemon package, build it with static linking
That is not allowed with fedora (for good reason I think)
2. Build unbound with dynamic linking. For the first build, disable
systemd and dnstap, and package the libraries as "unbound-libs". Next,
build it again, with systemd and dnstap enabled, and create two
packages: "unbound" and "unbound-libs-heavy", and make "unbound" depend
on "unbound-libs-heavy".
That is indeed pretty hacky.
If the systemd software watchdog is separated from the socket activation stuff, we can include that. The socket activation makes no sense and caused unbound to crash.
The unbound daemon binary itself actually does not dynamically link
against libunbound. The libunbound library is needed for the
unbound-anchor and unbound-host utilities.
What I do in the Debian package is perform multiple builds. One build is
for the unbound daemon and enables dnstap and other features. The
libunbound artifacts from this build are discarded (if there were a
--without-libunbound option I would use it for this build). Another
build is for the library itself (configure --with-libunbound-only)
without the extra add-ons.
This allows libunbound, unbound-anchor, and unbound-host to avoid the
extra dependencies required by dnstap. Only the "unbound" package that
contains the daemon has the extra dnstap dependencies.
1. For the daemon package, build it with static linking
That is not allowed with fedora (for good reason I think)
Sure, static linking is wrong way to solve it. Yet we use exactly that
in our current package. unbound, unbound-checkconf, unbound-streamtcp
and unbound-control do not link dynamically to libunbound. So they are
statically linked in my opinion, sort of. I have never noticed it
before. Robert takes advantage of that in Debian I think.
2. Build unbound with dynamic linking. For the first build, disable
systemd and dnstap, and package the libraries as "unbound-libs". Next,
build it again, with systemd and dnstap enabled, and create two
packages: "unbound" and "unbound-libs-heavy", and make "unbound" depend
on "unbound-libs-heavy".
That is indeed pretty hacky.
If the systemd software watchdog is separated from the socket activation stuff, we can include that. The socket activation makes no sense and caused unbound to crash.
Paul
I would like to signal service readiness from unbound. I do not think
socket activation is useful for us. If it always crashes often or
always, it has to be fixed.
I think more clean solution would be implementing some sort of interface
in libunbound for dnstap. The interface implementation would be linked
only to server and added in library initialization. DNSTAP code is
isolated enough for it. Just a structure with 3 function pointers would
work I think. Would require moving some code and non-trivial changes.
Probably would require ABI change. Would it be considered mergeable if I
prepared some prototype?
Systemd is more integrated. I am not sure whether it is really useful
for us.
Is anyone using out-of-tree configure and build to get different
results? Is it tested and used by nlnetlabs? Even tests work from
different directory it seems. Can it be relied on? We build two time for
different python versions, more variants would make it a mess.