Re: [icinga-users] var and locals keywords

[Kai Nothdurft]

Hi Tobias,
>>> On 23.11.2017 at 13:31, Tobias Koeck  wrote:
[...]
> just checked it out. It's possible to create a local variable with
> 
> locals.temp = a * b
> instead of
> var temp = a * b.

great, that you shared your test-results. Thanks.

> The usage of the keywords locals, this and globals aren't necessary just
> for readability. As far as I have read there is a priority from locals to
> this to globals variables. If you just write
> 
> 'something ...' = temp
> 
> it will check out the different scopes and gets the first that fits.

That's correct. You know it, Icinga2 knows it. Some other girl/guy, reading 
your config may not know it. So even when accessing a local variable, it may be 
good practice, to prepend it with "locals." when you have variables with the 
same name in different scopes. With "just for readability" I only meant your 
special case of using "locals" for a local variable.

> With the keyword you can force Icinga 2 to take a specific scope variable.

Jepp. Again, if you have a variable with the same name in global- and in 
local-scope, you have to prepend it with "globals.", to acces the one in the 
global-space. You dont' have to use "locals." to access the one in the local 
scope, but you CAN if you whish.

Hope I clarified it a little.

best regards
Kai



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

Re: [icinga-users] var and locals keywords

[Kai Nothdurft]

Hi Tobias,

AFAIK the usage of the keyword "locals" is more or less for readability. I'm 
not sure, if you can create the variable using your second example, but you can 
access it in your function using "locals.temp" afterwards. If you have already 
created variables named "temp" in different scopes, e.g. in global and in local 
scope, Icinga2 will use automatically the variable from the local scope, unless 
you use the "globals" specifier (globals.temp). The use of "locals.temp" to 
access the variable named "temp" in the local scope would make it more readable 
but otherwise makes no difference.

best regards
Kai


>>> On 23.11.2017 at 09:48, Tobias Koeck  wrote:
> Hi Kai,
> 
> thanks for the answer.
> 
> I did read the 'manual / website documentation several times and I have
> understood the scope of local variables.
> 
> It's possible to write the function either with
> 
>  function multiply(a, b) {
>var temp = a * b
>return temp
>  }
> 
> or with
> 
>  function multiply(a, b) {
>locals.temp = a * b
>return temp
>  }
> 
> Both 'creates' the local variable temp if it isn't available? So why use
> var if you can use locals.varname, too?
> 
> Greetings
> Tobias


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

Re: [icinga-users] var and locals keywords

[Kai Nothdurft]

RTFM ;)



The *local* scope contains variables which only exist during the
invocation of the current function, object or apply statement. *Local*
variables can be declared using the var keyword:

 function multiply(a, b) {
   var temp = a * b
   return temp
 }

Each time the multiply function is invoked a new temp variable is used
which is in no way related to previous invocations of the function.

When setting a variable which has not previously been declared as local
using the var keyword the *this* scope is used.
The *this* scope refers to the current object which the function or
object/apply statement operates on.

 object Host "localhost" {
   check_interval = 5m
 }

In this example the this scope refers to the *localhost* object. The
check_interval attribute is set for this particular host.
You can explicitly access the *this* scope using the this keyword:

 object Host "localhost" {
   var check_interval = 5m

   /* This explicitly specifies that the attribute should be set
* for the host, if we had omitted `this.` the (poorly named)
* local variable `check_interval` would have been modified
instead.
*/
   this.check_interval = 1m
 }

Similarly the keywords *locals* and *globals* are available to access
the local and global scope. <- !


Source:

- Chapter "Variable Scopes".

Gruss
  Kai


>>> On 22.11.2017 at 18:59, Tobias Koeck 
wrote:
> Hi,
> 
> what is the difference between
> 
> var varname = 1
> 
> and
> 
> locals.varname = 1
> 
> And when use one and the other?
> 
> Greetings
> Tobias
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [icinga-users] how to ignore a Host

[Kai Nothdurft]

Hi Michael,

