Puppet users - Jul 2009 - Notifying a service when exported resources go away

Hi,

I''m working with nagios, and if I''m de-configuring a server
manually, I''d like
to have the monitoring system not complain about it vanishing.

So, for each host I have:

    @@nagios_host { "$fqdn":
        use => "generic-host",
        address => $fqdn,
        contact_groups => "itstaff",
        notify => Service["nagios3"]
    }

and then on the Nagios server I have:

    resources { "nagios_host":
        purge => true,
        notify => Service["nagios3"]
    }

    Nagios_host <<| |>>

If I don''t have a notify on the resources entry, the nagios host
entries go
away, but nagios doesn''t refresh.  If I have it on the resources entry,
it
makes the service depend on it, and so won''t purge:

"Service[nagios3] still depends on me -- not purging"

Is it possible to accomplish what I''m trying to do?  If so, how?

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerlach@feds.uwaterloo.ca

--~--~---------~--~----~------------~-------~--~----~
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, Jul 24, 2009 at 12:47 PM, Eric Gerlach
<egerlach@feds.uwaterloo.ca>wrote:
>
> Hi,
>
> I''m working with nagios, and if I''m de-configuring a
server manually, I''d
> like
> to have the monitoring system not complain about it vanishing.
>
> So, for each host I have:
>
>    @@nagios_host { "$fqdn":
>        use => "generic-host",
>        address => $fqdn,
>        contact_groups => "itstaff",
>        notify => Service["nagios3"]
>    }
>
> and then on the Nagios server I have:
>
>    resources { "nagios_host":
>        purge => true,
>        notify => Service["nagios3"]
>    }
>
>    Nagios_host <<| |>>
>
> If I don''t have a notify on the resources entry, the nagios host
entries go
> away, but nagios doesn''t refresh.  If I have it on the resources
entry, it
> makes the service depend on it, and so won''t purge:
>
> "Service[nagios3] still depends on me -- not purging"
>
> Is it possible to accomplish what I''m trying to do?  If so, how?
>
> Cheers,
>
> --
> Eric Gerlach, Network Administrator
> Federation of Students
> University of Waterloo
> p: (519) 888-4567 x36329
> e: egerlach@feds.uwaterloo.ca
>
> >
>
Eric the most straight forward mechanism is to purge all the resources
associated with the host that is being decommissioned.  There is a script to
do this attached to the wiki page for storedconfigs.
http://reductivelabs.com/trac/puppet/attachment/wiki/UsingStoredConfiguration/kill_node_in_storedconfigs_db.rb

Cheers,
Teyo

--~--~---------~--~----~------------~-------~--~----~
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, Jul 24, 2009 at 04:09:22PM -0700, Teyo Tyree
wrote:
> On Fri, Jul 24, 2009 at 12:47 PM, Eric Gerlach
> <egerlach@feds.uwaterloo.ca>wrote:
> 
> >
> > Hi,
> >
> > I''m working with nagios, and if I''m de-configuring a
server manually, I''d
> > like
> > to have the monitoring system not complain about it vanishing.
> >
> > So, for each host I have:
> >
> >    @@nagios_host { "$fqdn":
> >        use => "generic-host",
> >        address => $fqdn,
> >        contact_groups => "itstaff",
> >        notify => Service["nagios3"]
> >    }
> >
> > and then on the Nagios server I have:
> >
> >    resources { "nagios_host":
> >        purge => true,
> >        notify => Service["nagios3"]
> >    }
> >
> >    Nagios_host <<| |>>
> >
> > If I don''t have a notify on the resources entry, the nagios
host entries go
> > away, but nagios doesn''t refresh.  If I have it on the
resources entry, it
> > makes the service depend on it, and so won''t purge:
> >
> > "Service[nagios3] still depends on me -- not purging"
> >
> > Is it possible to accomplish what I''m trying to do?  If so,
how?
>
> Eric the most straight forward mechanism is to purge all the resources
> associated with the host that is being decommissioned.  There is a script
to
> do this attached to the wiki page for storedconfigs.
>
http://reductivelabs.com/trac/puppet/attachment/wiki/UsingStoredConfiguration/kill_node_in_storedconfigs_db.rb
But if I do this, it still doesn''t notify the nagios service, so it
will
continue to monitor them (and complain to me that they''re gone) until I
restart
it.  So though that''s a nice way to purge the DB, it doesn''t
really help my
problem.

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerlach@feds.uwaterloo.ca

--~--~---------~--~----~------------~-------~--~----~
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 Tue, Jul 28, 2009 at 11:19:07AM -0400, Eric Gerlach
wrote:
> 
> But if I do this, it still doesn''t notify the nagios service, so
it will
> continue to monitor them (and complain to me that they''re gone)
until I restart
> it.  So though that''s a nice way to purge the DB, it
doesn''t really help my
> problem.
I have to say, I''m unconvinced by the whole storedconfigs mechanism,
particularly for this kind of thing.  If you''re using puppet to
configure most or all aspects of your hosts on the network, then your
central puppet config already stores enough information about all your
hosts to generate a nagios config centrally and push it to the
monitoring host.  Pushing all this information back from the clients to
the puppetmaster and then out again seems to me to be desperately
fragile and just asking for trouble.

-- 
Bruce

I object to intellect without discipline.  I object to power without
constructive purpose. -- Spock

