"Checkable with command endpoint requires a zone" even though it worked in 2.10

Icinga 2
1

Hi,

we are trying to migrate vom 2.10 to 2.11 but our config fails with the error messages: Checkable with command endpoint requires a zone

I consulted the upgrade and the documentation but IMHO our config is correct.

Example:

Host (in conf.d)

object Host "srv-im-crmsql" {
  import "generic-server-windows-sql-server"

  address = "x.x.x.x"
  vars.windows_disk["Festplatte E:"] = {
    character = "E:" 
  }
  vars.remote_client = "srv-im-crmsql"
}

Service (in conf.d)

apply Service for (disk => partition in host.vars.windows_disk) {
  import "generic-service"

  check_command = "disk-windows"
  display_name = disk
  
  if(partition.disk_win_warn || partition.disk_win_crit) {
    vars.disk_win_warn = partition.disk_win_warn
    vars.disk_win_crit = partition.disk_win_crit
  } else {
    vars.disk_win_warn = "5%"
    vars.disk_win_crit = "3%"
  }
  vars.disk_win_path = partition.character
  if(partition.sla) {
	vars.sla = partition.sla
  }  

  command_endpoint = host.vars.remote_client
  assign where (host.vars.os == "Windows" && host.vars.remote_client)
}

Zone config (zones.conf)

object Endpoint NodeName {
	host = NodeName
}

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

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

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

object Endpoint "srv-im-crmsql" {
	host = "`x.x.x.x"
}

object Zone "srv-im-crmsql" {
	endpoints = [ "srv-im-crmsql" ]

	parent = "master"
}

Can you tell me where the config error is or what I am doing wrong?

Best regards,
Hendrik

2

Hi,
I don’t see a zone in your host definition. How your template defination looks like?

3

Hi,

neither the host nor service belong to a zone. This is ensured with e.g. moving the hosts.conf file in to /etc/icinga2/zones.d/master where this is automatically generated.

Rationale for this change is that versions before 2.11 might not have scheduled the host/service checks for command endpoint agents correctly without having a zone specified.

Cheers,
Michael

2 Likes
4

thanks for the Explanation @dnsmichi . We do not get it that way because as you know we use the director. :slight_smile:

5

Hi,

thanks for your response.

So I have to move my hosts.conf to folder /etc/icinga2/zones.d/master ?
My understand was that zones.conf is also read as it is included in icinga2.conf and there is a zone and an endpoint specified there.

Best regards,
Hendrik

6

Hi,

so I moved my hosts.conf from /etc/icinga2/conf.d/subfolder to /etc/icinga2/zones.d/master/hosts.conf and the config validates. Thanks!!

Is it best practice then to move all contents of conf.d to the master zone folder?

Best regards,
Hendrik

7

Yes, in case you’re using a distributed environment with agents, satellites, HA masters, it is. That’s proposed in the scenario documentation too.

Cheers,
Michael

1 Like
8

Hi,

I’m just using my icinga2 server as one master node and needed to use remote_client for local checks on windows machines. We’ve used this config for approx. 2 years now and I don’t even know if this is state of the art anymore…

Best regards,
Hendrik

9

Hi,

we had debugged problems at customers where conf.d + command_endpoint led to unchecked services, leading to a missing zone and authority declaration. In order to allow these environments to function in the same way as everything else, the config compiler and validation is now picky about this. Before it led into possible bugs and long lasting ticket sessions for troubleshooting this.

Cheers,
Michael

1 Like
10

Hi,

thanks for clarification. This seems perfectly valid :slight_smile:

I moved all files to my master zone. Were there some changes with functions? We use to functions which now throw an critical/config: Error: Invalid field access (for value of type 'Service'): '<function name>'. I did not find anything in the release notes…

Example:

function remove_trailing_percentage(val) {
  string_val = val.to_string()
  cropped = string_val.substr(0, string_val.find("%"))
  return cropped
}

apply Service "linux-memory" {
  import "generic-service-linux-ssh"
  
  display_name = "RAM-Auslastung"
  check_command = "by_ssh_linux_memory"

  if(host.vars.linux_memory_warn && host.vars.linux_memory_crit) {
	vars.by_ssh_memory_warn = host.vars.linux_memory_warn
	vars.by_ssh_memory_crit = host.vars.linux_memory_crit
  }

  if(host.vars.linux_distribution == "sles" || host.vars.linux_distribution == "centos7") {
    if(host.vars.linux_memory_warn && host.vars.linux_memory_crit) {
      vars.by_ssh_memory_warn = remove_trailing_percentage(host.vars.by_ssh_memory_warn)
      vars.by_ssh_memory_crit = remove_trailing_percentage(host.vars.by_ssh_memory_crit)
    } else {
      vars.by_ssh_memory_warn = remove_trailing_percentage(get_check_command("by_ssh_linux_memory").vars.by_ssh_memory_warn)
      vars.by_ssh_memory_crit = remove_trailing_percentage(get_check_command("by_ssh_linux_memory").vars.by_ssh_memory_crit)
    }
  }

  assign where host.vars.os == "Linux"
  ignore where host.name == NodeName
}

Best regards,
Hendrik

11

Please do me favor and create a new topic, including the full icinga2 daemon -C and all the config snippets to reproduce this in a small environment. I’d like to see where exactly this is now failing.

Cheers,
Michael

1 Like