Re: [Puppet Users] Nagios Puppet

[Sans]

Hi steve,

So, you have all the services defined statically on the Nagios server? 
That setup only works, I think, if you install your Nagios server at the 
very end of your deployment process and all the clients are up and ready 
before the server. If you do a parallel deployment, then there is a very 
good chance that Nagios will refuse to start at the first run. Cheers!! 


On Friday, June 28, 2013 3:57:09 PM UTC+1, Steve J wrote:

 In my experience, exporting nagios_command resources doesn't work so well. 
 What I've found works best, is to define nagios_command{}'s directly on the 
 server, rather than exporting and collecting them there later.

 In my setup, the only resource that export is the nagios_host. I define 
 commands and services on the server, and assign the services to hostgroups. 
 Hosts then get service checks assigned to them based on which hostgroups I 
 put them in (usually done via the hosts role definition). I find that this 
 works well, since it doesn't leave me with multiple exported nagios_service 
 resources for every single host, that will eventually need to get cleaned 
 out of PuppetDB when the host is no longer in service.

 -Steve



-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Nagios Puppet Module - Multiple Service File Permissions Issues

[phundisk]

I am using the nagios puppet module to create and manage services via 
stored configurations.  The original module, stored all service cheks in 
one file and this was causing my puppet run on my nagios server to take 30+ 
minutes.  I have read here (
http://pieter.barrezeele.be/2009/05/11/puppet-and-nagios/) that if you 
split up the services files into multiple, puppet can run faster since it 
doesn't have to look through one huge file.  I would like to split this up 
by host.  (i.e. nagios_service_$::fqdn.cfg)  One issue I am running into, 
is that the file that is created  using the target method has the 
permissions of root:root 600, and thus nagios will crash when trying to 
read it since it does not have permissions.  The original nagios_service 
file is controlled via the following...  

I could add each hostname below, but that does not scale well.  Is there 
another way in which this can be more easily managed?

 file{[ ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_command.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_contact.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_contactgroup.cfg,
   ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_host.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostdependency.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostescalation.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostextinfo.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostgroup.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_hostgroupescalation.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_service.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_servicedependency.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_serviceescalation.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_serviceextinfo.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_servicegroup.cfg,
  
 ${nagios::defaults::vars::int_cfgdir}/conf.d/nagios_timeperiod.cfg ]:
ensure = file,
replace = false,
notify = Service['nagios'],
mode = 0644, owner = root, group = 0;
}



-- 
_
This email and any files transmitted with it are confidential and intended 
solely for the addressee.  If you received this email in error, please do 
not disclose the contents to anyone; kindly notify the sender by return 
email and delete this email and any attachments from your system.

© 2011 Currensee Inc. is a member of the National Futures Association (NFA) 
Member ID 0403251 | Over the counter retail foreign currency (Forex) 
trading may involve significant risk of loss. It is not suitable for all 
investors and you should make sure you understand the risks involved before 
trading and seek independent advice if necessary. Performance, strategies 
and charts shown are not necessarily predictive of any particular result 
and past performance is no indication of future results. Investor returns 
may vary from Trade Leader returns based on slippage, fees, broker spreads, 
volatility or other market conditions.

Currensee Inc | 54 Canal St 4th Floor | Boston, MA 02114 | +1.617.624.3824

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] nagios puppet dynamic moniroting setup - unable to populate host_resource files

[Chucks]

Hi all - I am setting up dynamic monitoring using puppet/nagios modules. 

I am following this doc to achieve basic setup 
http://www.allgoodbits.org/articles/view/32

Here is my configs


[root@ip-10-172-161-25 puppet]# cat modules/nagios/manifests/init.pp
class nagios::server {
  package { [nagios,nagios-plugins,nagios-plugins-nrpe]:
ensure = installed,
  }
  service { nagios:
ensure  = running,
enable  = true,
require = Exec['make-nag-cfg-readable'],
  }

  # This is because puppet writes the config files so nagios can't read them
  exec {'make-nag-cfg-readable':
command = /bin/find /etc/nagios -type f -name '*cfg' | xargs chmod 
+r,
  }

  file { 'resource-d':
path   = '/etc/nagios/resource.d',
ensure = directory,
owner  = 'nagios',
  }

  # Collect the nagios_host resources
  Nagios_host || {
require = File[resource-d],
notify  = [Exec[make-nag-cfg-readable],Service[nagios]],
  }
}


===

