Migration of Master Server to New DataCenter. How to deal with the new IP?

Hi there

I'm in the process of testing, previous to a real migration of our Master Server, running Debian 9, to a new DataCenter. Both Our Master and Slave servers have apache2, amavis, postfix+dovecot, and bind9 services enabled. Both servers are used to host web sites and mail accounts, route and relay email between them, having bind acting on Master as Primary Zone DNS Server and Slave as Secondary DNS Server. Our new Master server will have a different IP address, so my main concern is how to deal with that, since software adaptation to the new hardware has already been taken care of (I just needed to readjust network, mdraid settings and grub). So, if I may, I'd like to verify with you experts on ISPConfig the procedures to follow.

1.- On Master server, I will have to go to System, Server IP addresses, I will have to change current IP for the new one (IPv4 and IPv6)
2.- Since each and every web site has a declared IP (the old one), I must change all hosted sites to their new IP. Can I do that with Tools->Resync, or must I do it manually for each web site?
3.- I believe (please correct me if I'm wrong) DNS records are not saved in the ispconfig database, but directly in bind config files. There are so many DNS records pointing to the old IP address. Is there a way to automate the change, or will I have to change them all individually?
4.- Is the Slave Server, at some point, requesting info from Master, or is it Master sending changes to Slave? I'm not sure whether I should put Slave offline while doing changes on Master. Changes on Slave will only be related to DNS records. Will they be replicated afterwards when I put it back online?

Is there anything else I should be aware of?

Thanks very much in advance

Ignacio

 

DNS records are stored in database. The bind configuration files are written using the data from database.

 

1. I think so unless you use local ip for them, therefore I think they need no changes if you can assign it the same local ip. Public ip for ISPConfig GUI however need to be changed at its dns server.
2. I think so too and I think this can be done via PMA and then run resync will help you update the rest.
3. As said by @Taleman and I think similar as above you can do via PMA and then run resync as well.
4. I think the first and not the latter. I think we normally do the slaves first and lastly the master.

 

Additionally, I think if database access from slaves to master was using public ip or if it was using local ip but they are also changed, ensure you change that ip access in the main database.

 

Hi there. Sorry I could not answer before, as I've been out of reach for several days. Thanks for your comments. I already checked and found all the entries in the databases. Changing those using a mysql dump should be quite straightforward.

Fortunately for me, some days ago I found out there is something else I gadn't realized and it is quite important, and that is all LE certificated that we have on the server. First I thought that launching a certbot --force-renew would take care of everything, but right now I'm not so sure, since there is at least some operations going on at the ssl subdirectory in the hosting main directory.

Has anybody gone through the process of updating LE certs in a batch, or manually? I've checked previous ahrasis' posts (I know he's a guru on that), but I'd like some confirmation before I get my hands dirty... for my peace of mind

Thanks so much

 

I wouldn't go for manual batch or force renewals but I would normally test letsencrypt renewals using --dry-run parameter.

If there are errors, I'll fix them, then if all are successful, I'll let ISPConfig do their renewals as normal i.e. via its cron job, which I think is the best way.

 

Hi guys

After some minor setbacks this weekend I managed to to the whole migration. It worked as you all mentioned. I'm so grateful to you.

Happy holidays!