Icinga Director Kickstart Wizard failed deploy - need to rollback

I’m a bit of a newbie inheriting an Icinga2 with director configuration (v r2.10.4-1). I was attempting to add a satellite node. Using the Management WebUI, within Icinga Director > Icinga Infrastructure > Kickstart Wizard, I provided the new endpoint name and host information and ran the import on the director_ido DB resource. Unfortunately, when this attempted to deploy, it failed with:

critical/config: Error: Object 'generic-host' of type 'Host' re-defined: in [[stage]/zones.d/director-global/host_templates.conf](https://icinga01.storage.dc1.slc.ostk.com/director/config/file?config_checksum=f5e227fb9f32567c175daac495ba6b7ee2fad581&deployment_id=1232&file_path=zones.d%2Fdirector-global%2Fhost_templates.conf&backTo=deployment&highlight=1&highlightSeverity=critical): 1:0-1:27; previous definition: in /etc/icinga2/conf.d/templates.conf: 14:1-14:28 Location: in [[stage]/zones.d/director-global/host_templates.conf](https://icinga01.storage.dc1.slc.ostk.com/director/config/file?config_checksum=f5e227fb9f32567c175daac495ba6b7ee2fad581&deployment_id=1232&file_path=zones.d%2Fdirector-global%2Fhost_templates.conf&backTo=deployment&highlight=1&highlightSeverity=critical): 1:0-1:27

I’m stuck trying to clean up the entire configuration - I don’t appear to have the ability to discard this staged configuration to entirely revert this configuration to a previously successful deploy.

The kickstart attempt appeared to create:

  • An external object for a new zone - zones.d/<my_new_zone>/zones.conf
  • A ‘global-templates’ icinga zone - zones.d/director-global/zones.conf
  • A new icinga_endpoint - zones.d/<my_new_zone>/endpoints.conf
  • Modified zones.d/director-global/commands.conf - icinga_command ‘mail-service-notification’ removing line for ‘vars.notification_icingaweb2url’
    • Modified zones.d/director-global/commands.conf - icinga_command ‘mail-host-notification’ removing line for ‘vars.notification_icingaweb2url’

I tried looking up possible cleanup ideas online using the icingacli commands but this seems to be a very unique corner case, I’ve had no luck so far.


not sure if that’s the problem, but maybe a local example configuration causes trouble here. Ensure that conf.d isn’t included in icinga2.conf - the default setup wizard will already do that, but just to be sure.


Thank you for the reply Michael Friedrich. I worked on this issue for several hours last night, primarily to fix this issue so we can continue deploying new changes that were failing. I found a number of new and modified entries made in the director MySQL database. I manually purged the newly created zone & endpoint and reverted some director commands and existing director endpoints for mail-* back to object (from External Object types). I purged the activity log db rows and some of the failed deployment records to bring the log back to a “good” history (this wasn’t cleanly done because some FK dependencies exist and no cascading deletes are set). After all this very dirty fixing, I have icinga director building clean stages and deploying changes successfully. I tried running housekeeping against ALL but it doesn’t appear to clean up my messes for orphaned director deployment builds.

The correct way(or at least how I do it) of adding a satellite would be:

  • install icinga2 on the satellite host
  • run the setup wizard icinga2 node wizard
  • copy the zone and endpoint object from the satellites /etc/icinga2/zones.conf to the masters zones.conf
  • restart icinga2 on both systems
  • run the Director kickstart to import the new endpoint and zone into Director

Sounds to me as if you tried it the other way round.
Also as @dnsmichi said, there probably are some example configurations in /etc/icinga2/conf.d, which now duplicate stuff already imported from the initial Director kickstart.

1 Like