Re: [icinga-users] Using check_multi with Icinga2

[Michael Friedrich]

> On 14 Jul 2016, at 21:08, Michael Martinez  wrote:
>
> On Thu, Jul 14, 2016 at 12:48 AM, Michael Friedrich
>  wrote:
>> var hg_name = “myhostgroup"
>> var data = []
>> for (h in get_objects(Host)) {
>>  if (hg_name in h.groups) {
>>data.add(h.name)
>>  }
>> }
>
> Ok, thanks for the tip.
>
> Now another question: let's say I have an array or dictionary that
> contains a list of arbitrary names. I want to create a HostGroup
> Object for each name and then assign to hosts. Can Icinga do this at
> startup?

const MyHGNames = [ “hg1”, “hg2” ]

for (hg in MyHGNames) {
   object HostGroup hg {
 assign where ...
  }
}

Something like this. This comes in handy if you want to generate hosts as well. 
Though it makes your config a bit tad more difficult to read :)

We’re using such methods to simply generate test config in our test labs (e.g. 
https://github.com/Icinga/icingaweb2/blob/master/.puppet/profiles/icinga2_dev/files/conf.d/test-config.conf)

Kind regards,
Michael


> ___
> icinga-users mailing list
> icinga-users@lists.icinga.org
> https://lists.icinga.org/mailman/listinfo/icinga-users


-- 
Michael Friedrich, DI (FH)
Senior Developer

NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
Tel: +49 911 92885-0 | Fax: +49 911 92885-77
CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461
http://www.netways.de | michael.friedr...@netways.de

** OSBConf 2016 - September - osbconf.org **
** OSMC 2016 - November - netways.de/osmc **
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

[icinga-users] Icinga2: Command scheduling on remote agents

[Andreas Maus]

Hi .*

After several years of Nagios/Icinga I've started the journey
into the wild, wild world of Icinga 2 ;)

I've setup a simple setup. A central server ("www") is running Icinga 2
(2.4.10). Clients (e.g "lu-kthu")  are configured as remote agents ("Command 
Execution
Bridge"). Some checks (e.g. checking for updates using apt) should be
started at a different interval.

If I understand the configuration correctly, the master connects to the
remote clients and execute the commands. (Or am I wrong?)

Unfortunately this does not work on the remote agents if a service uses
a different scheduling interval, although icinga2 object list show the
desired check_command interval:

root@www:~# icinga2 object list --name='lu-kthu.badphish.ypbind.de!remote_apt'
Object 'lu-kthu.badphish.ypbind.de!remote_apt' of type 'Service':
  % declared in '/etc/icinga2/conf.d/services/apt.conf', lines 1:0-1:25
  * __name = "lu-kthu.badphish.ypbind.de!remote_apt"
  * action_url = ""
  * check_command = "apt"
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 4:2-4:22
  * check_interval = 86400
% = modified in '/etc/icinga2/conf.d/templates/service_daily_check.conf', 
lines 3:3-3:22
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 6:2-6:21
  * check_period = ""
  * check_timeout = null
  * command_endpoint = "lu-kthu.badphish.ypbind.de"
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 10:3-10:30
  * display_name = "APT"
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 3:2-3:21
  * enable_active_checks = true
  * enable_event_handler = true
  * enable_flapping = false
  * enable_notifications = true
  * enable_passive_checks = true
  * enable_perfdata = true
  * event_command = ""
  * flapping_threshold = 30
  * groups = [ ]
  * host_name = "lu-kthu.badphish.ypbind.de"
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 1:0-1:25
  * icon_image = ""
  * icon_image_alt = ""
  * max_check_attempts = 3
% = modified in '/etc/icinga2/conf.d/templates/service_daily_check.conf', 
lines 2:3-2:24
  * name = "remote_apt"
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 1:0-1:25
  * notes = ""
  * notes_url = ""
  * package = "_etc"
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 1:0-1:25
  * retry_interval = 1800
% = modified in '/etc/icinga2/conf.d/templates/service_daily_check.conf', 
lines 4:3-4:22
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 7:2-7:21
  * templates = [ "remote_apt", "service-daily-check" ]
% = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 1:0-1:25
% = modified in '/etc/icinga2/conf.d/templates/service_daily_check.conf', 
lines 1:0-1:37
  * type = "Service"
  * vars
* apt_upgrade = false
  % = modified in '/etc/icinga2/conf.d/services/apt.conf', lines 5:2-5:25
  * volatile = false
  * zone = ""

The checks on the remote clients are not scheduled avery 24 hour:

root@lu-kthu:~# grep check_apt /var/log/icinga2/debug.log
[...]
[2016-07-15 19:28:08 +0200] notice/Process: Running command 
'/usr/lib/nagios/plugins/check_apt' '--upgrade' 'false': PID 27519
[2016-07-15 19:28:09 +0200] notice/Process: PID 27519 
('/usr/lib/nagios/plugins/check_apt' '--upgrade' 'false') terminated with exit 
code 0
[2016-07-15 19:33:38 +0200] notice/Process: Running command 
'/usr/lib/nagios/plugins/check_apt' '--upgrade' 'false': PID 27702
[2016-07-15 19:33:39 +0200] notice/Process: PID 27702 
('/usr/lib/nagios/plugins/check_apt' '--upgrade' 'false') terminated with exit 
code 0
[2016-07-15 19:39:08 +0200] notice/Process: Running command 
'/usr/lib/nagios/plugins/check_apt' '--upgrade' 'false': PID 27924
[2016-07-15 19:39:09 +0200] notice/Process: PID 27924 
('/usr/lib/nagios/plugins/check_apt' '--upgrade' 'false') terminated with exit 
code 0
[...]

Definitions for the host on the master:

object Endpoint "lu-kthu.badphish.ypbind.de" {
host = "lu-kthu.badphish.ypbind.de"
}

object Zone "lu-kthu.badphish.ypbind.de" {
endpoints = [ "lu-kthu.badphish.ypbind.de" ]
parent = "www.badphish.ypbind.de"
}
object Host "lu-kthu.badphish.ypbind.de" {
import "generic-host"
display_name = "lu-kthu"
address = "lu-kthu.badphish.ypbind.de"

// Meta data
vars.kvm = true
vars.os = "Linux"
vars.distributor = "Debian"
vars.icinga_agent = true
vars.services = [ "smtp", "ssh" ]
}


and service:

apply Service "remote_apt" {
import "service-daily-check"
display_name = "APT"
check_command = "apt"
vars.apt_upgrade = false
check_interval = 24h
retry_interval = 30m

if (host.name != NodeName) {
command_endpoint = host.name
}

assign where host.vars.os == "Linux" && host.vars.distributor == 
"Debian" && (host.vars.icinga_agent || host.name == NodeName)
}


with "service-daily-check" as:

template Service "service-dail

Re: [icinga-users] Satellite setup - certificate problem

[Stephan Tesch]

Am 13.07.2016 um 19:19 schrieb Michael Friedrich:

Hi Michael,
>> Any chance to get the openssl error included in the Icinga error
>> messsage?
>>
>
> If you can provide a way to reliably test that scenario (certs, configs)
> and we only need to fiddle with the error message passed inside the
> code, feel free to open a feature request.
>

I nailed it down to the following setting within the CA config:

nsCertType = server

If that is set while the certificate is signed, the validation fails.

I could provide the appropriate openssl config, commands to generate the
certs and so on, but I'm not sure how you will test this. The certs need
to have a valid CN and you would need to have at least a master and a
satellite. If you have static hostnames for that, I can just provide the
certificates, that would be easier :)

Best regards,
Stephan



___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users