Is there a switch to allow redefinitions of configuration objects?

So first off I’m not using the director at all. I’ve been using icinga2 for some years, not that I am an expert at it. However there’s this chicken and egg problem I am having recently because configuration objects are not allowed to be redefined and/or configuration appears to be order sensitive.

Is there a switch somewhere to tell icinga2 “It’s ok to redefine objects”? That would immediately solve my problem.

Otherwise, I am pushing configuration data to satellites and it’s apparently non-deterministic whether or not I have to include the local satellite’s conf.d directory into config even though I have the same definitions in my master conf.d/zones.d directory.

I have searched some on this problem but as you know, search engines return different results for people. If someone out there thinks that I should have found some article that will clarify things, please repost it here. Thanks!

Hi @davehayes,

there is no so switch to allow redefining objects.

If you still got this problem, maybe you could share a config example and/or elaborate on why you need to redefine config objects.

Greetings
Noah

Hello there @davehayes !
Did you manage to solve your issue in the meantime?
I’d be happy to read an update on this!
Have a nice day!
Feu

Not properly. Basically I have to blow away satellite configurations, then bootstrap a global templates file, turn on icinga2, once it receives an update from master turn it off, remove global templates file, and then turn it on again.

I can’t share a config example because the configs I am using have sensitive data in them. What I would have to do is create an example from scratch, which of course will have the likely result of not triggering the issue.

All this would be solved if I had a command line switch that prevented errors on redefinitions of objects.

Last time I read this, I didn’t notice that you have your zones.d directory in your conf.d directory. If that’s correct you also have to change you ZonesDir constant, because Icinga doesn’t handle the zones.d directory like a normal config directory. Also, config in conf.d will by default never be synced to other Icinga instances in your cluster. Config that is needed on every instance (e.g. apply rules) should be synced via the zones.d/global-templates directory/zone.

If it’s not possible to share config, maybe you could explain what is missing on the satellite and why you even need config on your satellite (that depends on something from your master). Most setups only need config on the master, maybe it’s not necessary to have config on your satellite.

You only notice that because I communicated unclearly. I do not have my zones.d in my conf.d directory and that slash should really be an “and”. :slight_smile:

The template “generic-service” is a good example. This has to exist. When I tried to upgrade versions, without changing anything, icinga2 (on the satellite) complained that this template was multiply defined. If you look at my config with grep:

 > grep -r generic * | grep ':template'
zones.d/global-templates/global-templates.conf:template Service "generic-service" {

All my satellites disabled

include_recursive "conf.d"

but I found I had to reenable this long enough to get a successful restart.

Looks fine to me, and that’s the way most people do it. What version of Icinga are you using on your masters and satellites? The config sync can be broken by using incompatible versions of Icinga. For example your satellites should never have a newer version then your master. https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#versions-and-upgrade

1 Like

That’s the problem then. I cannot upgrade the master until a particular FreeBSD icinga2 bug is fixed, but I did upgrade the satellites. Thank you for mentioning this.

1 Like