Moving to alternate OS - how to migrate to a new Icinga master?

Icinga 2
1

Hello,
I was using Icinga2 on CentOS7 with IcingaDirector for some years now.
Since CentOS7 is EOL this year I am forced to move to an alternate OS.
Most hosts are monitored with agents (Win & Lnx) which use self-registration.

Which option do I have ? What approaches can be taken in general ?

Sadly I couldn’t find any clear answer searching the forum and the documentation also does not cover this topic.
I was thinking of things like:

  • setup new master from scratch and somehow integrate it into the existing Icinga2 hierachy/zones resulting in a 2-master-monitoring setup
  • setup new master and do some database export/import magic and it just works
  • IcingaDirector export/import of configuration baskets

I just need a general concept, no details: What could work vs. what I shouldn’t even try .
I want to avoid re-joining/re-configuring all agents to a new master.

Thanks in advance !
Kind regards,
Jan

2

Hi in Theory, if the host name stays the same, you could just install icinga and then move over all the files [1] from the old master. Before starting the icinga service on the new master some minor differences like user name icinga → nagions if moving to Debian would need to be handled.

For a different host name, I would look into deployment of Icinga2 via the Ansible.
The initial cost ist high but additional deployment will be a breeze and config as code makes also documents, who did what and when.

[1] don’t miss the files in /var/lib/icinga2/ and /var/cache/icinga2/

1 Like
3

Hi,
I sucessfully managed to move to Ubuntu 22.04 from CentOS7.
Besides /var/-related files as mentioned by Dominik I also did move additional files e.g. /usr/share/. In addition I performed dump/restore for the MariaDBs. You also need to manually recreate the database users afterwards. I did not change the FQDN, only the IP address. Therefore I have added a DNS-override for the FQDN to the new IP address. Only 2 out of 50 agents needed a restart the rest was just working/connected to the new host within a few minutes.

Regards,
Jan

2 Likes
4

Thank you for sharing, this will be very helpful end of the month. Did you have to regenerate and/or distribute any certificate?

We have the added constraints of:

  • having to change the hostname and IP address of both masters
  • having to manage the replication between two master nodes with a MySQL database also in replication mode

Any idea on how to deal with these constraints?

5

I think most important for my setup was that the hostname stays the same so the CN-attribute of the certificate still does match my master-node and I could just copy all elements/objects. If this was not matching I assume I would have to reconfigure all agents to accept the new certificate. Since it was matching I did not have to care about certificates or hostnames in any part of the configuration.
I think if you already do have 2 master nodes it is easier for you to add another 2 masters (the new ones) to the existing infrastructure and afterwards shutdown the old 2 masters. I do not think that you can stick to the same procedure as I did. But I am not really familiar with Icinga-infrastructure so this is only a feeling/guess. Based on the size of your infrastructure and the impact if the change fails I would advise you to discuss this with Netways or any other Icinga-partner. Your infrastructure seems a bit more complex than my single node deployment with < 100 monitored servers.

1 Like
6

I just had the confirmation from Icinga Consulting that the Certificate Authority defined on our current Masters can be copied over to the new Masters, so that all certificates created under that old CA and deployed on our agents will remain valid under the new (unchanged) CA.

1 Like