It’s been a long, long wait! But it’s finally here, the second part of the Icinga 2 tutorial that I’ve promised a while ago.

Last time, we set up an Icinga 2 server to which we are now going to add a host. Unlike with Nagios, you can add hosts “automatically” in Icinga 2 out of the box. That is, you have to do some things, but configuration is quite easy compared to getting started with NRPE. On top of that, it’s a lot more secure: all communication is secured by TLS with certificates, which Icinga 2 can set up for you automatically.

So, we’re going to add a host to our server. I’m assuming the host is running Ubuntu as well; any recent version will work.

Let’s get started!

The server node

In order to be able to add hosts securely, we have to go to the server and run the following command:

sudo icinga2 node wizard

This will start a wizard which will first ask you whether this is a satellite setup or not. Since this is the server or master you have to say ‘No’ here, to input an ‘n’:

Please specify if this is a satellite setup (‘n’ installs a master setup) [Y/n]: n

It then starts generating keys are certificates required for secured TLS communication. In addition to that, it adds these to the configuration, plus it ensures this server is listed as the master:

information/base: Writing private key to ‘/var/lib/icinga2/ca/ca.key’.
information/base: Writing X509 certificate to ‘/var/lib/icinga2/ca/ca.crt’.
information/cli: Initializing serial file in ‘/var/lib/icinga2/ca/serial.txt’.
information/cli: Generating new CSR in ‘/etc/icinga2/pki/icinga-server.csr’.
information/base: Writing private key to ‘/etc/icinga2/pki/icinga-server.key’.
information/base: Writing certificate signing request to ‘/etc/icinga2/pki/icinga-server.csr’.
information/base: Writing private key to ‘/etc/icinga2/pki/icinga-server.key’.
information/base: Writing certificate signing request to ‘/etc/icinga2/pki/icinga-server.csr’.
information/cli: Signing CSR with CA and writing certificate to ‘/etc/icinga2/pki/icinga-server.crt’.
information/cli: Copying CA certificate to ‘/etc/icinga2/pki/ca.crt’.
information/cli: Dumping config items to file ‘/etc/icinga2/zones.conf’.
information/cli: Created backup file ‘/etc/icinga2/zones.conf.orig’.

It then asks you for the host and port for the API. We have no reason to change these, so leave these empty:

Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:

It then finalizes setting up this server as a master my editing some more configuration files:

information/cli: Enabling the APIlistener feature.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
information/cli: Created backup file ‘/etc/icinga2/features-available/api.conf.orig’.
information/cli: Updating constants.conf.
information/cli: Created backup file ‘/etc/icinga2/constants.conf.orig’.
information/cli: Updating constants file ‘/etc/icinga2/constants.conf’.
information/cli: Updating constants file ‘/etc/icinga2/constants.conf’.
Done.

Now restart your Icinga 2 daemon to finish the installation!

With that done, restart Icinga 2 in order to use the new settings:

sudo service icinga2 restart

And the master is good for now. Let’s move on to the host node!

The host node

On the host node, we’re first going to have to ensure the Icinga 2 repository is present:

add-apt-repository ppa:formorer/icinga

Press ENTER when it asks you to.

Note: If this command gives you an error, run ‘sudo apt-get install software-properties-common’ to get the ‘add-apt-repository’ command!

Once the repository has been added, update apt:

sudo apt-get update

And install Icinga 2:

sudo apt-get install icinga2

With that out of the way, we can initiate the same wizard as we did on the master:

sudo icinga2 node wizard

This time we answer ‘Yes’ when it asks us if this is a satellite setup by just hitting ENTER:

Please specify if this is a satellite setup (‘n’ installs a master setup) [Y/n]:

After which is starts a different wizard:

Starting the Node setup routine…
Please specifiy the common name (CN) [icinga-node]:
Please specifiy the local zone name [icinga-node]:

It asks you for the common name and the local zone name for this server. These default to the system’s hostname in fully qualified domain name format. These master uses the common name to connect to the server and the local zone name to identify it in configuration files. I just let these be.

It then goes on to ask you about your master node:

Please specify the master endpoint(s) this node should connect to:
Master Common Name (CN from your master setup): icinga-server
Do you want to establish a connection to the master from this node? [Y/n]:

Please enter the Common Name of your master node (in my case ‘icinga-server’). This is usually the hostname unless you’ve changed it. Then press ENTER when asked if you want to establish a connection to the master from this node. This triggers the next question:

Please fill out the master connection information:
Master endpoint host (Your master’s IP address or FQDN): icinga-server
Master endpoint port [5665]:
Add more master endpoints? [y/N]:

