[SOLVED] Cluster Configuration - IP misconfiguration after Disaster Recovery

[rg2]

Hi.

I simulated a Disaster Recovey of my PMG installation (I created a new PMG instance using a backup) and everything went backup online. When I did this test, I only had the Master node configured on the Cluster Administration.

Now I created a second PMG installation and I'm trying to add it to the cluster as a node,. but I noticed something strange and I can't find a way to fix it.

This is the information I have on the Master:



I'm working on a cloud environment, so all IPs attached to the network interfaces are internal IPs. These IPs are randomly chosen at the time of the VM creation and can't be changed.

The first time I created the PMG installation, it had the IP 10.0.0.18. After I simulated the disaster recovery (built a new instance from a backup), the PMG got a new IP, it's now 10.0.0.150.



Now I can't add a node to the cluster because the Master has the wrong IP configured. I can't manually change the IP of the VM back to 10.0.0.18 (the previous VM IP), and I can't find a way to edit or remove the master from the cluster, so I can add it again with the correct (new) IP.

This is a very critical part of the PMG system. There should be a way to fix the cluster environment configuration after a disaster recovery.

How can I fix it? Thank you!

Best regards.
Rafael

 

[Stoiko Ivanov]

make sure the following is correct:
* /etc/hosts - the hostname must have a line pointing to the current ip
* /etc/hostname
* ping $(uname -n) has to work
* check the 'ip' lines in /etc/pmg/cluster.conf

I hope this helps!

 

[rg2]

make sure the following is correct:
* /etc/hosts - the hostname must have a line pointing to the current ip
* /etc/hostname
* ping $(uname -n) has to work
* check the 'ip' lines in /etc/pmg/cluster.conf

I hope this helps!

Hi Stoiko,

hosts file does not point to current IP, it only contains localhost IPs (127.0.0.1 localhost and 127.0.1.1 antispam-mx1) ---> this is default for all instances on this cloud platform

hostname is correct --- antispam-mx1


ping $(uname -n) does work, it successfully pings 127.0.1.1

And the IP lines in /etc/pmg/cluster.conf contains the old IP, the same that the GUI shows (10.0.0.18), which was the instance's IP when the cluster configuration was first created. After the disaster recovery, the instance got a new IP but the cluster configuration kept the old one.

Also, it seems this file (cluster.conf) is a read only file... can I force edit it? If Vi edits a readonly file, it will delete the original file and create a new one with the same name, but doing this may change some properties of the file (symbolic links, permissions, owner)

Can I edit it? Or should I change something else?

Thanks

 

[Stoiko Ivanov]

hosts file does not point to current IP, it only contains localhost IPs (127.0.0.1 localhost and 127.0.1.1 antispam-mx1) ---> this is default for all instances on this cloud platform

PMG needs to be able to resolve the ip to the hostname - usually this is done through an entry in /etc/hosts
-> update your /etc/hosts

Also, it seems this file (cluster.conf) is a read only file... c

you need to edit is as root user

 

[rg2]

PMG needs to be able to resolve the ip to the hostname - usually this is done through an entry in /etc/hosts
-> update your /etc/hosts

Just to let you know, on cloud environments the hosts files works differently, we can't edit it directly. I had to edit a template (specific to the cloud environment I'm working on) where I changed the default line 127.0.1.1 "hostname" to "current IP address" "hostname"

After that I was able to add a node to the cluster. Thank you for your help!

 

[Stoiko Ivanov]

Just to let you know, on cloud environments the hosts files works differently, we can't edit it directly. I had to edit a template (specific to the cloud environment I'm working on) where I changed the default line 127.0.1.1 "hostname" to "current IP address" "hostname"

After that I was able to add a node to the cluster. Thank you for your help!

Thanks for coming back and reporting how you fixed this in your cloud environment!