Critical/cli: Ticket salt (--salt) must be specified

Icinga 2
1

I’m running an Icinga2 dual master configuration and having difficulties to establish the connection between a client node and my masters. I’ve successfully connected my client node with the icinga node wizard method, to one of my masters. However, there’s a problem with creating a connection with the second master. As on the other master, I wanted to create a ticket with

icinga2 pki ticket --cn '…'

Unlike on the first master, this is not working and the following error shows up:

critical/cli: Ticket salt (–salt) must be specified

Is this because this master was configured as a client in the first place (to establish the connection to the real master), and then was configured as a second master?

Informations about my Setup:

  • CentOS 7
  • Two Icinga2 masters with their config mirrored with NFS on an external OS. So if I turn one master off, Icinga automatically switches to the other master to keep running.
  • As long as my active master is the one, I’ve established a connection to the client node, monitoring is working fine. But as soon as I’m switching to the other master, obviousley it says that there’s no connection to the master for this client. Remote Icinga instance … is not connected to master

Thanks for your help!

2

Hi,

in order to generate such a ticket, the salt must be configured. This is done automatically by the setup wizard for a master, specifically by generating a random private key hash and putting it into constants.conf for the TicketSalt constant. This value is then read by pki ticket and used to generate a ticket number based on the salt and the given CN.

In order to fix this, you can manually generate a private key for the TicketSalt, e.g. by using openssl:

echo "const TicketSalt = \"$(openssl rand -base64 30)\"" >> /etc/icinga2/constants.conf

Keep in mind that not only the ticket is required, but also the CA key pair for later CSR auto-signing when a satellite/client connects to the secondary master. Best is to only have one master doing the signing tasks, but you may rsync /var/lib/icinga2/ca to the secondary master then too - or have that put onto NFS/DRBD.

This specific case would also need the private TicketSalt to be shared, so it is better to also have the same value on the secondary master. In case you cannot sync constants.conf, split it up into a dedicated include in icinga2.conf on both masters.

Something like

cat >/etc/icinga2/signing.conf <<EOF
const TicketSalt = "..."
EOF

cat >>/etc/icinga2/icinga2.conf <<EOF
include "signing.conf"
EOF

Cheers,
Michael

3 Likes
3

Hi! Vielen Dank für deine schnelle Antwort! Der erste Schritt hat bestens geklappt. Für die weiteren Steps muss ich wohl etwas herumprobieren und üben, da ich eher ein Anfänger bin. Aber vielen Dank für deine Unterstützung!

4

Please stick to English to allow others to join the conversation as well :slight_smile:

In terms of moving the CA to the secondary master, a simple copy/scp/rsync should be sufficient.

1 Like
5

I’ve made all the steps and I’m getting the following warning with icinga2 daemon -C: (on both masters)

warning/Value for constant ‘TicketSalt’ was modified. This behaviour is deprecated.
Location: in /etc/icinga2/signing.conf: 1:0-1:52
/etc/icinga2/signing.conf(1): const TicketSalt = "key from constants.conf"

Any suggestions? Thank you!

EDIT: On one master it says …signing.conf… and on the other master it says …signing.conf(1)…
Could this mean, that it’s sharing this file between the two masters and there’s a conflict?

6

Remove the line from constants.conf which says TicketSalt, forgot about this.

8

This fixed the warning. Thank you!

I have now connected my client (testhost.home) over the icinga2 node wizard with my two masters (icinga2a.home and icinga2b.home). In the node wizard it’s asking if I’d like to add another master, so I did enter my second master there. Interestingly, it was only asking for the key of the second master (icinga2b.home)… but config was accepted and everything looked fine.

On the icinga2a.home master, I’ve added two .conf files in /etc/icinga2/zones.d/master. testhost.conf and services.conf
The client is showing up on icingaweb2 (on both icingaweb2 from the two masters), but the checks won’t work, regardless of which master is running / performing the checks:

Remote Icinga instance ‘testhost.home’ is not connected to 'icinga2a.home’
or
Remote Icinga instance ‘testhost.home’ is not connected to 'icinga2b.home’

testhost.home:
cat /etc/icinga2/zones.conf

/*

  • Generated by Icinga 2 node setup commands
  • on 2019-03-14 09:19:16 +0100
    */

object Endpoint “icinga2a.home” {
host = “192.168.10.120”
port = “5665”
}

object Endpoint “icinga2b.home” {
host = “192.168.10.121”
port = “5665”
}

object Zone “master” {
endpoints = [ “icinga2a.home”, “icinga2b.home” ]
}

object Endpoint “testhost.home” {
}

object Zone “testhost.home” {
endpoints = [ “testhost.home” ]
parent = “master”
}

object Zone “global-templates” {
global = true
}

object Zone “director-global” {
global = true
}

from the client:
netstat | grep :5665
tcp 0 0 testhost:45208 192.168.10.120:5665 ESTABLISHED
tcp 0 0 testhost:41466 192.168.10.121:5665 ESTABLISHED

1 Like
9

It seems to be working now. I’ve gone through de node wizard process again, but this time I’ve switched the order of the masters. First the 2b and as an additional master, the 2a.
It looks like, its up and running on both masters now :blush:

1 Like