Config deployment fails due to redefined master

unixadmin · June 17, 2024, 10:46am

My issue is similar to the one found here:

I set up Icinga2 on a master server, together with the icingaweb2 and the database.
II have two zones. which are assigned based on a puppet variable on deployment / import with the director.

When I deploy the config, it fails with the following error message:

[2024-06-17 12:16:21 +0200] information/cli: Icinga application loader (version: r2.14.2-1)
[2024-06-17 12:16:21 +0200] information/cli: Loading configuration file(s).
[2024-06-17 12:16:21 +0200] critical/config: Error: Object '<master-host>' of type 'Host' re-defined: in [stage]/zones.d/dmz/hosts.conf: 2418:1-2418:46; previous definition: in /etc/icinga2/conf.d/hosts.conf: 18:1-18:20
Location: in [stage]/zones.d/dmz/hosts.conf: 2418:1-2418:46
[stage]/zones.d/dmz/hosts.conf(2416): }
[stage]/zones.d/dmz/hosts.conf(2417): 
[stage]/zones.d/dmz/hosts.conf(2418): object Host "<master-host>" {
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[stage]/zones.d/dmz/hosts.conf(2419):     import "<template>"
[stage]/zones.d/dmz/hosts.conf(2420): 
[2024-06-17 12:16:21 +0200] critical/cli: Config validation failed. Re-run with 'icinga2 daemon -C' after fixing the config.

If I delete the Icinga2 master host object in the director after the syncronization from puppetdb, the import run works perfectly and I can see my hosts and monitor them in Icingaweb2.
But every time I deploy a new config, I have to manually import everything and deploy it by hand because the config deployment will fail if I don’t delete the imported master host.
This is pretty annoying as I cannot automate import, sync and deployment. Also, all of my configured services aren’t deployed on the master.
I see the master as it is by default shown in icingaweb2 as it is the server host.
The solution of the cited post does not work, just setting the problematic host to no agent does not make the import run without issue (which would be nice because it would allow me to just assign another template to the host on sync with puppet).

My question is:
Can I delete the original master host in some way and just deploy it by standard means of the director as a “foreign” host (meaing it’s not 127.0.0.1)?

moreamazingnick · June 17, 2024, 11:36am

You created a host object by puppet, but but there might be this config enabled too:

github.com

Icinga/icinga2/blob/master/etc/icinga2/conf.d/hosts.conf

/*
 * Host definitions with object attributes
 * used for apply rules for Service, Notification,
 * Dependency and ScheduledDowntime objects.
 *
 * Tip: Use `icinga2 object list --type Host` to
 * list all host objects after running
 * configuration validation (`icinga2 daemon -C`).
 */

/*
 * This is an example host based on your
 * local host's FQDN. Specify the NodeName
 * constant in `constants.conf` or use your
 * own description, e.g. "db-host-1".
 */

object Host NodeName {
  /* Import the default host template defined in `templates.conf`. */
  import "generic-host"

This file has been truncated. show original

which creates a hostobject that might have a similar name…

for completely managing with pupped this “NodeName” dependend config files should not be used as they will interfere with your static puppet config

unixadmin · June 18, 2024, 9:07am

Well I moved the file away and now my config deployment works and the correct checks are executed on the master server as if it were a remote server, which is exactly what I wanted.
Thanks so much for the fast help. this forum is incredible. I hope this didn’t break anything in the long run but I assume it won’t as the config files in that directory aren’t used anyway to my understanding (at least the way I set it up).

Thank you very much.