Hi all One of our slave servers (running Debian), which we use for secondary MX and secondary DNS, is to be decommissioned by our bare-metal provider (OVH). I was thinking about moving (cloning) the system to a new server. Unfortunately the IP of the new server will be different since we didn't rent a failover IP for this one. Therefore all configs we have in our Master Server related to this Slave Server (DNS and MX) would point to a non-valid IP anymore. I was thinking about getting my hands dirty with mariadb and search and replace all instances of the old IP, but I'm not sure this will be enough, don't even know this is going to work. Any advices or procedures anyone can share? TIA Ignacio
Replacing the IP in the database and then doing a resync through the panel should work. I suppose it's mostly DNS configuration to allow transfers and send notices?
Hello, after so much testing finally last night we went through the migration. Everything went fine, and after rebooting the master and the slave newly comissioned server everything went fine but one thing: in the control panel, under monitor, data such as cpu info, memory usage, etc, won't show updated data from the new server, still showing data from the old one. We didn't detect this in our previous tests. is there anything we can do to fix this? TIA Ignacio
Most likely the new system is not able to connect to the master anymore. Run a ISPConfig update on the slave node and let it reconfigure permission in the master database.
Hi till and thanks for your quick reply. Before I do that I should mention that I did a quick test and I can create and delete, for example, web sites, in the slave server, I mean, orders from the control panel are executed in the slave server. Should I follow your instructions anyway? Thanks so much Ignacio
If this works, then monitoring should work as well. Check that the root crontab of the system contains the cronjob for cron.sh too. Then you could empty the sys_cron table on the slave node in the ispconfig database (important: empty just "sys_cron", not "cron") to reset the internal cron system. Finally, you can try to run repair and optimize on monitor_data table in master and slave ispconfig database. If all this does not solve it (wait a few minutes), then you can still try the update approach.