bind config should be separated out into local/options files about puppet-bind

[thias]

There isn't the same breakdown in RHEL. It has the following in RHEL6 :
/etc/named.conf
/etc/named.iscdlv.key
/etc/named.rfc1912.zones
/etc/named.root.key
/var/named/named.ca
/var/named/named.empty
/var/named/named.localhost
/var/named/named.loopback

Any way of splitting the files should be possible with the current module. I'm even doing it, using the "includes" parameter, where I reference a file I generate using another module's definition in order to repeat some common configuration for multiple types of zones (typically internal/external, with different acls allowed for querying and transfer).

So, what's wrong with something like the following :

class named::server::conf with includes => [ 'named.conf.local', 'named.conf.options', 'named.conf.default-zones' ]

Then use the bind::server::file definition for each of these files?

Also, I've made the main named.conf management optional on purpose, meaning that If you just include the main class (not the conf), and your bind server package contains a working default, you're good to go. So here, if it automatically includes the files you mention, you could use only bind::server::file to manage the one or more file(s) you want, not the main named.conf.

Bottom line : It's already possible, and I don't see any easy/clean way to replicate the behaviour of all possible distros without making a huge useless mess inside the module :-)

[apowers]

What Thias said and more to the point it shouldn't really matter what your distro does as long as the configuration is reproducible and functional on whatever system you are applying the module to. Thus it shouldn't matter that RHEL and Debian have different ways of structuring the configuration files as long as the module can build a structure that works on either/all distributions, which it can and does.

[thias]

What I also want to avoid is having the module force a structure of its own. For me, the ideal situation is to have a puppet module configure things in the ideal way for a given OS, meaning leaving everything where people familiar with that OS expect it to be : For instance, I don't want an apache httpd puppet module to have files under /etc/apache2/ on a Red Hat system, nor do I want to have it use /etc/httpd/ on a Debian system.

[thias]

I'm going to close this one. But if anyone wants to submit a pull request for clean and sane changes, I'll definitely have a look.