Hi, I try to include or import a lot of configuration files in a node, but
it doesn''t work :/
I create a module to configure bind, but i have a lot of domains to
configure in the node of my server, so i decided to create an other module
just to register my configuration with 1 file per domain (i have around 200
domains, so arount 200 files...).
My tree (for the configuration module) :
module/
conf_bind/
manifests/
init.pp
bind/
domain1_conf.pp
...
domain200_conf.pp
Init.pp :
class conf_bind {
}
I tried " import ''bind/*.pp'' " , but it worked only
once on my VM... The
only solution i have now it''s to include my domain*_conf one by one,
but
i''ll be very long...
If someone got an idea :) thanks
--
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/-/U8UbkO-hf2IJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Friday, September 28, 2012 3:31:11 AM UTC-5, pierre-emmanuel degand wrote:> > Hi, I try to include or import a lot of configuration files in a node, but > it doesn''t work :/ > > I create a module to configure bind, but i have a lot of domains to > configure in the node of my server, so i decided to create an other module > just to register my configuration with 1 file per domain (i have around 200 > domains, so arount 200 files...). > > My tree (for the configuration module) : > module/ > > conf_bind/ > > manifests/ > > init.pp > > bind/ > > domain1_conf.pp > > ... > > domain200_conf.pp > > > Init.pp : > class conf_bind { > } > > I tried " import ''bind/*.pp'' " , but it worked only once on my VM... The > only solution i have now it''s to include my domain*_conf one by one, but > i''ll be very long... > > If someone got an idea :) thanks > >The ''import'' function is the wrong tool for this job (indeed there is only about one job for which it is appropriate). You don''t describe the contents of your bind/domainX_conf.pp manifests, but with the layout you describe, each should be of this form: class conf_bind::bind::domainX_conf { # declarations for configuring domain X... } 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'' } Puppet DSL does not provide a way to use pattern matching to assign classes to nodes, and it does not provide for textual interpolation in the manner of the C preprocessor''s "#include" directive. In particular, Puppet''s ''include'' function performs a fundamentally different job than does cpp''s "#include". 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/-/ueJrUZd_E84J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi, On Fri, 2012-09-28 at 06:47 -0700, jcbollinger wrote:> > > On Friday, September 28, 2012 3:31:11 AM UTC-5, pierre-emmanuel degand > wrote: > Hi, I try to include or import a lot of configuration files in > a node, but it doesn''t work :/ > > > I create a module to configure bind, but i have a lot of > domains to configure in the node of my server, so i decided to > create an other module just to register my configuration with > 1 file per domain (i have around 200 domains, so arount 200 > files...). > > > My tree (for the configuration module) : > module/ > conf_bind/ > manifests/ > init.pp > bind/ > domain1_conf.pp > ... > domain200_conf.pp > > > Init.pp : > class conf_bind { > }Ouch, that looks like a painful way to do it.> You don''t describe the contents of your bind/domainX_conf.pp > manifests, but with the layout you describe, each should be of this > form: > > class conf_bind::bind::domainX_conf { > # declarations for configuring domain X... > } > > 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'' > } > > Puppet DSL does not provide a way to use pattern matching to assign > classes to nodes, and it does not provide for textual interpolation in > the manner of the C preprocessor''s "#include" directive. In > particular, Puppet''s ''include'' function performs a fundamentally > different job than does cpp''s "#include".So, John answered the question you actually asked, and I''m going to try to answer the question you probably should have asked, which is, "what is the smart way to achieve this?" I think you probably want a custom type with enough parameters to satisfy your particular needs. Eg, if the master is always the same and the slaves are always the same, all you really need is the domain name. If you need more parameterization per domain, you could make zones be a hash with the additional information keyed carried in it. I''d set it up something like: class bind::params { $domains = [ domain1, ..., domain200, ] } class bind { package { ''bind'': } service { ''bind'': } } define bind::master_zone { include bind file { "/etc/bind9/zones/masters/${name}.conf": content => template(''bind/master_zone.conf.erb''), notify => Service[''bind''] } } define bind::slave_zone { include bind file { "/etc/bind9/zones/slaves/${name}.conf": content => template(''bind/slave_zone.conf.erb''), notify => Service[''bind''] } } class bind::master { include bind include bind::params $zones = $bind::params::zones bind::master_zone { $zones } } class bind::slave { include bind include bind::params $zones = $bind::params::zones bind::slave_zone { $zones } } This is off the top of my head, and leaves out an awful lot of boilerplate. Hopefully you see what I''m trying to say and it gets you to somewhere more manageable. Cheers, -- Stephen Gran Senior Systems Integrator - guardian.co.uk Please consider the environment before printing this email. ------------------------------------------------------------------ Visit guardian.co.uk - newspaper of the year www.guardian.co.uk www.observer.co.uk www.guardiannews.com On your mobile, visit m.guardian.co.uk or download the Guardian iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad Save up to 37% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit guardian.co.uk/subscribe --------------------------------------------------------------------- This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News & Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Friday, September 28, 2012 8:47:03 AM UTC-5, jcbollinger wrote:> > > > On Friday, September 28, 2012 3:31:11 AM UTC-5, pierre-emmanuel degand > wrote: >> >> Hi, I try to include or import a lot of configuration files in a node, >> but it doesn''t work :/ >> >> I create a module to configure bind, but i have a lot of domains to >> configure in the node of my server, so i decided to create an other module >> just to register my configuration with 1 file per domain (i have around 200 >> domains, so arount 200 files...). >> >> My tree (for the configuration module) : >> module/ >> >> conf_bind/ >> >> manifests/ >> >> init.pp >> >> bind/ >> >> domain1_conf.pp >> >> ... >> >> domain200_conf.pp >> >> >> Init.pp : >> class conf_bind { >> } >> >> I tried " import ''bind/*.pp'' " , but it worked only once on my VM... The >> only solution i have now it''s to include my domain*_conf one by one, but >> i''ll be very long... >> >> If someone got an idea :) thanks >> >> > The ''import'' function is the wrong tool for this job (indeed there is only > about one job for which it is appropriate). > > You don''t describe the contents of your bind/domainX_conf.pp manifests, > but with the layout you describe, each should be of this form: > > class conf_bind::bind::domainX_conf { > # declarations for configuring domain X... > } > > 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'' > } > > Puppet DSL does not provide a way to use pattern matching to assign > classes to nodes, and it does not provide for textual interpolation in the > manner of the C preprocessor''s "#include" directive. In particular, > Puppet''s ''include'' function performs a fundamentally different job than > does cpp''s "#include". > >On the other hand, there is probably an all-around better way to do this. I''m guessing that the manifests for your domains are all pretty much the same form, but with different data. In that case, you might be better off separating the data from the manifests. Puppet''s primary general-purpose data access API is hiera, which is an add-on to Puppet 2 but a built-in in Puppet 3. If you organize your data suitably then you can use hiera to serve it up to your module as a hash of hashes something like this: { domain1 => { propertyA => ''valueA1'', propertyB => ''valueB1'', ... }, ... domain200 => { propertyA => ''valueA200'', propertyB => ''valueB200'', ... } } Combine that with a suitable Puppet defined type and the create_resources() function, and your module can hook it all together something like this: class conf_bind { create_resources(''conf_bind::domain'', hiera(''bind_domains'')) } where ''conf_bind::domain'' is the name of the defined type that wraps the per-domain declarations, and ''bind_domains'' is the key with which hiera will look up your data. 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/-/qwb4qQdG4D0J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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,
}
}
And for each domainX_conf.pp :
class conf_bind::bind_domain_fr {
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
--
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/-/kOvfDx8vZBYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
As regards your 3 proposals : - "that it would probably all need to go into one YAML file" => it will be the same than insert all my config in the manifest.pp, and it''s not interesting to me - "you could put it in an hiera data store" => i don''t know this method yet - "You could write a custom function that reads the directory" => i think it''s the better choice Thanks for answering. -- 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/-/qF7rOFmRyMAJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.