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
If only your IP address changes and nothing else, there is nothing to worry about: the certs are not linked to your IP address. To get back on your questions in the first post: 1: Yes 2: I think that when changing the IP entry itself (so instead of adding a new IP, editing a existing entry) this change will be taken over to the vhosts and there is nothing to worry about. You should test that ofcourse. Otherwise, you could automate it with PHPMyAdmin / a SQL query from the CLI and then run a resync for the webs 3: No, they are stored in the database. You can automate this with PHPMyAdmin (it has a easy search and replace function) or with a custom SQL query. 4: On your slave(s) you should have the IP address of the other server(s) in your hosts file (/etc/hosts). So you should put it there and change it when you switch to the new IP. The slave tries to connect to the master DB every minute. You might want to disable that by commenting out the ISPConfig cronjobs in your crontab: Code: crontab -e (remember to enable them after your moved the master server) When the master comes online again, changes will be replicated. Make sure to make a clear schedule what happens when. When will the master go offline? When will it be online? Schedule disabling the cronjobs before going offline, and re-enable after it is offline. When do you change the DNS records? Which query do you use? By making a clear schedule, you minimize downtime to a minimum.
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!