--~--~---------~--~----~------------~-------~--~----~
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 28 Jul 2009, at 9:39 AM, Bruce Richardson wrote:
> I have to say, I''m unconvinced by the whole storedconfigs
mechanism,
> particularly for this kind of thing.  If you''re using puppet to  
> configure most or all aspects of your hosts on the network, then  
> your central puppet config already stores enough information about  
> all your hosts to generate a nagios config centrally and push it to  
> the monitoring host.  Pushing all this information back from the  
> clients to the puppetmaster and then out again seems to me to be  
> desperately fragile and just asking for trouble.
For me, the killer app for storeconfigs is exported SSH host keys.   
That''s information that my puppetmaster *doesn''t* have in its
manifests, and needs to collect from clients.  That said, sshkey  
resources are giving me trouble in 0.24.8, with puppetd logging errors  
such as:

	puppetd[6170]: Got an uncaught exception of type ArgumentError: Field  
''name'' is required

And unusual messages like:

	puppetd[6170]: Sshkey absent found in both parsed and parsed;  
skipping the parsed version

I''ve not yet had time to track down this issue (and should probably do
so in the 0.25 beta, anyway), but I wonder if anyone else has seen this.

-- 
Ian Ward Comfort <icomfort@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Eric Gerlach wrote:
> On Fri, Jul 24, 2009 at 04:09:22PM -0700, Teyo Tyree wrote:
>> On Fri, Jul 24, 2009 at 12:47 PM, Eric Gerlach
>> <egerlach@feds.uwaterloo.ca>wrote:
>>
>>> Hi,
>>>
>>> I''m working with nagios, and if I''m
de-configuring a server manually, I''d
>>> like
>>> to have the monitoring system not complain about it vanishing.
>>>
>>> So, for each host I have:
>>>
>>>    @@nagios_host { "$fqdn":
>>>        use => "generic-host",
>>>        address => $fqdn,
>>>        contact_groups => "itstaff",
>>>        notify => Service["nagios3"]
>>>    }
>>>
>>> and then on the Nagios server I have:
>>>
>>>    resources { "nagios_host":
>>>        purge => true,
>>>        notify => Service["nagios3"]
>>>    }
>>>
>>>    Nagios_host <<| |>>
>>>
>>> If I don''t have a notify on the resources entry, the
nagios host entries go
>>> away, but nagios doesn''t refresh.  If I have it on the
resources entry, it
>>> makes the service depend on it, and so won''t purge:
>>>
>>> "Service[nagios3] still depends on me -- not purging"
>>>
>>> Is it possible to accomplish what I''m trying to do?  If
so, how?
>> Eric the most straight forward mechanism is to purge all the resources
>> associated with the host that is being decommissioned.  There is a
script to
>> do this attached to the wiki page for storedconfigs.
>>
http://reductivelabs.com/trac/puppet/attachment/wiki/UsingStoredConfiguration/kill_node_in_storedconfigs_db.rb
> 
> But if I do this, it still doesn''t notify the nagios service, so
it will
> continue to monitor them (and complain to me that they''re gone)
until I restart
> it.  So though that''s a nice way to purge the DB, it
doesn''t really help my
> problem.
Notify from the containing directory using "checksum => mtime".
It''ll
change when a file is deleted from it.

Regards, DavidS


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Ian Ward Comfort wrote:
> On 28 Jul 2009, at 9:39 AM, Bruce Richardson wrote:
>> I have to say, I''m unconvinced by the whole storedconfigs
mechanism,
>> particularly for this kind of thing.  If you''re using puppet
to
>> configure most or all aspects of your hosts on the network, then  
>> your central puppet config already stores enough information about  
>> all your hosts to generate a nagios config centrally and push it to  
>> the monitoring host.  Pushing all this information back from the  
>> clients to the puppetmaster and then out again seems to me to be  
>> desperately fragile and just asking for trouble.
> 
> For me, the killer app for storeconfigs is exported SSH host keys.   
> That''s information that my puppetmaster *doesn''t* have in
its
> manifests, and needs to collect from clients.  That said, sshkey  
> resources are giving me trouble in 0.24.8, with puppetd logging errors  
> such as:
> 
> 	puppetd[6170]: Got an uncaught exception of type ArgumentError: Field  
> ''name'' is required
> 
> And unusual messages like:
> 
> 	puppetd[6170]: Sshkey absent found in both parsed and parsed;  
> skipping the parsed version
> 
> I''ve not yet had time to track down this issue (and should
probably do
> so in the 0.25 beta, anyway), but I wonder if anyone else has seen this.
I''m running 0.24.8-1 on Debian etch and lenny and I''ve never
seen
something similar.


Regards, DavidS

--~--~---------~--~----~------------~-------~--~----~
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 28 Jul 2009, at 11:00 PM, David Schmitt wrote:
> Ian Ward Comfort wrote:
>> For me, the killer app for storeconfigs is exported SSH host keys.   
>> That''s information that my puppetmaster *doesn''t*
have in its
>> manifests, and needs to collect from clients.  That said, sshkey  
>> resources are giving me trouble in 0.24.8, with puppetd logging  
>> errors such as:
>>
>> 	puppetd[6170]: Got an uncaught exception of type ArgumentError:  
>> Field ''name'' is required
>>
>> And unusual messages like:
>>
>> 	puppetd[6170]: Sshkey absent found in both parsed and parsed;  
>> skipping the parsed version
>>
>> I''ve not yet had time to track down this issue (and should
probably
>> do so in the 0.25 beta, anyway), but I wonder if anyone else has  
>> seen this.
>
> I''m running 0.24.8-1 on Debian etch and lenny and I''ve
never seen
> something similar.
Hunh -- thanks for the datapoint.  FWIW, this manifest is enough to  
cause the above exception for me on RHEL5.3, with Puppet  
0.24.8-1.el5.1 from EPEL:

	sshkey { ''host.example.com'': type => rsa, key  =>
''foo'' }

I''ll try this tomorrow on a fresh machine with the beta, and submit a  
ticket, I suppose, if I see the same behavior.

-- 
Ian Ward Comfort <icomfort@rescomp.stanford.edu>
System Administrator, Student Computing, Stanford University


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---