[root@ip-10-172-161-25 puppet]# cat modules/nagios/manifests/export.pp 
class nagios::export {
  @@nagios_host { $::fqdn:
address   = $::ipaddress,
check_command = 'check-host-alive!3000.0,80%!5000.0,100%!10',
hostgroups= 'all-servers',
target= /etc/nagios/resource.d/host_${::fqdn}.cfg
  }
}

=
node.pp

#nagios server
node 'ip-10-198-23-24.us-west-1.compute.internal' {
  include nagios::server
}

=
site.pp

[root@ip-10-172-161-25 puppet]# cat manifests/site.pp 
import 'nodes.pp'
node default {
  include nagios::export
}
==

Puppet run succeeds on both nagios client and nagios server, but it do not 
populate host.cfg files on nagios server /etc/nagios/resource.d/*



Debug run on nagios server:

[root@ip-10-198-23-24 resource.d]# puppet agent -t --debug
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Puppet::Type::User::ProviderLdap: true value when expecting false
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl 
does not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not 
exist
debug: Failed to load library 'rubygems' for feature 'rubygems'
debug: Failed to load library 'selinux' for feature 'selinux'
debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/client_data]: Autorequiring 
File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state/graphs]: Autorequiring 
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/state/last_run_summary.yaml]: Autorequiring 
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring 
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/state/last_run_report.yaml]: Autorequiring 
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/ssl/private]: Autorequiring 
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring 
File[/var/lib/puppet/ssl]
debug: 
/File[/var/lib/puppet/ssl/public_keys/ip-10-198-23-24.us-west-1.compute.internal.pem]:
 
Autorequiring File[/var/lib/puppet/ssl/public_keys]
debug: /File[/var/run/puppet/agent.pid]: Autorequiring File[/var/run/puppet]
debug: 
/File[/var/lib/puppet/ssl/certs/ip-10-198-23-24.us-west-1.compute.internal.pem]:
 
Autorequiring File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/clientbucket]: Autorequiring 
File[/var/lib/puppet]
debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
debug: 
/File[/var/lib/puppet/ssl/private_keys/ip-10-198-23-24.us-west-1.compute.internal.pem]:
 
Autorequiring File[/var/lib/puppet/ssl/private_keys]
debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring 
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring 
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/client_yaml]: Autorequiring 
File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring 
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring 
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring 
File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/state/resources.txt]: Autorequiring 
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/classes.txt]: Autorequiring 
File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
debug: Finishing transaction 70124700385060
debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring 
File[/var/lib/puppet/ssl]
debug: 
/File[/var/lib/puppet/ssl/private_keys/ip-10-198-23-24.us-west-1.compute.internal.pem]:
 
Autorequiring File[/var/lib/puppet/ssl/private_keys]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring 

Re: [Puppet Users] Nagios Puppet

[Stephen Jahl]

In my experience, exporting nagios_command resources doesn't work so well.
What I've found works best, is to define nagios_command{}'s directly on the
server, rather than exporting and collecting them there later.

In my setup, the only resource that export is the nagios_host. I define
commands and services on the server, and assign the services to hostgroups.
Hosts then get service checks assigned to them based on which hostgroups I
put them in (usually done via the hosts role definition). I find that this
works well, since it doesn't leave me with multiple exported nagios_service
resources for every single host, that will eventually need to get cleaned
out of PuppetDB when the host is no longer in service.

-Steve



On Thu, Jun 27, 2013 at 12:07 PM, Christian Reiß
reiss.symgen...@gmail.comwrote:

 Hello folks,

 I am currently using Puppet to forge the nagios configuration files. Using
 exported ressources it really works well - to a point.

 The one thing I am banging my head against is the service definitions. The
 services use stuff like remote-nrpe-zombie-procs, which of course, is not
 defined anywhere:

 define service {
 ## --PUPPET_NAME-- (called '_naginator_name' in the
 manifest)check_zombie_procs_gaming
 useremote-nrpe-zombie-procs
 host_name  gaming.alpha-labs.net
 }

 So far I am letting puppet generate the three configs:

 nagios_host.cfg
 nagios_hostextinfo.cfg
 nagios_service.cfg

 Tho for this to work I would need a corresponding commands.cfg and all the
 Howtos out there do not seem to have my problem. The important snipplet
 from my config would be this:


  Nagios_host || {
  require = File[resource-d],
  notify = Service[icinga],
  }

  Nagios_service || {
  require = File[resource-d],
  notify = Service[icinga],
  }

  Nagios_hostextinfo || {
  require = File[resource-d],
  notify = Service[icinga],
  }

  Nagios_command || {
  require = File[resource-d],
  notify = Service[icinga],
  }


 After banging my head for 3 evenings on this I really need your help.
 Thanks for any pointers.

 -Chris.

  --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to puppet-users+unsubscr...@googlegroups.com.
 To post to this group, send email to puppet-users@googlegroups.com.
 Visit this group at http://groups.google.com/group/puppet-users.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Nagios Puppet

[Jakov Sosic]

On 06/28/2013 04:57 PM, Stephen Jahl wrote:

In my experience, exporting nagios_command resources doesn't work so
well. What I've found works best, is to define nagios_command{}'s
directly on the server, rather than exporting and collecting them there
later.

In my setup, the only resource that export is the nagios_host. I define
commands and services on the server, and assign the services to
hostgroups. Hosts then get service checks assigned to them based on
which hostgroups I put them in (usually done via the hosts role
definition). I find that this works well, since it doesn't leave me with
multiple exported nagios_service resources for every single host, that
will eventually need to get cleaned out of PuppetDB when the host is no
longer in service.


Yeah, that approach seems better performance-wise. Tank you for sharing :)


--
Jakov Sosic
www.srce.unizg.hr

--
You received this message because you are subscribed to the Google Groups Puppet 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Nagios Puppet

[Christian Reiß]

Hello folks,

I am currently using Puppet to forge the nagios configuration files. Using 
exported ressources it really works well - to a point.

The one thing I am banging my head against is the service definitions. The 
services use stuff like remote-nrpe-zombie-procs, which of course, is not 
defined anywhere:

define service {
## --PUPPET_NAME-- (called '_naginator_name' in the 
manifest)check_zombie_procs_gaming
useremote-nrpe-zombie-procs
host_name  gaming.alpha-labs.net
}

So far I am letting puppet generate the three configs:

nagios_host.cfg
nagios_hostextinfo.cfg
nagios_service.cfg

Tho for this to work I would need a corresponding commands.cfg and all the 
Howtos out there do not seem to have my problem. The important snipplet 
from my config would be this:


 Nagios_host || {
 require = File[resource-d],
 notify = Service[icinga],
 }

 Nagios_service || {
 require = File[resource-d],
 notify = Service[icinga],
 }

 Nagios_hostextinfo || {
 require = File[resource-d],
 notify = Service[icinga],
 }

 Nagios_command || {
 require = File[resource-d],
 notify = Service[icinga],
 }


After banging my head for 3 evenings on this I really need your help.
Thanks for any pointers.

-Chris.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Nagios Puppet

[Pete Brown]

Shameless plug.
I wrote a module to do pretty much what you are trying to achieve.
http://forge.puppetlabs.com/rendhalver/monitoring
It currently works on CentOS and Fedora. Debian/Ubuntu support is in progress.
I also have a couple of other modules for managing nrpe and icinga
Feel free to have a look at the code on github for inspiration even if
you don't install it.

Pete.

On 28 June 2013 02:07, Christian Reiß reiss.symgen...@gmail.com wrote:
 Hello folks,

 I am currently using Puppet to forge the nagios configuration files. Using
 exported ressources it really works well - to a point.

 The one thing I am banging my head against is the service definitions. The
 services use stuff like remote-nrpe-zombie-procs, which of course, is not
 defined anywhere:

 define service {
 ## --PUPPET_NAME-- (called '_naginator_name' in the manifest)
 check_zombie_procs_gaming
 useremote-nrpe-zombie-procs
 host_name  gaming.alpha-labs.net
 }

 So far I am letting puppet generate the three configs:

 nagios_host.cfg
 nagios_hostextinfo.cfg
 nagios_service.cfg

 Tho for this to work I would need a corresponding commands.cfg and all the
 Howtos out there do not seem to have my problem. The important snipplet from
 my config would be this:


  Nagios_host || {
  require = File[resource-d],
  notify = Service[icinga],
  }

  Nagios_service || {
  require = File[resource-d],
  notify = Service[icinga],
  }

  Nagios_hostextinfo || {
  require = File[resource-d],
  notify = Service[icinga],
  }

  Nagios_command || {
  require = File[resource-d],
  notify = Service[icinga],
  }


 After banging my head for 3 evenings on this I really need your help.
 Thanks for any pointers.

 -Chris.

 --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to puppet-users+unsubscr...@googlegroups.com.
 To post to this group, send email to puppet-users@googlegroups.com.
 Visit this group at http://groups.google.com/group/puppet-users.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.