Enter the master’s IP address or Fully Qualified Domain Name (FQDN) here and accept the default port. Also press ENTER in order to not add more endpoints: we’re just working with one master right now.

Then it’s on to the connection for CSR auto-signing, the bit of magic that makes setting up a secure connection a bit easier for you:

Please specify the master connection for CSR auto-signing (defaults to master endpoint host):
Host [icinga-server]:
Port [5665]:

Accept the defaults here as well, because the master we have entered before is also our server for CSR auto-signing.

After this, Icinga 2 is going to save some configuration on the host node and start the setup of a secure connection. As part of this process the master is contacted:

information/base: Writing private key to ‘/etc/icinga2/pki/icinga-node.key’.
information/base: Writing X509 certificate to ‘/etc/icinga2/pki/icinga-node.crt’.
information/cli: Generating self-signed certifiate:
information/cli: Fetching public certificate from master (icinga-server, 5665):

information/cli: Writing trusted certificate to file ‘/etc/icinga2/pki/trusted-master.crt’.
information/cli: Stored trusted master certificate in ‘/etc/icinga2/pki/trusted-master.crt’.

The certificate that has been set up needs to be signed in order to prove that you’re actually in command of both servers and approve of this secure communication:

Please specify the request ticket generated on your Icinga 2 master.
(Hint: # icinga2 pki ticket –cn ‘icinga-node’):

This means you need to run the following command on the master:

sudo icinga2 pki ticket –cn ‘icinga-node’

And copy the output from that command, which looks like ‘ff84267fca3b0b29c4c88d94706c76f4247cac34’ to the host node.

information/cli: Processing self-signed certificate request. Ticket ‘ff84267fca3b0b29c4c88d94706c76f4247cac34’.

information/cli: Created backup file ‘/etc/icinga2/pki/icinga-node.crt.orig’.
information/cli: Writing signed certificate to file ‘/etc/icinga2/pki/icinga-node.crt’.
information/cli: Writing CA certificate to file ‘/etc/icinga2/pki/ca.crt’.

With all certificates signed and in place, we’re asked about the API again:

Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:

Just like at the master, we’re not going to touch these here.

The wizard now asks you whether to accept the configuration and commands from the master:

Accept config from master? [y/N]: y
Accept commands from master? [y/N]: y

Select ‘Yes’ for both. Unfortunately, the Icinga 2 documentation is a bit fuzzy on this part. There are several ways to setup up a client, for example with a local configuration or as an execution bridge. I’m aiming for the latter of the two here: the master is in control and sends commands, the host node just executes them and returns the results. This is closest to what NRPE does and should keep all the data on the master.

With this done, everything is being put in place to make this work:

information/cli: Disabling the Notification feature.
Disabling feature notification. Make sure to restart Icinga 2 for these changes to take effect.
information/cli: Enabling the Apilistener feature.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
information/cli: Created backup file ‘/etc/icinga2/features-available/api.conf.orig’.
information/cli: Generating local zones.conf.
information/cli: Dumping config items to file ‘/etc/icinga2/zones.conf’.
information/cli: Created backup file ‘/etc/icinga2/zones.conf.orig’.
information/cli: Updating constants.conf.
information/cli: Created backup file ‘/etc/icinga2/constants.conf.orig’.
information/cli: Updating constants file ‘/etc/icinga2/constants.conf’.
information/cli: Updating constants file ‘/etc/icinga2/constants.conf’.
Done.

Now restart your Icinga 2 daemon to finish the installation!

After which you need to restart Icinga 2 on the host node:

sudo service icinga2 restart

And it’s back to the master.

Back to the server node (the master)

With the host node set up properly, only a few things remain on the master to be set up. First of all, we want to list the nodes on the master to see if our new host node is in there:

sudo icinga2 node list

The output should include the node you’ve just added.

Then, we update the configuration on the master so the host node is being included in checks, or in other words is being added to the master:

sudo icinga2 node update-config

The only thing that remains right now is to reload Icinga 2:

sudo service icinga2 reload

And we’re done! After a few minutes results should start popping up in the web interface!

• Author
• Recent Posts

mpkossen

Maarten Kossen was the administrator of LowEndBox from 2013 to 2015, and brought many ideas and improvements to the website during his leadership. Today he is member of our community and LowEndTalk.

Latest posts by mpkossen (see all)

• How to Rapidly Install Java, OpenJDK & Oracle JDK on your VPS - December 14, 2015
• It’s been a great ride - December 14, 2015
• Cheap Windows VPS – $21/quarter 1GB KVM-based Windows VPS in 11 worldwide locations - November 30, 2015