Hi Petr!
Two separate things, building the library and modules.
For your specific case, couldn't you build Unbound two times?
One with all the configured modules you want and install the daemon from
that build?
The other configured with --with-libunbound-only and install a probably
vanilla, no extra configured modules only library to be used by other
programs?
As for the modules, the modularity is there for the developer and user
to be able to easily try new/extra features without polluting the main
logic of other features/functionality. This is how it started.
Then the Python module made it possible to have your own Python logic
attached into Unbound. And the dynlibmod came after that as providing
the same black box functionality without having to rely on Python.
The main reason for not having runtime loadable modules is that it was
not designed for that in the first place. It could be done but I believe
yours is the first request that at least I know of.
People could argue that this behaviour does not sound secure and they
would rather have the functionality compiled in the code.
I was told that there was such an argument way back for NSD.
I mean for core modules; dynlibmod for other stuff is something that you
need to explicitly configure/consent so that's on the user to decide.
As for configuration of dynamically loaded modules, it can already
happen if desired during initialization of the module (i.e., read your
own configuration from a source) but not as part of Unbound's config file.
Best regards,
-- Yorgos
On 09/07/2024 13:02, Petr Menšík via Unbound-users wrote:
Hello unbound users!
I have been digging around existing modules for unbound. There are some
quite nice, dnstap module for example. We package unbound for fedora and
rhel, but do not build alternative modules like redis, ipset or dnscrypt.
Main reason for it is dependencies dragged into libunbound.so. Because
our packaging would drag more unnecessary dependencies with each
depending application, gnutls-dane for example. The more we enable
during build, the more would get linked into libunbound. Which is quite
nice library for general DNS resolution and I would recommend it for
more complex resolution. But external module dependencies would make
every application using it require more packages.
I know most people does not need those modules. And they are made as
modules separate already, but not as loadable code. Of course problem is
they often have non-trivial configuration parts.
But unbound already supports dynlibmod, which kind of prepares loading
of external code. Could it be expanded a bit more to provide also
configuration snippets and known loadable modules?
Our unbound-libs package now depends on libprotobuf-c.so.1, among
others. Because we wanted dnstap. I think for general distributions,
this approach does not scale well. Ideally I would have unbound-dnstap
subpackage, which would only depend on protobuf-c. Another
unbound-redis, unbound-ipset, etc. But basic daemon would not link to
external libraries, only crypto libraries.
Is there specific reason, why loadable module cannot be dlopened only
when cachedb module is specified? Similar with any interesting features,
which are less common and have external library dependencies? dynlibmod
seems capable of such thing, but would make modules configuration look
weird. Especially when cachedb requires own section in configuration.
dynlibmod does not seem to support additional configuration processed in
module.
I expect those questions have already appeared. Were there any reasons
why modules are not (yet?) separate loadable code, but linked into main
library? Are there some blockers, why it should not be made such way?
Regards,
Petr