so what do you mean with ignore? If it's showing OK, you can ignore the
host, don't you? If you don't use a check_command, what should be shown
in the Web-interface? Or do you want the hosts be hidden from the
Webinterface? How do you want to hide them? If from the GUI, how would
you reenable the host? Or do you want to "disable" the hosts(s)
programmatically? Would be a reload of Icinga2 a problem then?

Though I don't really understand, what you are trying to achieve, you
may play around with parameter "check_period" and create a timeperiod
"never".

brgds
Kai


>>> On 18.10.2016 at 03:17, Michael Martinez  wrote:
> Hi Kai,
> 
> Yes, I understand that. But a dummy check that always returns OK is
> misleading. The hosts themselves may be Up, may be Down, but for a
> particular subset of hosts we don't want to know either way. We
would
> rather ignore them.
> 
> On Fri, Oct 7, 2016 at 5:04 AM, Kai Nothdurft
 
> wrote:
>> Hi Michael,
>>
>> I know, you wrote, that you don't want to assign a dummy check -
but
>> why not? You could use the built-in "dummy"-check for this:
>>
>>
>> object Host "unchecked-host" {
>>   import "generic-host"
>>
>>   check_command = "dummy"
>>
>>   vars.dummy_state  = 0
>>   vars.dummy_text   = "This host will never be checked and
shows
>> always OK"
>>
>> }
>>
>> hth
>> Kai>>> On 06.10.2016 at 19:18, Michael Martinez 
>> wrote:
>>> Hi Hasan, thanks for your reply. I should be more clear: I am
>> actually
>>> looking to ignore the Host check itself. What you've written works
>> for
>>> service checks only.
>>>
>>> On Wed, Oct 5, 2016 at 10:26 AM, hasan akgöz

