Am 09.02.2015 um 18:19 schrieb Michael Friedrich: > Am 09.02.2015 um 17:38 schrieb Dustin Funk: >> Hi, >> >> i have a question about config handling for icinga2 agent based checks >> (icinga2 version 2.2.3). >> >> I wanna use both cases >> - local config and >> - remote check execution > > I'm not sure why you would want that. That generates headaches. >
I read it in the documentation [1] and want to test both ways combined
atm. The concept in future would be:
- local config: for icinga2 satellites
- remote check execution: on all hosts as nrpe replacement
>>
>> The question is how to handle both cases. My problem is that 'node
>> update-config' handles both and creates also files for clients which can
>> not be administrated by update-config (the clients which usees remote
>> check execution).
>>
>> I did the following:
>>
>> 1) run the wizard for become a secure connection between both hosts
>> 2) delete host.conf on client (because for the client check execution
>> should be used)
>> 3) activate the accept_commands on clients api.conf
>> 4) wrote manually the configuration on the master (objects: host,
>> endpoint and zone) and saved it e.g. in conf.g
>> 5) run icinga2 node list
>>
>> At node list output i see that the new client is registered but only one
>> line is listet (only the node, no host, no service).
>>
>> At this point all works fine.
>>
>> 6) run update-config (because there are more clients configured with
>> local config)
>>
>> update-config creates now a zone, endpoint and host object (restart
>> icinga2 isn't possible because double definitions).
>>
>> The definitions from update-config are the following:
>>
>> repository.d/hosts/
>> object Host "monitoring-test.fem.tu-ilmenau.de" {
>> import "satellite-host"
>> check_command = "cluster-zone"
>> }
>> repository.d/endpoint/
>> object Endpoint "monitoring-test.fem.tu-ilmenau.de" {
>> }
>> repository.d/zones/
>> object Zone "monitoring-test.fem.tu-ilmenau.de" {
>> endpoints = [ "monitoring-test.fem.tu-ilmenau.de" ]
>> parent = "master"
>> }
>>
>>
>> My workaround atm is to edit the three files in the repository.d.
>> - the zone-file is identical
>> - the host file is full commented out and is defined in a file in conf.d
>> - add attribute "host" on the endpoint file
>>
>> I like the idea to play all zone and endpoint configurations in
>> repository.d. But for clients with remote check execution the object
>> host is created wrong and in the endpoint the ip/FQDN/dns is missing.
>
> It wasn't made for that, which is why we are not using nor refencing it
> in the documentation.
>
So the right way is to separate hard both possibilities from each other?
In irc someone answer to me that zone and endpoint definitions should
find place in repository.d (also these for remote check execution).
Separate both possibilities means that all hosts for remote check
execution should be blacklisted at icinga2 node @CLI?
I was wondered about eeehr.. Is it true that remote-clients earlier had
to be added via icinga2 node add? Later i read that node add is no
longer necessary. But my head was confused about the auto accepting
clients including clients configured with remote check execution.
Autoaccepting clients is the reasons why i run in problems.
>> But now update-config doesn't ignore the host (which is understandable).
>> Is there a better way for blacklisting?
>
> That's a known bug in 2.2.x: https://dev.icinga.org/issues/8211
>
Thanks! I see its fixed in 2.3.0. Nice!
Cheers
nuts
[1]
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-remote-systems#icinga2-remote-monitoring-client-roles
signature.asc
Description: OpenPGP digital signature
_______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
