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.
Modify the handling of the `servers` property in `bind::view` to respond to
specific keys in the config hash for each server, and document how this
property is handled.
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.
Several record types do not function correctly with the `resource_record` type
unless their values are specified as fully-qualified names with a trailing dot.
This adds clarifying information to the documentation and fixes a couple of
examples which are actually broken.
The incremental update change made NS record updates work for non-glue NS
records, but broke `ensure => absent` because there is no semantic guarantee
that the contents of the `data` member match what's in DNS. Set math ensures
that hilarity ensues.
Both the guts of the PuppetBind::Provider::Nsupdate module and the type method
of the dns_rr(nsupdate) provider produce and expect the type expressed as a
string, but the resource_record(nsupdate) provider's type method produces
symbols. This accidentally worked for a while, then it didn't. Also, in
quoted_type? that's supposed to be an array of strings, not a quoted string.
`validate_bool` validates that the passed value(s) are boolean, not that they
are true. Reformulate the calls to `unless` blocks, and remove the check for
"dynamic implies master" since setting `dynamic` to true is 1) the default and
2) does not cause any change to configuration text or manifest behavior when
the zone is not master.
