Hi, A question for the devs. Will this: http://projects.puppetlabs.com/issues/4020 make it into a release any time soon? Best regards, Martijn. -- 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.
Sadly, signs point to "no". On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman <martijn@iphion.nl>wrote:> Hi, > > A question for the devs. Will this: > > http://projects.puppetlabs.com/issues/4020 > > make it into a release any time soon? > > Best regards, > Martijn. > > -- > 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. > >-- 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 02-03-11 14:49, Brian Gallew wrote:> Sadly, signs point to "no".Too bad. But since I run a patched Puppetmaster anyway, I can do what I want :-) Unfortunately, it doesn''t solve my problem. I am trying to do the same thing as Gabriel Filion in this post: http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d So, I have a nagios-target class, that defines a virtual resource: @@nagios_host { "$hostname": use => "generic-host", address => $fqdn, alias => $hostname, ensure => present, hostgroups => [], } and I would like to do something along the lines of this: in a different class (not a subclass of nagios-target), for example in the class that configures the MTA: Nagios_host [$hostname] { hostgroups +> "mail-satellite-servers", } which results in this error: "Only subclasses can override parameters at ..." which sounds logical, but... Is there any way to do what I want? I can''t really think of anything, since (variable) scoping will always be in my way, as far as I can see... Best regards, Martijn.> > On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman <martijn@iphion.nl > <mailto:martijn@iphion.nl>> wrote: > > Hi, > > A question for the devs. Will this: > > http://projects.puppetlabs.com/issues/4020 > > make it into a release any time soon? > > Best regards, > Martijn. > > -- > 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 > <mailto:puppet-users@googlegroups.com>. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com > <mailto:puppet-users%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > > -- > 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.-- 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.
Martijn Grendelman
2011-Mar-02 15:33 UTC
[Puppet Users] Class inheritance (was Re: Nagios configuration arrays)
Hi, After some reading and experimenting, I thought I had found the solution to the problem below in class inheritance, but again... I''m stuck. As said, I have class "nagios-target", defined as listed below. I now have this: class mta inherits nagios-target { Nagios_host [$hostname] { hostgroups +> "mail-satellite-servers", } } This works; I get a Nagios host definition with the expected ''hostgroups'' setting. Now I add a second class: class snmp inherits nagios-target { Nagios_host [$hostname] { hostgroups +> "snmp-servers", } } but now I get: Error 400 on SERVER: Parameter ''hostgroups'' is already set on Nagios_host[martijn] at /etc/puppet/manifests/classes/mta.pp:43; cannot redefine at /etc/puppet/manifests/classes/snmp.pp:4 on node martijn. What part of overriding parameters and the ''+>'' operator am I missing here? Best regards, Martijn. On 02-03-11 15:55, Martijn Grendelman wrote:> On 02-03-11 14:49, Brian Gallew wrote: >> Sadly, signs point to "no". > > Too bad. But since I run a patched Puppetmaster anyway, I can do what I > want :-) > > Unfortunately, it doesn''t solve my problem. > > I am trying to do the same thing as Gabriel Filion in this post: > http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d > > So, I have a nagios-target class, that defines a virtual resource: > > @@nagios_host { "$hostname": > use => "generic-host", > address => $fqdn, > alias => $hostname, > ensure => present, > hostgroups => [], > } > > and I would like to do something along the lines of this: in a different > class (not a subclass of nagios-target), for example in the class that > configures the MTA: > > Nagios_host [$hostname] { > hostgroups +> "mail-satellite-servers", > } > > which results in this error: > > "Only subclasses can override parameters at ..." > > which sounds logical, but... > > Is there any way to do what I want? I can''t really think of anything, > since (variable) scoping will always be in my way, as far as I can see... > > Best regards, > Martijn. > > > > > > > > > > > > > > > > > >> >> On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman <martijn@iphion.nl >> <mailto:martijn@iphion.nl>> wrote: >> >> Hi, >> >> A question for the devs. Will this: >> >> http://projects.puppetlabs.com/issues/4020 >> >> make it into a release any time soon? >> >> Best regards, >> Martijn. >> >> -- >> 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 >> <mailto:puppet-users@googlegroups.com>. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com >> <mailto:puppet-users%2Bunsubscribe@googlegroups.com>. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> -- >> 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. >-- 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.
Dude, I struggled with that for more than 6 months, and the position of the Puppet people was, "you''re doing it wrong". Since that didn''t help my problem I ended up doing it this way: 1) Create a new fact (see attached) that reports back to the master server on what classes are defined on the client (during the last run!). 2) Create a new function (see attached) that will compute the correct set of hostgroups from the class list 3) Create a new fact (see attached) that will determine if the client is a zone server (e.g. global zone) or if it''s a zone running on a server. 4) Use those to drive my Nagios configs. Here''s the relevant class fragment: @@nagios_host { $fqdn: alias => $hostname, address => $service_ipaddress, max_check_attempts => 3, contact_groups => "unix", hostgroups => $nagios_hostgroup_list, icon_image_alt => $operatingsystem, icon_image => "$operatingsystem.png", notifications_enabled => 1, statusmap_image => "$operatingsystem.gd2", tag => inline_template("<%=my_nagios_home.sub('' '',''_'')%>"), # Puppet doesn''t like tags with spaces?!? notes_url => $cprt_globalzone ? { global => "https://${hostname}-a.${my_domain}/", default => undef, }, parents => $cprt_globalzone ? { "" => undef, nil => undef, global => undef, default => "${cprt_globalzone}.${my_domain}", }, use => [ $productname ? { "Sun Fire X4140" => "host-x4140-template", default => "host-generic-template" }, "host-pnp-template" ], } On Mar 2, 2011, at 6:55 AM, Martijn Grendelman wrote:> On 02-03-11 14:49, Brian Gallew wrote: >> Sadly, signs point to "no". > > Too bad. But since I run a patched Puppetmaster anyway, I can do what I > want :-) > > Unfortunately, it doesn''t solve my problem. > > I am trying to do the same thing as Gabriel Filion in this post: > http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d > > So, I have a nagios-target class, that defines a virtual resource: > > @@nagios_host { "$hostname": > use => "generic-host", > address => $fqdn, > alias => $hostname, > ensure => present, > hostgroups => [], > } > > and I would like to do something along the lines of this: in a different > class (not a subclass of nagios-target), for example in the class that > configures the MTA: > > Nagios_host [$hostname] { > hostgroups +> "mail-satellite-servers", > } > > which results in this error: > > "Only subclasses can override parameters at ..." > > which sounds logical, but... > > Is there any way to do what I want? I can''t really think of anything, > since (variable) scoping will always be in my way, as far as I can see... > > Best regards, > Martijn. > > > > > > > > > > > > > > > > > >> >> On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman <martijn@iphion.nl >> <mailto:martijn@iphion.nl>> wrote: >> >> Hi, >> >> A question for the devs. Will this: >> >> http://projects.puppetlabs.com/issues/4020 >> >> make it into a release any time soon? >> >> Best regards, >> Martijn. >> >> -- >> 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 >> <mailto:puppet-users@googlegroups.com>. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com >> <mailto:puppet-users%2Bunsubscribe@googlegroups.com>. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> -- >> 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. > > -- > 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. >-- 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.
Hello, I finally abandoned the idea of having a group-based sane-looking Nagios configuration with puppet, because there are too many weirdnesses in Naginator. And unfortunately I can''t really bring any help with patches since I don''t write any ruby.. There are some great nagios modules out there which you could use, or from which you could borrow ideas. Generally speaking, I see that they tend to define services for each host and attach them directly to hosts. It''s big and clunky, but at least it works.. For example, in an sshd module, you would have something like: @@nagios_service { "${fqdn}_ssh": check_command => "check_ssh", host_name => $fqdn, } The biggest problem I have right now is that purging nagios resources doesn''t seem to erase anything, so my config gets messed up from time to time when nodes are taken out or things are moved around and I need to manullay remove nagios config files and have puppet regenerate them :\ On 11-03-02 09:55 AM, Martijn Grendelman wrote:> On 02-03-11 14:49, Brian Gallew wrote: >> Sadly, signs point to "no". > > Too bad. But since I run a patched Puppetmaster anyway, I can do what I > want :-) > > Unfortunately, it doesn''t solve my problem. > > I am trying to do the same thing as Gabriel Filion in this post: > http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d > > So, I have a nagios-target class, that defines a virtual resource: > > @@nagios_host { "$hostname": > use => "generic-host", > address => $fqdn, > alias => $hostname, > ensure => present, > hostgroups => [], > } > > and I would like to do something along the lines of this: in a different > class (not a subclass of nagios-target), for example in the class that > configures the MTA: > > Nagios_host [$hostname] { > hostgroups +> "mail-satellite-servers", > } > > which results in this error: > > "Only subclasses can override parameters at ..." > > which sounds logical, but... > > Is there any way to do what I want? I can''t really think of anything, > since (variable) scoping will always be in my way, as far as I can see... > >> On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman <martijn@iphion.nl >> <mailto:martijn@iphion.nl>> wrote: >> >> Hi, >> >> A question for the devs. Will this: >> >> http://projects.puppetlabs.com/issues/4020 >> >> make it into a release any time soon?-- Gabriel Filion -- 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.
I''ve found that Puppet/Naginator has the bad habit of occasionally breaking the Nagios config. Here''s how I worked around this: 1) When you collect your Nagios resource, store them all in a temporary directory (in my case, ~nagios/var/tmp) 2) Purge that directory with a cron job every night (so deleted resources disappear) 3) Create an exec that creates a ~nagios/etc/nagios-tmp.cfg by running sed on ~nagios/etc/nagios.cfg and changing directories appropriately. 4) Create an exec that pre-flights Nagios using the nagios-tmp.cfg (which checks the tmp dir) and, if successful, sync the files over into the real Nagios config directory. It''s a little clunky, but Nagios doesn''t ever break anymore. Remember that your pre-flight exec should require all the Nagios resources (so the files get updated first), and should always run if the contents of the tmp dir vary at all from the real target (diff is your friend here). Otherwise, the preflight may fail once and then never run again until the next time you make a substantive server change. On Mar 2, 2011, at 10:34 AM, Gabriel Filion wrote:> Hello, > > I finally abandoned the idea of having a group-based sane-looking Nagios > configuration with puppet, because there are too many weirdnesses in > Naginator. And unfortunately I can''t really bring any help with patches > since I don''t write any ruby.. > > There are some great nagios modules out there which you could use, or > from which you could borrow ideas. Generally speaking, I see that they > tend to define services for each host and attach them directly to hosts. > It''s big and clunky, but at least it works.. > > For example, in an sshd module, you would have something like: > > @@nagios_service { "${fqdn}_ssh": > check_command => "check_ssh", > host_name => $fqdn, > } > > > The biggest problem I have right now is that purging nagios resources > doesn''t seem to erase anything, so my config gets messed up from time to > time when nodes are taken out or things are moved around and I need to > manullay remove nagios config files and have puppet regenerate them :\ > > On 11-03-02 09:55 AM, Martijn Grendelman wrote: >> On 02-03-11 14:49, Brian Gallew wrote: >>> Sadly, signs point to "no". >> >> Too bad. But since I run a patched Puppetmaster anyway, I can do what I >> want :-) >> >> Unfortunately, it doesn''t solve my problem. >> >> I am trying to do the same thing as Gabriel Filion in this post: >> http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d >> >> So, I have a nagios-target class, that defines a virtual resource: >> >> @@nagios_host { "$hostname": >> use => "generic-host", >> address => $fqdn, >> alias => $hostname, >> ensure => present, >> hostgroups => [], >> } >> >> and I would like to do something along the lines of this: in a different >> class (not a subclass of nagios-target), for example in the class that >> configures the MTA: >> >> Nagios_host [$hostname] { >> hostgroups +> "mail-satellite-servers", >> } >> >> which results in this error: >> >> "Only subclasses can override parameters at ..." >> >> which sounds logical, but... >> >> Is there any way to do what I want? I can''t really think of anything, >> since (variable) scoping will always be in my way, as far as I can see... >> >>> On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman <martijn@iphion.nl >>> <mailto:martijn@iphion.nl>> wrote: >>> >>> Hi, >>> >>> A question for the devs. Will this: >>> >>> http://projects.puppetlabs.com/issues/4020 >>> >>> make it into a release any time soon? > > > -- > Gabriel Filion > > -- > 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. >-- 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 11-03-02 02:27 PM, Brian Gallew wrote:> I''ve found that Puppet/Naginator has the bad habit of occasionally breaking the Nagios config. Here''s how I worked around this: > 1) When you collect your Nagios resource, store them all in a temporary directory (in my case, ~nagios/var/tmp) > 2) Purge that directory with a cron job every night (so deleted resources disappear) > 3) Create an exec that creates a ~nagios/etc/nagios-tmp.cfg by running sed on ~nagios/etc/nagios.cfg and changing directories appropriately. > 4) Create an exec that pre-flights Nagios using the nagios-tmp.cfg (which checks the tmp dir) and, if successful, sync the files over into the real Nagios config directory. > > It''s a little clunky, but Nagios doesn''t ever break anymore. Remember that your pre-flight exec should require all the Nagios resources (so the files get updated first), and should always run if the contents of the tmp dir vary at all from the real target (diff is your friend here). Otherwise, the preflight may fail once and then never run again until the next time you make a substantive server change.hmm, that''s an interesting approach. it sounds like it requires a lot of exec magic but it does cover for the config breakages and also for purging resources. When I finally get some free time, I''ll look into implementing that. Thanks for the hint. -- Gabriel Filion -- 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 03-03-11 08:04, Gabriel Filion wrote:> On 11-03-02 02:27 PM, Brian Gallew wrote: >> I''ve found that Puppet/Naginator has the bad habit of occasionally >> breaking the Nagios config. Here''s how I worked around this: 1) When >> you collect your Nagios resource, store them all in a temporary >> directory (in my case, ~nagios/var/tmp) 2) Purge that directory with >> a cron job every night (so deleted resources disappear) 3) Create an >> exec that creates a ~nagios/etc/nagios-tmp.cfg by running sed on >> ~nagios/etc/nagios.cfg and changing directories appropriately. 4) >> Create an exec that pre-flights Nagios using the nagios-tmp.cfg >> (which checks the tmp dir) and, if successful, sync the files over >> into the real Nagios config directory. >> >> It''s a little clunky, but Nagios doesn''t ever break anymore. >> Remember that your pre-flight exec should require all the Nagios >> resources (so the files get updated first), and should always run if >> the contents of the tmp dir vary at all from the real target (diff is >> your friend here). Otherwise, the preflight may fail once and then >> never run again until the next time you make a substantive server >> change. > > hmm, that''s an interesting approach. it sounds like it requires a lot > of exec magic but it does cover for the config breakages and also for > purging resources. When I finally get some free time, I''ll look into > implementing that. Thanks for the hint.Nice! Currently, our Nagios config lives in a Git repository. Before pulling changes to /etc/nagios3 and restarting Nagios, we pull them to a temp dir, and with a nagios.conf with adapted paths, we test the config, just like you describe. This is all pretty much automated, so it''s something I have been thinking about, how to implement that in Puppet. Step 3 in your description is -in our setup- unnecessary, we just keep the test-config in our repo as well. Thanks. Best regards, Martijn. -- 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.