> On 17 Nov 2016, at 13:55, t...@lisag.de wrote:
>
> Hi Stephan,
>
> resolved the problem:
>
> The Masters didn't synconizing the objects of the child-zones.
> On switching to cluster, the idodb-connection switched to an master without
> synced child-objects.
>
> You have to declare the childzones on _all_ clustermembers.
> Then all objects of the childzone declared on the configmaster will be
> replicated too.
> The definition of the Ccildzone itself on the configmaster will not be synced.
Zone and Endpoint configuration must be there before a connection and then a
sync can happen. If you don’t have those objects on the satellite, it won’t
know about the connecting master node - neither it can check the CN against the
endpoint name nor check against the zone hierarchy in order to accept the
configuration from the parent only.
Kind regards,
Michael
>
> Best regards
>
> On 15.11.2016 17:56, tilo....@googlemail.com wrote:
>> Hi Stephan,
>>
>>
>> On 14.11.2016 21:14, Stephan Tesch wrote:
>>> Am 14.11.2016 um 19:55 schrieb tilo....@googlemail.com:
>>>> on satA's:
>>>> =================
>>>>
>>>> /etc/icinga2.conf:
>>>> -----------------
>>>> ...
>>>> include zones.conf.d
>>>> include _recursive zones.conf.d
>>>>
>>>>
>>>>
>>>> /etc/icinga2.zones.conf.d/satA.conf:
>>>> -----------------
>>>> object Endpoint "satA1" {
>>>> host= "xxx.xxx.xxx.xxx"
>>>> }
>>>>
>>>> object Endpoint "satA2" {
>>>> host= "xxx.xxx.xxx.xxx"
>>>> }
>>>>
>>>> object Zone "satA" {
>>>> endpoints = [ "satA1","satA2"]
>>>> parent = "master"
>>>> }
>>>>
>>>> object Zone "global"
>>>> global = true
>>>> }
>>>>
>>>>
>>>> /etc/icinga2/zones.conf.d/master.conf:
>>>> -----------------
>>>> object Endpoint "master1" {
>>>> host= "xxx.xxx.xxx.xxx"
>>>> }
>>>>
>>>> object Endpoint "master2" {
>>>> host= "xxx.xxx.xxx.xxx"
>>>> }
>>>>
>>>> object Endpoint "master3" {
>>>> host= "xxx.xxx.xxx.xxx"
>>>> }
>>>>
>>>> object Zone "master" {
>>>> endpoints = [ "master1","master2","master3"]
>>>> }
>>>
>>> I'm not sure if this impacts this, but there's a bug that only lets you
>>> use 2 Endpoints for each zone. I wasn't able to find that bugreport, but
>>> it might be a start to dial that config down to master1 and master2.
>> https://dev.icinga.org/isuues/10435
>> It should only impact the performance of doing checks.
>> and in my scenario the 3 masters doesn't execute checks
>>
>> I'm able to see the results via incinga2 api on the master, but not
>> inside idodb. That means: icinga2-sync itself is working fine?
>>
>> But anyway:
>>
>> I stripped down the complete cluster to only one member per zone
>> Now I'm getting the check-states inside idodb.
>>
>> I'll doing further investigations with different cluster-structures...
>>
>>>
>>> Best regards,
>>> Stephan
>>>
>>> _______________________________________________
>>> icinga-users mailing list
>>> icinga-users@lists.icinga.org
>>> https://lists.icinga.org/mailman/listinfo/icinga-users
>>>
>>
>
> --
> Linux Information Systems
> LIS Stuttgart GmbH
> Talstraße 41 70188 Stuttgart Germany
> mobil +49-177-6493942 tel +49-711-6403961 fax +49-711-6403955
>
> Geschäftsführer Tilo Mey
> Amtsgericht Stuttgart, HRB 729287, Ust-IdNr DE264295269
> Volksbank Stuttgart EG, BIC VOBADESS, IBAN DE75600901000340001003
> _______________________________________________
> 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
** OSMC 2016 - November - netways.de/osmc **
** OSDC 2017 - Mai – osdc.de **
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
