3bfcc19a3e
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.
13 lines
398 B
YAML
13 lines
398 B
YAML
---
|
|
bind::defaults::supported: true
|
|
bind::defaults::bind_user: 'bind'
|
|
bind::defaults::bind_group: 'bind'
|
|
bind::defaults::bind_package: 'bind9'
|
|
bind::defaults::bind_service: 'bind9'
|
|
bind::defaults::nsupdate_package: 'dnsutils'
|
|
bind::defaults::confdir: '/etc/bind'
|
|
bind::defaults::namedconf: '/etc/bind/named.conf'
|
|
bind::defaults::cachedir: '/var/cache/bind'
|
|
|
|
bind::updater::keydir: '/etc/bind/keys'
|