- RHEL chroot code has been moved into a bind::chroot::package class
- Debian family (and probably other families) can use the
`bind::chroot::manual` class to enable chroot for bind using the method
described here: https://wiki.debian.org/Bind9#Bind_Chroot
Debian supplies the bind keys at /etc/bind/bind.keys and RedHat supplies it at
/etc/named.iscdlv.key. Add the directive that references this file. I think it
may have "just worked" on Debian, baesd on the information at
https://www.isc.org/downloads/bind/bind-keys/
The bind class parameter defaults values are meant to be supplied via module
data. Really, these ought to come through the bind::defaults class from hiera,
but that class is currently the home of platform defaults which are not meant
to be overridden by the user. This is a first step, maybe? A normalization for
sure.
It turns out the `rndc` command that was intended to reload a managed zone
wasn't working (see PR #91 for reference) if more than one view included the
zone. The helper script is really just a wrapper around the `rndc` command
itself, it translates its final parameter into a domain/class/view tuple and
pass the leading parameters and the tuple to `rndc`.
RedHat's default zones are baked into the stock named.conf, which the module's
template completely rewrites. Since the module is extremely view-based, and the
Debian default-zones are repositioned into the zones, let's take those defaults
out of the stock named.conf, build a configuration file out of them and include
it in the view just the same.
The changes in the `redhat-default-zones` branch, when released, may cause
upgrade difficulties for Red Hat system administrators. Try to ease the
transition.
The `params` vs. `bind` class distinction has been blurry for a long time. I'm
formalizing it.
`params` is now `defaults` and its purpose is to gather platform-specific
variation into a single scope. These variables are related to situating a BIND
server on a particular platform and it should not ever be necessary or perhaps
even possible to change them as a matter of preference. Rather, correct values
are function of e.g. `$osfamily` or `$operatingsystem`.
The parameters of the `bind` class are limited to those that control the
server's feature set. These parameters *are* matters of preference and/or
purpose, rather than platform.
Also, I have taken some care to develop a convention for direct references to
qualified parameters where they are re-scoped into the local scope centrally at
the top first, and subsequent references are to the local value. This should
minimize future code churn and also aid readability.
Fix a bunch of warnings whne using the bind::updater class by moving confdir to
the params class. In order for this to work, the bind and bind::updater classes
both now inherit from params. Also, fix the default value for
managed_key_directory to something that's actually falsey.
Distro packaging includes a lot of configuration files that this module tries
and fails to get rid of, but with exclusions. Those don't always work for
mysterious reasons. Leave the distributed files intact as much as possible,
with just the necessary files touched to effect the desired configuration.
Also, make inclusion of named.conf.local optional (default false) and stop
ensuring that there's at least an empty one.
`dnssec-keygen` uses `/dev/random` by default, but this is slow in some
scenarios where `/dev/urandom` is both faster and provides sufficient utility.
Allow override via the `bind::random_device` hiera key.
Previous iterations and even a release were all broken. The module works again,
sorry for the interlude.
- Giving up on params and moving to module_data (WIP)
- Change the Package and Service references to the static 'bind' name
- Add a meager amount of test coverage
