Icinga2 Server/Agent Upgrade


I have a quick question, about the best approach in upgrading icinga server and clients.
Following documentation:

There is this note:

The default expected path for client certificates is /var/lib/icinga2/certs/ + NodeName + {.crt,.key}.
The NodeName constant is usually the FQDN and certificate common name (CN).
Check the conventions section inside the Distributed Monitoring chapter.

Does this mean that once the server is upgraded to 2.8, the clients will have to be on 2.8 as well, in order to communicated properly with the server?


I don’t think so. But I could be wrong :smiley:


it is the best practice to run the monitoring setup (master, satellites, clients (agents)) on the same Icinga 2 version.

You can run a master on version 2.8.0 and an agent on version 2.7.X, but if you facing any issues you should upgrade the client first and see if the issue is still there.

The changed certificate paths only changes the location for the local certificates (every node has a private key and a certificate). To use the CA proxy feature that came into Icinga 2 in 2.8.0 all instances must be on 2.8.0.

In 2.8.0 the bottom up mode was removed and clients lower than 2.8.0 tries to call a function of it, that fails when the master is already on 2.8.0 and generate a log entry. This was fixed in 2.8.1.

I would upgrade the satellites and clients as soon as possible, to have a fully supported environment.

Best regards

Hi Michael,

Thanks for the answer, but currently I run 2.6 on servers side and 2.6/2.7 on the clients (agents).
My concern was regarding the client - server communication, after upgrading server side to latest 2.8 version.
Meaning, will the a client (on 2.6/2.7) be able to communicate properly with the server or it is mandatory to upgrade client to 2.8 as well (due to the be new certificate system, etc.)
Following your reply, I would understand this is required.



Server 2.8.0 -> Client 2.7.X works, but I cannot guarantee it that there are no side-effects, but from my personal experience there are no (Currently I have some clients that are - unfortunately - still on 2.7.X and my Server is on 2.8.1).

While this works you don’t have a fully supported environment, so I suggest that you upgrade your clients as soon as possible.

Maybe there was an misunderstanding, but I though that was what I wrote about in my post. :sweat_smile:

If there are still some open questions, feel free to quote the passages from my post that are unclear. :slight_smile:

Best regards

Cluster messages should still work with 2.7 at least. In order to function properly, a general upgrade maintenance is recommended with 1) master 2) satellites 3) clients.

I need to get back to you with a question.
I attempt upgrading master nodes from v2.6.2 to v.2.8.4 by following the upgrade procedure:

Icinga2 update went well, now I have latest version (that is in the Icinga2 repository):
icinga2 - The Icinga 2 network monitoring daemon (version: r2.8.4-1)

I have adjusted /etc/icinga2 to match directives in the latest version, checking also from github repo:

MySQL update went fine as well:

mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/upgrade/2.8.0.sql
mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/upgrade/2.8.1.sql

First attempt to restart icinga2 throw in the logs:
critical/config: Error: Object 'generic-host' of type 'Host' re-defined:

Next, I commented out:
//include_recursive "conf.d"

Next attempt to restart icinga2, new error thrown:
critical/config: Error: Validation failed for object 'NODE_NAMEt!ping!Service notification' of type 'Notification'; Attribute 'command': Object 'mail-service-notification' of type 'NotificationCommand' does not exist.

The object “mail-service-notification” is defined in ./conf.d/commands.conf, but because I have uncommented it in the icinga2.conf it is no longer taken into consideration now.
What do I miss? Please advise…

Thanks a lot.

Is “/var/lib/icinga2/api/packages/director” deprecated?
I might have missed this part from docs? I removed the last generated folder within and then the restart went fine…

Please show the full error message, especially the one which tells about the duplicated object.

Your last comment makes me think that you’re now using the Director, is that something new to your setup?

I managed to make it work again, after removing the old director files and redeploying configuration.
Thanks for the prompt reply.