Most of my machines are pretty cookie-cutter, so I have one class and config file setup for different services. For example, pretty much have one hosts.allow that goes out everywhere. However, there are always exceptions. So I have 3 hosts that have similar configs but have more things open, so what''s the ''best practice'' way to centralize those? Do I really need to create a whole new class and assign that one config file to it for one host? Thanks! Dan -- 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.
Am 04.06.2010 18:34, schrieb Dan:> Most of my machines are pretty cookie-cutter, so I have one class and > config file setup for different services. For example, pretty much > have one hosts.allow that goes out everywhere. However, there are > always exceptions. So I have 3 hosts that have similar configs but > have more things open, so what''s the ''best practice'' way to centralize > those? Do I really need to create a whole new class and assign that > one config file to it for one host?The simplest way would be to use class inheritance and override the source of the file: class extended inherits base { File["/etc/hosts.allow"]{source => ...} } A more maintainable way would be to manage the file''s content more fine-grained than that. Look into the "augeas" type whether there is a lens to manage that syntax. Then you could use a simple define to wrap this all nicely into a resource you can use: define hosts_allow(...) { augeas {...} } class base { hosts_allow { ... } } class other_stuff { hosts_allow { ... } } Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- 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 Sun, Jun 6, 2010 at 5:13 PM, David Schmitt <david@dasz.at> wrote:> Am 04.06.2010 18:34, schrieb Dan: >> >> Most of my machines are pretty cookie-cutter, so I have one class and >> config file setup for different services. For example, pretty much >> have one hosts.allow that goes out everywhere. However, there are >> always exceptions. So I have 3 hosts that have similar configs but >> have more things open, so what''s the ''best practice'' way to centralize >> those? Do I really need to create a whole new class and assign that >> one config file to it for one host? > > The simplest way would be to use class inheritance and override the source > of the file: > > class extended inherits base { > File["/etc/hosts.allow"]{source => ...} > } > > A more maintainable way would be to manage the file''s content more > fine-grained than that. Look into the "augeas" type whether there is a lens > to manage that syntax. Then you could use a simple define to wrap this all > nicely into a resource you can use: > > define hosts_allow(...) { > augeas {...} > } > > > class base { > hosts_allow { ... } > } > > class other_stuff { > hosts_allow { ... } > }You could manage it via two seperate templates, and otherwise keep the class the same. Or you could have a $variable in the template that turns on the extra hosts when set. --Michael -- 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 Fri, Jun 4, 2010 at 11:34 AM, Dan <dwittenberg2008@gmail.com> wrote:> Most of my machines are pretty cookie-cutter, so I have one class and > config file setup for different services. For example, pretty much > have one hosts.allow that goes out everywhere. However, there are > always exceptions. So I have 3 hosts that have similar configs but > have more things open, so what''s the ''best practice'' way to centralize > those? Do I really need to create a whole new class and assign that > one config file to it for one host?I use a technique approximately like this: class syslog-ng { package { "syslog-ng": ensure => installed } file { "/etc/syslog-ng.conf": require => Package[syslog-ng], source => [ "puppet:///modules/syslog-ng/$hostname/syslog-ng.conf", "puppet:///modules/syslog-ng/syslog-ng.conf" ] } } Then in the files directory of that module, I have a a "syslog-ng.conf" at the top level, and subdirectories for each host that requires a custom configuration. Puppet first checks to see if the $hostname subdir exists and, if it doesn''t, falls through to the default config file. The documentation for the "source" parameter describes how this works in more detail: http://docs.puppetlabs.com/references/stable/type.html#source -Ben -- 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.