>> wrote:
>>>> Hello Michael,
>>>>
>>>> if you hostname or ip adress whatever is static you can use
ignore
>> keyword
>>>> follow like ;
>>>>
>>>> apply Service "Service Name" {
>>>>   ...
>>>>
>>>>   assign where match("web*.example.org", host.name)
>>>>   ignore where host.name
>>>> }
>>>>
>>>>
>>>>
>>>> 2016-10-05 19:51 GMT+03:00 Michael Martinez :
>>>>>
>>>>> we need to exclude certain hosts based on AWS
>>>>> attributes (VpcId
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> icinga-users mailing list
>>>> icinga-users@lists.icinga.org 
>>>> https://lists.icinga.org/mailman/listinfo/icinga-users 
>>>>
>>>
>>>
>>>
>>> --
>>> ---
>>> Michael Martinez
>>> http://www.michael--martinez.com 
>>> ___
>>> icinga-users mailing list
>>> icinga-users@lists.icinga.org 
>>> https://lists.icinga.org/mailman/listinfo/icinga-users 
>> ___
>> icinga-users mailing list
>> icinga-users@lists.icinga.org 
>> https://lists.icinga.org/mailman/listinfo/icinga-users 
> 
> 
> 
> -- 
> ---
> Michael Martinez
> http://www.michael--martinez.com 
> ___
> icinga-users mailing list
> icinga-users@lists.icinga.org 
> https://lists.icinga.org/mailman/listinfo/icinga-users
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [icinga-users] how to ignore a Host

[Kai Nothdurft]

Hi Michael,

I know, you wrote, that you don't want to assign a dummy check - but
why not? You could use the built-in "dummy"-check for this:


object Host "unchecked-host" {
  import "generic-host"

  check_command = "dummy"

  vars.dummy_state  = 0
  vars.dummy_text   = "This host will never be checked and shows
always OK"

}

hth
Kai>>> On 06.10.2016 at 19:18, Michael Martinez 
wrote:
> Hi Hasan, thanks for your reply. I should be more clear: I am
actually
> looking to ignore the Host check itself. What you've written works
for
> service checks only.
> 
> On Wed, Oct 5, 2016 at 10:26 AM, hasan akgöz 
wrote:
>> Hello Michael,
>>
>> if you hostname or ip adress whatever is static you can use ignore
keyword
>> follow like ;
>>
>> apply Service "Service Name" {
>>   ...
>>
>>   assign where match("web*.example.org", host.name)
>>   ignore where host.name
>> }
>>
>>
>>
>> 2016-10-05 19:51 GMT+03:00 Michael Martinez :
>>>
>>> we need to exclude certain hosts based on AWS
>>> attributes (VpcId
>>
>>
>>
>>
>>
>>
>> ___
>> icinga-users mailing list
>> icinga-users@lists.icinga.org 
>> https://lists.icinga.org/mailman/listinfo/icinga-users 
>>
> 
> 
> 
> -- 
> ---
> Michael Martinez
> http://www.michael--martinez.com 
> ___
> icinga-users mailing list
> icinga-users@lists.icinga.org 
> https://lists.icinga.org/mailman/listinfo/icinga-users
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [icinga-users] icinga2 agent default services

[Kai Nothdurft]

Hi Hasan,

I'm sorry, I don't use the icinga2 node wizard - I use vi.

best regards
Kai


>>> On 03.05.2016 at 10:08, Hasan Akgöz wrote:
> Hi Kai,
> 
> When register with icinga2 node wizard application , following
services are
> automatically added. When each server register I just want to ping
and ssh
> as a default.
> 
> 
>  Host 'client4.example.com'
> * Service 'apt'
> * Service 'disk'
> * Service 'disk /'
> * Service 'http'
> * Service 'icinga'
> * Service 'load'
> * Service 'ping4'
> * Service 'ping6'
> * Service 'procs'
> * Service 'ssh'
> * Service 'swap'
> * Service 'users'
> 
> 
> 
> 2016-05-03 10:44 GMT+03:00 Kai Nothdurft :
> 
>> only assigned to host
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [icinga-users] icinga2 agent default services

[Kai Nothdurft]

Hi,

the default-services are only assigned, when specific attributes are
set. For example,
service  is only assigned to hosts with an configured
.
Service  is only assigned to hosts with configured
.

Nevertheless, you find the definitions in  and can
comment them out if you whish.

best regards
Kai


>>> On 02.05.2016 at 21:59, Hasan Akgöz wrote:
> Hello guys,
> I wanna change icinga2 agent default services. how can I do it ? For
> example when
> register any remote client default monitoring services is
> ping4,ping6,http,icinga vb.. I don't want http services monitoring as
a
> default.
> 
> 
> good works.
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [icinga-users] Passive host checks are soft

[Kai Nothdurft]

>>> On 17.03.2016 at 17:46, Michael Friedrich  
>>> wrote:
>> On 16 Mar 2016, at 09:26, Kai Nothdurft  wrote:

[...]

>> in Icinga1 there is an option . Does anybody 
>> know, if there is an equivalent in Icinga2?
> 
> No, and it is not planned to implement such a behaviour.

Ah, OK. Thanks for the Info.

brgds
Kai


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

[icinga-users] Passive host checks are soft

[Kai Nothdurft]

Hi list,

in Icinga1 there is an option . Does anybody 
know, if there is an equivalent in Icinga2?

thanks in advance
Kai


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

Re: [icinga-users] Question about variables

[Kai Nothdurft]

Hello Bertalan,

how about using an array instead?

Example:
vars.attribute = [ "value1" ]
vars.attribute += [ "value2" ]

apply1:
assign where "value1" in vars.attribute

apply2:
assign where "value2" in vars.attribute

hth
Kai


>>> On 10.09.2015 at 15:36, Bertalan Voros  wrote:
> Hello All,
> 
> If there is a variable defined twice on one object, which value gets used?
> Does it get combined?
> 
> Example:
> vars.attribute = "value1"
> vars.attribute = "value2"
> 
> There are then two different apply rules using this.
> 
> apply1:
> assign where vars.attribute == "value1"
> 
> apply2 (somewhere else)
> assign where vars.attribute == "value2"
> 
> Can I expect both to take effect?




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

Re: [icinga-users] PNP4Nagios with Icinga 2

[Kai Nothdurft]

Good morning,

what exactly are you looking for? Are you stucked somewhere? What distro are 
you using? If you are using some flavour of SuSE, I can send you snippets of my 
own documentation.

best regards
Kai


>>> On 31.07.2015 at 23:51, Peltokangas Mikko  
>>> wrote:
> Hi, I would like to have some details about configuring PNP4Nagios in Icinga2


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

Re: [icinga-users] PNP4Nagios with Icinga 2

[Kai Nothdurft]

Hello Martin,

thx for feedback. That's too simple. ;) The documentation is misleading
here. I have now set up PNP4Nagios and integrated it into the Classic-UI
and into Icinga Web 2 as well. Works like a charm!

thanks again and

-- 
best regards
Kai Nothdurft



>>> On 31.07.2015 at 14:55, Martin
Stiborský wrote:
> Hello,
> You just enable perfdata feature in icinga2 and then you point npcd
daemon
> to read the performance data, that's all.
> I can provide details, if you want, I configured pnp4nagios just
yesterday.
> 
> On Fri, Jul 31, 2015, 14:51 Kai Nothdurft 
wrote:
> 

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

[icinga-users] PNP4Nagios with Icinga 2

[Kai Nothdurft]

Hello list,

I have a problem (understanding how) to configure PNP4Nagios with Icinga 2.

The Icinga 2 doc at 

says:

> If you're planning to use it configure it to use the 
> *bulk mode with npcd and npcdmod* 
> 
> in combination with Icinga 2's PerfdataWriter. NPCD collects the performance
> data files which Icinga 2 generates.

OK, I have to use the *npcdmod* - fine but how do I say Icinga 2 to use the
mod?
 
At 

the Icinga 2 doc says about "Broker Modules and Features":

> Icinga 1.x broker modules are incompatible with Icinga 2.
> In order to provide compatibility with Icinga 1.x the functionality of
> several popular broker modules was implemented for Icinga 2:

> IDOUtils
> Livestatus
> Cluster (allows for high availability and load balancing)

Which part in the documentation is wrong or what am I missing?

best regards
Kai


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

Re: [icinga-users] Pushing passive check results from Icinga2 to Nagios

[Kai Nothdurft]

Hello Sergei,

AFAIK Icinga2 saves the new status.dat file as temp file, and once the
entire information was written to that file, closes the file handle and
renames the temp file to status.dat

If your temp directory is on the same partition as the status_file
location, then the rename/mv is an atomic operation - at least on
Linux.

best regards
Kai


>>> On 29.04.2015 at 09:29, Sergei Franco 
wrote:
> Hello Kai,
> 
> Thank you for your reply!
> 
> At this stage it looks we will be parsing the status file (only worry
is
> that the status file is updated in a non-atomic way, so will probably
write
> a daemon with inotify watch on "close_write".
> A second question: is the status file updated atomically?
> 
> Thank you very much!
> 
> I hoped there is an "official" way to achieve this.
> 
> Sergei.
> 
> On 29 April 2015 at 19:19, Kai Nothdurft 
wrote:
> 
>> Hi Sergei,
>>
>> before I forget, you should not use ".'~'.$hostName.'" in the two
>> fwrite-lines of the script. This is for our special environment
only.
>>
>> rgds
>> Kai
>>
>>
>> >>> On 29.04.2015 at 09:10, "Kai Nothdurft"

>> wrote:
>> > Hello Sergei,
>> >
>> > at first, I was missing the "obsess over services/hosts" as well.
As
>> a
>> > workaround I wrote a little cronjob, which parses the status.dat
and
>> creates
>> > a command‑file from it. The script generates a
>> > "PROCESS_HOST|SERVICE_CHECK_RESULT" for ALL host‑ and
service‑stati.
>> You have
>> > to filter on the hosts/services, you are interested in, transfer
the
>>
>> > COMMAND_FILE to your Nagios 3.x‑host and pipe it into the
>> command‑pipe. Be sure
>> > that the feature "statusdata" is enabled (icinga2 feature list).
>> >
>> > hth
>> > Kai
>> >
>> >  cut here 
>> > #!/usr/bin/php
>> > > >
>> > define("STATUS_FILE", "/var/cache/icinga2/status.dat");
>> > define("COMMAND_FILE", "/YOUR/PATH/TO/status.upd");
>> >
>> > if (file_exists(STATUS_FILE)) {
>> >   $status_file_handle = fopen(STATUS_FILE, "r");
>> >   if ($status_file_handle) {
>> > $command_file_handle = fopen(COMMAND_FILE, "w");
>> > if ($command_file_handle) {
>> >   while (!feof($status_file_handle)) {
>> > $line = fgets($status_file_handle);
>> > switch ($line) {
>> >   case "hoststatus {\n":
>> > $hostName = '';
>> > $status = 3;
>> > $pluginOutput = '';
>> > $performanceData = '';
>> > $checkSource = '';
>> > $lastCheck = '';
>> > $line = fgets($status_file_handle);
>> > while (!feof($status_file_handle) && trim($line)!=
"}")
>> {
>> >   list ($param, $value) = explode('=',trim($line),2);
>> >   switch ($param) {
>> > case "host_name":
>> >   $hostName = $value;
>> >   break;
>> > case "current_state":
>> >   $state = $value;
>> >   break;
>> > case "plugin_output":
>> >   $pluginOutput = $value;
>> >   break;
>> > case "performance_data":
>> >   $performanceData = $value;
>> >   break;
>> > case "check_source":
>> >   $checkSource = $value;
>> >   break;
>> > case "last_check":
>> >   $lastCheck = $value;
>> >   break;
>> > }
>> >$line = fgets($status_file_handle);
>> > }
>> > fwrite($command_file_handle,"[$lastCheck]
>> >
>>
>> 
>
PROCESS_HOST_CHECK_RESULT;".$checkSource.'~'.$hostName.';'.$state.';'.$plugin
>> > Output.'|'.$performanceData."\n");
>> > break;
>> >
>> >   case "servicestatus {\n":
>> > $hostName = '';
>> >  

Re: [icinga-users] Pushing passive check results from Icinga2 to Nagios

[Kai Nothdurft]

Hi Sergei,

before I forget, you should not use ".'~'.$hostName.'" in the two
fwrite-lines of the script. This is for our special environment only.

rgds
Kai


>>> On 29.04.2015 at 09:10, "Kai Nothdurft" 
wrote:
> Hello Sergei,
> 
> at first, I was missing the "obsess over services/hosts" as well. As
a 
> workaround I wrote a little cronjob, which parses the status.dat and
creates 
> a command‑file from it. The script generates a 
> "PROCESS_HOST|SERVICE_CHECK_RESULT" for ALL host‑ and service‑stati.
You have 
> to filter on the hosts/services, you are interested in, transfer the

> COMMAND_FILE to your Nagios 3.x‑host and pipe it into the
command‑pipe. Be sure 
> that the feature "statusdata" is enabled (icinga2 feature list).
> 
> hth
> Kai
> 
>  cut here 
> #!/usr/bin/php
>  
> define("STATUS_FILE", "/var/cache/icinga2/status.dat");
> define("COMMAND_FILE", "/YOUR/PATH/TO/status.upd");
> 
> if (file_exists(STATUS_FILE)) {
>   $status_file_handle = fopen(STATUS_FILE, "r");
>   if ($status_file_handle) {
> $command_file_handle = fopen(COMMAND_FILE, "w");
> if ($command_file_handle) {
>   while (!feof($status_file_handle)) {
> $line = fgets($status_file_handle);
> switch ($line) {
>   case "hoststatus {\n":
> $hostName = '';
> $status = 3;
> $pluginOutput = '';
> $performanceData = '';
> $checkSource = '';
> $lastCheck = '';
> $line = fgets($status_file_handle);
> while (!feof($status_file_handle) && trim($line)!= "}")
{
>   list ($param, $value) = explode('=',trim($line),2);
>   switch ($param) {
> case "host_name":
>   $hostName = $value;
>   break;
> case "current_state":
>   $state = $value;
>   break;
> case "plugin_output":
>   $pluginOutput = $value;
>   break;
> case "performance_data":
>   $performanceData = $value;
>   break;
> case "check_source":
>   $checkSource = $value;
>   break;
> case "last_check":
>   $lastCheck = $value;
>   break;
> }
>$line = fgets($status_file_handle);
> }
> fwrite($command_file_handle,"[$lastCheck] 
>
PROCESS_HOST_CHECK_RESULT;".$checkSource.'~'.$hostName.';'.$state.';'.$plugin
> Output.'|'.$performanceData."\n");
> break;
> 
>   case "servicestatus {\n":
> $hostName = '';
> $serviceDescription = '';
> $status = 3;
> $pluginOutput = '';
> $performanceData = '';
> $checkSource = '';
> $lastCheck = '';
> $line = fgets($status_file_handle);
> while (!feof($status_file_handle) && trim($line)!= "}")
{
>   list ($param, $value) = explode('=',trim($line),2);
>   switch ($param) {
> case "host_name":
>   $hostName = $value;
>   break;
> case "service_description":
>   $serviceDescription = $value;
>   break;
> case "current_state":
>   $state = $value;
>   break;
> case "plugin_output":
>   $pluginOutput = $value;
>   break;
> case "performance_data":
>   $performanceData = $value;
>   break;
> case "check_source":
>   $checkSource = $value;
>   break;
> case "last_check":
>   $lastCheck = $value;
>   break;
> }
>$line = fgets($status_file_handle);
> }
> fwrite($command_file_handle,"[$lastCheck] 
>
PROCESS_SERVICE_CHECK_RESULT;".$checkSource.'~'.$hostName.';'.$servi

Re: [icinga-users] Pushing passive check results from Icinga2 to Nagios

[Kai Nothdurft]

Hello Sergei,

at first, I was missing the "obsess over services/hosts" as well. As a 
workaround I wrote a little cronjob, which parses the status.dat and creates a 
command-file from it. The script generates a 
"PROCESS_HOST|SERVICE_CHECK_RESULT" for ALL host- and service-stati. You have 
to filter on the hosts/services, you are interested in, transfer the 
COMMAND_FILE to your Nagios 3.x-host and pipe it into the command-pipe. Be sure 
that the feature "statusdata" is enabled (icinga2 feature list).

hth
Kai

 cut here 
#!/usr/bin/php



>>> On 29.04.2015 at 06:49, Sergei Franco  wrote:
> Hello there,
> 
> Is there a way to push passive results via nsca from Icinga 2 (which does
> active checking) to Nagios 3.x?
> It looks like the "obsess over services/hosts" and ochp/ocsp config items
> are missing from Icinga 2.
> 
> The nagios machine (that receives the passive checks) *cannot* be
> "upgraded" to icinga2 so none of the distributed monitoring documentation
> applies
> 
> Regards.
> 
> 
> Sergei.
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

[icinga-users] apply|ignore where... in templates possible?

[Kai Nothdurft]

Hi all,

I put an "ignore where..." statement into a service template. A service 
apply-rule, which imports the template ignores the ignore. Does it work as 
designed this way? Am I unable to use "apply|ignore" in templates?

best regards
Kai


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

Re: [icinga-users] Icinga 2 and obsess_over_host / obsess_over_service

[Kai Nothdurft]

Good morning Michael,

>>> On 05.03.2015 at 20:20, Michael Friedrich
 wrote:
> Am Donnerstag, 5. März 2015 schrieb Kai Nothdurft :
>>  >>> On 05.03.2015 at 16:44, Michael Friedrich
> wrote:
>> >
>> > I'm curious what makes you think that such an option
"ohcp_command"
>> > exists in Icinga 2.
>> >
>> > Michael
>>
>> Doesn't Icinga 2 inherit the option "ohcp_command" from Icinga,
which
>> inherited it from Nagios? Please don't tell me that this feature
was
>> removed.
> 
> 
> It's not implemented. There was no use case for it.

I'm curious what makes you think that there is no use case for anybody.
;)

>>  I need it. How should I otherwise transfer the states from ship
>> to shore?
> 
> Cluster feature with integrated replication. Check the docs. 

I did check the docs. Again, I am talking about remote Icinga2-hosts
on
seagoing vessels, which have only low-bandwith/high latency- Internet
once in a while via satellite with a very expensive data-plan. There
is no reliable Internet-connection at all, but at least we have a
robust
file-transfer-solution for maritime business.

Cluster Requirements (from the docs) not met:


Cluster Requirements
- communication between zones happens bi-directional which means that a

DMZ-located node can still reach the master node, or vice versa 
- Update firewall rules and ACLs

Distributed Zones
That scenario fits if your instances are spread over the globe and they

all report to a master instance. Their network connection only works 
towards the master master (or the master is able to connect, depending

on firewall policies). 


>There's also a mention for the differences between 1.x and 2.x.

Yep, a.o. it says:


Distributed Monitoring

Icinga 1.x uses the native "obsess over host/service" method which 
requires the NSCA addon passing the slave's check results passively
onto 
the master's external command pipe. While this method may be used for 
check load distribution, it does not provide any configuration 
distribution out-of-the-box. Furthermore comments, downtimes, and other

stateful runtime data is not synced between the master and slave nodes.

There are addons available solving the check and configuration 
distribution problems Icinga 1.x distributed monitoring currently 
suffers from. 

Icinga 2 implements a new built-in distributed monitoring architecture,

including config and check distribution, IPv4/IPv6 support, SSL 
certificates and zone support for DMZ. High Availability and load 
balancing are also part of the Icinga 2 Cluster setup. 


I see propaganda for the (good) built-in distributed monitoring 
architecture but NO word, that the old way does NOT work anymore. 

>> In my test-setup now the config is accepted, but it looks like my
>> "ohcp_command"-script is never executed.
> 
> Just because that configuration is nonsense, and not documented
_anywhere_
> in the icinga2 docs.

Why so rude? I think you are right, that the configuration does not 
work. But "nonsense"? That something is not documented means that it is

not implemented? You say the documentation always reflects the latest 
state? I could argue that it is nonsense, that Icinga2 takes the
options 
from my conf-file without complaining. When it takes options w/o errors

or warnings one can  assume, that the options are valid and that they
have an 
effect. Btw, the documentaion for Icinga2 at docs.icinga.org lacks a
search
engine, which forced me to use Google, which in turn often displays
results
for Icinga even when searched for Icinga2.

Again, I think you don't know anything about maritime business. I only

need status updates every half an hour or so. Now that I know, that 
ocsp/ohcp is not implemented in Icinga2 (thanks for clarifying), I'll 
write a cron-job which gets the data via livestatus and feeds that to 
our file-transfer-routine. But I have to read the docs for klivestatus
first...

Thanks again for putting me on the right track and
best regards
Kai
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [icinga-users] Icinga 2 and obsess_over_host / obsess_over_service

[Kai Nothdurft]

 >>> On 05.03.2015 at 16:44, Michael Friedrich  
 >>> wrote:
> 
> I'm curious what makes you think that such an option "ohcp_command" 
> exists in Icinga 2.
> 
> Michael

Doesn't Icinga 2 inherit the option "ohcp_command" from Icinga, which 
inherited it from Nagios? Please don't tell me that this feature was 
removed. I need it. How should I otherwise transfer the states from ship
to shore?

In my test-setup now the config is accepted, but it looks like my
"ohcp_command"-script is never executed.

Kai

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

Re: [icinga-users] Icinga 2 and obsess_over_host / obsess_over_service

[Kai Nothdurft]

Hi Markus,

you are great. With double quotes it's O.K.
Thank you very much for your quick and correct response!

-- 
best regards
Kai Nothdurft


>>> On 05.03.2015 at 15:55, Markus Joosten wrote:
> Hi Kai,
> 
> commands should be specified in double quotes ("").
> 
> Regards,
> Markus
> -----Original message-
> From: Kai Nothdurft 
> Sent: Thursday 5th March 2015 15:47
> To: icinga-users@lists.icinga.org 
> Subject: [icinga-users] Icinga 2 and obsess_over_host / obsess_over_service
> 
> Hello list,
>  I want to install some Icinga2-hosts on a couple of seagoing vessels, which 
> are
> online only irregulary. I want to send the check-results to an Icinga2-host
> running on the shore-side via email. In a test-environment from the ships-
> network I have prepared a host with does the active checks and which works 
> fine
> so far. Now  I hought obsess_over_host/obsess_over_service is the way to go,
> but I'm stucked.
> 
> On "icinga2 daemon -C" I always get the following error:
>  /etc/icinga2/conf.d/local.d/main.conf(38):  * the obsess_over_host 
> directive in
>   the host definition is 
> enabled.
> /etc/icinga2/conf.d/local.d/main.conf(39):  */
> /etc/icinga2/conf.d/local.d/main.conf(40): 
> ochp_command=submit_host_check_result
> 
> 
> /etc/icinga2/conf.d/local.d/main.conf(41):
> /etc/icinga2/conf.d/local.d/main.conf(42): /*
>  Config error: Error while evaluating expression: Tried to access undefined
>  script variable 
> 'submit_host_check_result'
> critical/config: 1 errors, 0 warnings.
>  
> In my local.d/main.conf I have:
>  enable_notifications=0
> ochp_timeout=5
> ochp_command=submit_host_check_result
> obsess_over_hosts=1
>  and in my local.d/commands.cfg I have defined:
>  object CheckCommand "submit_host_check_result" {
> import "plugin-check-command"
>  command = [ PluginDir + "/submit_host_check_result" ]
>  arguments = {
> }
> }
>  The script itself exist, but does nothing at all at the moment.
>  Why is Icinga2 complaining about undefined script variable
> "submit_host_check_result"? What am I missing?
>  thanks in advance
> Kai
> 
> ___
> 
> icinga-users mailing list
> 
> icinga-users@lists.icinga.org 
> 
> https://lists.icinga.org/mailman/listinfo/icinga-users

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

[icinga-users] Icinga 2 and obsess_over_host / obsess_over_service

[Kai Nothdurft]

Hello list,
 
I want to install some Icinga2-hosts on a couple of seagoing vessels, which are
online only irregulary. I want to send the check-results to an Icinga2-host
running on the shore-side via email. In a test-environment from the ships-
network I have prepared a host with does the active checks and which works fine
so far. Now  I hought obsess_over_host/obsess_over_service is the way to go,
but I'm stucked.

On "icinga2 daemon -C" I always get the following error:
 
/etc/icinga2/conf.d/local.d/main.conf(38):  * the obsess_over_host directive in

  the host definition is enabled.
/etc/icinga2/conf.d/local.d/main.conf(39):  */
/etc/icinga2/conf.d/local.d/main.conf(40): ochp_command=submit_host_check_result


/etc/icinga2/conf.d/local.d/main.conf(41):
/etc/icinga2/conf.d/local.d/main.conf(42): /*
 
Config error: Error while evaluating expression: Tried to access undefined
 script 
variable 'submit_host_check_result'
critical/config: 1 errors, 0 warnings.
 

In my local.d/main.conf I have:
 
enable_notifications=0
ochp_timeout=5
ochp_command=submit_host_check_result
obsess_over_hosts=1
 
and in my local.d/commands.cfg I have defined:
 
object CheckCommand "submit_host_check_result" {
import "plugin-check-command"
 
command = [ PluginDir + "/submit_host_check_result" ]
 
arguments = {
}
} The script itself exist, but does nothing at all at the moment.
 
Why is Icinga2 complaining about undefined script variable
"submit_host_check_result"? What am I missing?
 
thanks in advance
Kai
 
 
 
 
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users