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

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

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

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

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?

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