"Unable to detect your deployment endpoint" when deploying zones

Icinga Web Modules Icinga Director
1

Hi, I hope you can help - I’m been going through steps to try to get Icinga2/Web/Directory configured in a distributed master/slave setup.
As I was having such trouble, I spent time trying to make the base icinga2 setup work in a master/satellite.

On the directory module configuration page, I reach the follwoing configuraion item:

“This is the name of the Endpoint object (and certificate name) you created for your ApiListener object.”

I couldn’t find the creation of an ApiListener object in the Icinga2 or Icinga Web 2 installation steps. So as far as I understand it, this is tha master zone name.

My endpoint is master (see below) but director wouldn’t pick this up so I had to put the FQDN of the master node (Icinga2,Icinga Web 2 & Director are all on the same host).

When I ran the kickstart wizard, the master and site-a zones do not get imported.

I tried to add the master and site-a zones (with the latter having “master” as the parent) but director threw this error.

Unable to detect your deployment endpoint. I was looking for the first endpoint configured with an assigned API user in the “master” zone.

I’m not sure what to do next, how I can I get the director config to match the underlying icinga2 config?

Thanks,

Master zones.conf

 * Generated by Icinga 2 node setup commands
 * on 2019-04-09 13:22:32 +0100
 */

object Endpoint "master" {
}

object Zone "master" {
        endpoints = [ "master" ]
}

object Endpoint "site-a" {
        host = "siteanode.mydomain.local"
        port = "5665"
}

object Zone "site-a" {
        endpoints = [ "site-a" ]
        parent = "master"
}

object Zone "global-templates" {
        global = true
}

object Zone "director-global" {
        global = true
}

Satellite zones.conf:

/*
 * Generated by Icinga 2 node setup commands
 * on 2019-04-09 13:27:48 +0100
 */

object Endpoint "master" {
        host = "masternode.mydomain.local"
        port = "5665"
}

object Zone "master" {
        endpoints = [ "master" ]
}

object Endpoint "site-a" {
        host = "siteanode.mydomain.local"
        port = "5665"
}

object Zone "site-a" {
        endpoints = [ "site-a" ]
        parent = "master"
}

object Zone "global-templates" {
        global = true
}

object Zone "director-global" {
        global = true
}
2

Hi,

yet again, the Director assumes you follow the FQDN principle explained in the docs. Since you’ve changed that for your liking, the default instructions do not apply anymore. That’s basically the reason we don’t recommend changing the conventions, as it gets troublesome.

Kickstart expects the master’s endpoint name and a connection address with host and port where the REST API ist listening on. You can also run the icingacli director kickstart run command with putting in a kickstart.ini into /etc/icingaweb2/modules/director beforehand.

[config]
endpoint = icinga-master
host = 127.0.0.1
port = 5665
username = director
password = ***

That’s extracted from how the Puppet module does it.

Cheers,
Michael

1 Like
3

Thanks Michael,

I tried to do a kickstart.ini file, I wasn’t sure what the credentials were supposed to be so I used the root API account but I get the following error (didn’t wrap on the console so was truncated)

ERROR: Icinga\Exception\ConfigurationError in /usr/share/icingaweb2/modules/director/library/Director/KickstartHelper.php:375 with message: I was unable to re-establish a connection to the n

At this point I’m happy to roll back to a fresh install of Icinga/Web2 to get director installed as I’ve been banging my head against this for days now. The reason for modifying the zones was that the default config does not reflect the organisation setup, the FQDN of a host should not be used for any zone name as we’d hoped to eventually have N+1 resilience for the zones, so an additional host would have a different FQDN, but maybe there’s a better way to do this.

4

Maybe just change that for the zone names, but not the endpoint names per se. When you point the Director and everything else to a zone, it will attempt to import things. It just maps the REST API details with the endpoint name here, resulting in the FQDN requirement. I don’t know whether it is possible to rule out.