On Friday, September 28, 2012 9:56:51 AM UTC-5, pierre-emmanuel degand
wrote:
>
> my module bind :
> - init.pp :
> class bind {
> include bind::install
> include bind::service
> }
>
> -install.pp :
> class bind::install (
> $packages = $bind::params::server_packages
> ) inherits bind::params {
> package { $packages :
> ensure => present,
> }
>
> file { "/etc/bind/zones":
> ensure => "directory",
> owner => "root",
> group => "root",
> mode => 0755,
> }
>
> file { "/etc/bind/named.conf.local":
> owner => "root",
> group => "root",
> mode => 0644,
> source => "puppet:///modules/bind/named.conf.local",
> }
>
> }
>
> service.pp :
> class bind::service (
> $service = $bind::params::server_services
> ) inherits bind::params {
> service { $service :
> enable => true,
> ensure => running,
> hasrestart => true,
> hasstatus => true,
> }
> }
>
> params.pp :
> class bind::params {
> $server_packages = ["bind9"]
> $server_services = "bind9"
> }
>
> config.pp (the one i use to configure each domain) :
> define bind::config ($dns_server = $fqdn,
> $domain,
> $type_ip = "A",
> $ip_serv = '',
> $type_ip2 = $type_ip,
> $ip_serv2 = $ip_serv,
> $sub_domain='',
> $mx="false",
> $ip_mx1 = "xxx.xxx.xxx.xxx",
> $domain_mx1 = $domain,
> $type_mx1 = "A",
> $ip_mx2 = "xxx.xxx.xxx.xxx",
> $domain_mx2 = $domain_mx1,
> $type_mx2 = "A",
> $ip_ns1 = "xxx.xxx.xxx.xxx",
> $type_ns1 = "A",
> $ip_ns2 = "xxx.xxx.xxx.xxx",
> $type_ns2 = "A",
> $ip_ns3 = "xxx.xxx.xxx.xxx",
> $type_ns3 = "A",
> $www = "true"
> ){
>
> include bind
> file { "/etc/bind/zones/${domain}.db":
> content => template("bind/zone.db.erb"),
> owner => "root",
> group => "root",
> mode => 0644,
> }
> }
>
>
Having so many parameters is pretty ugly, but perhaps that's the best
available way. Puppet supports arrays and hashes, however, and your ERB
template could easily make use of such objects, so perhaps it would be both
cleaner and more convenient to replace some groups of parameters with array
or hash parameters. That might even be more flexible, too.
More importantly, items in your parameter list must not refer to other
items in the same list. That is, parameter list items such as
> $type_ip2 = $type_ip,
will not reliably do what you expect. The order of the parameter list is
irrelevant to this issue.
Your best bets would be to restructure your parameter space some way that
does not require duplication, or to convert some or all of your parameters
into ordinary variables and set them via a mechanism that allows you to
specify a default value (hiera() and even extlookup() can do this). There
are cleaner alternatives now, but the traditional approach follows this
model:
define bind::config (...
$type_ip2 = 'UNSET',
...) {
$real_type_ip2 = $type_ip2 ? {
'UNSET' => $type_ip,
default => $type_ip2
}
...
}
Alternatively, you could put similar code into your template instead of
your manifest.
>
> And for each domainX_conf.pp :
> class conf_bind::bind_domain_fr {
>
Note that Puppet will expect to find a class of that name in
<module_path>/conf_bind/manifests/bind_domain_fr.pp (that is, not in a
subdirectory).
> bind::config { "domain.fr":
> domain => "domain.fr",
> ip_serv => "xxx.xxx.xxx.xxx",
> sub_domain => ["domain.fr. IN MX 20 mx2.ovh.net.",
> "domain.fr. IN MX 10 mx1.ovh.net.",
> "domain.fr. IN MX 100 mxb.ovh.net.",
> "domain.fr. IN TXT \"v=spf1
> ip4:xxx.xxx.xxx.xxx ip4:xxx.xxx.xxx.xxx -all\"",
> "subdomain1 IN A xxx.xxx.xxx.xxx",
> "subdomain2 IN A xxx.xxx.xxx.xxx",
> "pop3 IN CNAME ns0.ovh.net.",
> ],
> }
> }
>
> At the beginning, all the configuration was in the node.pp, but i had too
> much ligns so i split all the configuration like that...
>
> "Then in the module's init.pp you would have:
>
> class conf_bind {
> include 'conf_bind::bind::domain1_conf'
> include 'conf_bind::bind::domain2_conf'
> # ...
> include 'conf_bind::bind::domain200_conf'
> }" ==> it's what i want to avoid :s
>
I understand that you want to avoid listing each class individually in your
manifests, but you cannot do that without changes of one kind or another.
Here are some of your options:
- The general structure of your module is much as I suspected, quite
suitable for a conversion to storing all the domain data in hiera and then
using create_resources() to declare all the domains. You already have
bind::config as the resource type that you would specify to
create_resources(). The limitations here are that you would need to
convert all those classes to suitably-structured YAML (or build the YAML
data some other way), and that it would probably all need to go into one
YAML file.
- You could write a custom function that reads the directory containing
the per-domain manifests, converts file names to corresponding
(fully-qualified) class names, and returns an array of the class names. I
think you can pass such an array to the 'include' function to declare them
all, but at worst you could interpose a simple defined type to handle the
array and cause all the named classes to be included.
- If the problem is not so much the use of a hard-coded list of classes
as the location of that list, then you could put it in an hiera data store
or a separate parameters class.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/MQaW_lK8fMIJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
