Adding downtimes/comments/acks via Satellite-API

Icinga 2
1

Hi all :slight_smile:

I’m trying to figure out how to add/remove comments/downtimes/acknowledgments via the satellites API to the master.

Setup is:
Master → multiple Satellite-Zones → Agent with no connectivity between Agent and Master
The API call is issued on the agent host or a different host that is only able to connect to the satellite and not the master
The master and satellite have /etc/icinga2/features-enabled/api.conf as follows.

object ApiListener "api" {
  accept_commands = true
  accept_config = true
  ticket_salt = TicketSalt
}

The debug.log on the master shows the following when firing the API call:

[2021-01-21 16:34:55 +0100] notice/JsonRpcConnection: Received 'config::UpdateObject' message from identity 'mvd-mgmt02'.
[2021-01-21 16:34:55 +0100] notice/ApiListener: Received config update for object: {"config":"object Comment \"e9d393df-641e-49dc-817a-8f47eaf6a629\" ignore_on_error {\n\tauthor = \"icingaadmin\"\n\tentry_time = 1611242636.607766\n\tentry_type = 1.000000\n\texpire_time = 0.000000\n\thost_name = \"mvd-d1-ts1001\"\n\tpersistent = false\n\ttext = \"This is a downtime.\"\n\tversion = 1611242636.607799\n\tzone = \"mvd-azure\"\n}\n","modified_attributes":{},"name":"mvd-d1-ts1001!e9d393df-641e-49dc-817a-8f47eaf6a629","original_attributes":[],"type":"Comment","version":1611242636.607799,"zone":"mvd-azure"}
[2021-01-21 16:34:55 +0100] notice/ApiListener: Discarding 'config update object' message from 'mvd-mgmt02' (endpoint: 'mvd-mgmt02', zone: 'mvd-azure') for object 'mvd-d1-ts1001!e9d393df-641e-49dc-817a-8f47eaf6a629' of type 'Comment'. Sender is in a child zone.

I hoped to get rid of the “Discarding object” with the accept_config = true, but that does not seem to be the case.

I have found an older post referring to the same problem, but I would like to know if it is possible without the workaround mentioned there.

Any tips and trick are much apreciated!

2

i would recommend sending the downtime api request to the primary master (or an haproxy cname) instead of the satellites other wise the request has to know which zone/satellite the host/service is in.

3

Thx for the feedback!
hm, sounds logical to me.
Nevertheless we don’t have network connetivity from the agents or hosts in their network to the master.Only to the(ir) zones satellite.

Seems like we really need to think about proxying.

4

you could send the downtime api request from anywhere that has connection to the master. just curious as the desire to have it be from an agent?

5

The terminal server team wants to integrate the API call when a server is shutdown (or started) on demand and set/remove a downtime for that host.

6

Follow up to this:
We implemented a quick and dirty HAproxy to listen on port 5666 on the satellites that then forward the oncoming requests to the icinga api on the master:5665

#---------------------------------------------------------------------
# Forwarder Frontend for Icinga2 API
#---------------------------------------------------------------------
frontend icinga2api_frontend
    bind SATELLITE-IP:5666
    mode tcp
    option tcplog
    default_backend icinga2api_backend

#---------------------------------------------------------------------
# Forwarder Backend for Icinga2 API
#---------------------------------------------------------------------
backend icinga2api_backend
    mode tcp
    option tcplog
    option tcpka
    balance source
    server master1 master1-fqdn:5665 check weight 1 inter 5s rise 2 fall 2
    server master2 master2-fqdn:5665 check weight 1 inter 5s rise 2 fall 2 backup

In case of SELinux this is also needed
setsebool -P haproxy_connect_any 1