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.
4 lines
82 B
YAML
4 lines
82 B
YAML
---
|
|
bind::defaults::confdir: '_CONFDIR_'
|
|
bind::defaults::namedconf: '_NAMEDCONF_'
|