Its time to migrate a single server copy of ISPConfig to a higher performance in-house brand new clean and empty server running Ubuntu 22.04. At the same time (or separately) I'd like to resolve a current error in the subdomain naming for the existing ISPConfig server. Currently, we have the ISP providing the internet setting a reverse.lookup for email to the subdomain A.domain.org. However, due to a setup error on my part, ISPConfig creates its certificates based on a different subdomain, B.domain.org. Is resolving this domain naming issue best done at the same time as the migration/ISPCopy or separately? Should I be using migration or ISCopy ? the current ISPConfig server is running Ubuntu 20.04 and has in the past had a couple of longstanding problems with some websites related to server crashes that my repairs left the ISPConfig arrangement a bit broken on some sites - so I'd welcome moving everything to a new installation of ISPConfig. I welcome your thoughts.
is this a website or is this the hostname of the system? Use the Migration Tool. ISPCopy is a special tool for moving nodes of a multiserver that shall stay connected to its master by doing an exact copy of the config. In all other cases, use the Migration Tool.
Thanks Till, I will use the Migration tool. The subdomain issue is the hostname of the server. The reverse dns is for the source ISPConfig server is A.domain.org and set up by the ISP providing our broadband service. It was difficult to get them to organise so I'd like to use that subdomain name for the FQDN for in the new target ISPConfig server. Mistakenly, I had previously put B.domain.org as the FQDN in hosts file in the source ISPConfig server and this has created problems with certificates in Outlook mail clients. Is there any problem migrating to a target server with a different FQDN?
No. You can set the right hostname on the new server before installing ISPConfig to it and then migrate the system to the new one which has already correct hostname.
Thanks Till. I've hit a problem with the migration. Running ./migrate I get the message to change the default shell from Dash to Bash. I've run chsh -s /bin/bash and echo $SHELL shows /bin/bash as shell but ./migrate still halts with the message to change the default shell from Dash to Bash. I welcome your advice.
The command to change the shell is: dpkg-reconfigure dash and then choose 'no' in the following dialog.
Everything moving ahead with migration dry run till I get 'different Letsencrypt client on Target - cannot copy Letsencrypt certificates'. Which is the preferred way forward? Do I just continue and assume the Target system will automatically remake the certificates with the new Letsencrypt client?
I now see you asked same question on it's own thread. You should have removed your question from this thread I do not answer it in vain. It does not. I think the preferred solution is to use same Let's Encrypt client on TARGET and SOURCE. If you can not do that, you need to remove the existing certificates on TARGET and force creation of them. There has been discussion about this on forum, search old (recent) threads.
Please accept my apologies for taking up your time unneccessarily. Your reply is helpful and I will search for the threads. I realised the question needed a new thread but didn't know that I could remove the early post. I realise now that I should at least have added a note to this thread to say I'd move the question to a new thread.
