Migrating i-MSCP from Ubuntu to Debian - pitfalls?

Well, technically that seems to be correct. That tutorial is only meant for a direct switch to another server (same OS). So you need to keep that in mind. Means it may differ from the tutorial.

I wouldnt do that without a full back. Means, save the databases manually (every one as a single backup).

Plus, make sure to backup the /var/www/virutal/*domains*/backup folders.

Do a manual backup from your mail system as well and if needed, from the roundcube/etc db as well.

Do you use the server just for your self? If yes, I would do something else to keep it as clean as possible.

Importing the mail data isnt the problem.

Simply backup the mail folder, in general: "/var/mail/virtual/*" .

Create the domains again and then the mail accounts, after that copy every folder back to: "/var/mail/virtual/*".

The next step is runing this command: "perl /var/www/imscp/engine/setup/imscp-reconfigure --fix-permissions" after it.

If you use roundcube or similar and you created contacts and so on, you should create a backup of that database too. Thats not getting saved automatically.

After that, you can see the mails like nothing happened (I already did that myself and it works pretty much fine).

Btw, if you are going to install Debian. Make sure to use Stretch at least, but please dont use Buster. Buster isnt (at the moment) not really supported from i-MSCP.

cynric

Good morning,

First, I'm assuming that you're comfortable with rsync(1) and mysql(1) command line tools, and that you have a fresh/base installation of Debian Stretch (new server).

To migrate one i-MSCP instance to another server, you need to follow the following steps:

1. Install the SQL server on the new server. It MUST be the same vendor/version as on the old server.
2. Backup your /etc/mysql directory on your new server (just for safety).
3. Rsync both, the /etc/mysql and /var/lib/mysql directories from the old server to the new server. Note that you MUST NOT do that while the SQL server is running on the old server.
4. Start the SQL server on the new server and check that all is working as expected (connecting through mysql(1) command line tool, querying and so on)...
5. Update the servers_ips table in the i-MSCP database manually through the mysql(1) command line tool. You need update the IP address and network interface name...
6. Set both the admin_sys_name and admin_sys_gname columns to NULL in the admin table of the i-MSCP database (for all rows): UPDATE admin SET admin_sys_name = NULL, admin_sys_gname = NULL;
7. Set both the admin_sys_uid and admin_sys_gid columns to 0 in the admin table of the i-MSCP database (for all rows): UPDATE admin SET admin_sys_uid = 0, admin_sys_gid = 0;
8. Disable all plugins in the i-MSCP database: UPDATE plugin SET plugin_status = 'disabled' WHERE plugin_status NOT IN ('disabled', 'uninstalled');
9. Rsync the /etc/imscp directory from the old server to the new server.
10. Rsync the /var/www/imscp directory from the old server to the new server.
11. Rsync the /var/www/virtual directory from the old server to the new server.
12. Rsync the /var/mail/virtual directory from the old server to the new server. You SHOULD NOT do that while both the SMTP (Postfix) and IMAP/POP servers are running on the old server.
13. Update the /etc/imscp/imscp.conf configuration file (hostname, IP address)...

Once all that is done, you need to download the identical i-MSCP version archive on the new server and run the installer as follows: perl imscp-autoinstall -dx. This command will install all missing distribution packages, and rebuild all configuration files for the various services and so on... This will also fix all permissions recursively, including new UNIX ownership for your customers as those will get resetted.

After the installation, you'll have to re-enable the plugins. Generally the way to go is to force an update command for each of them, manually because if those are correctly implemented, this will install the missing distribution packages and reconfigure the whole:

1. Shutdown the i-MSCP daemon: service imscp_daemon stop
2. Update the plugin status to force update: UPDATE plugin SET plugin_status = 'toupdate';
3. Execute the tasks processor manually: perl /var/www/imscp/engine/imscp-rqst-mngr -dv

Of course, you could have some issues while the process, depending on the plugins you're using... If so, we can always help you.

Once all is working as expected, don't forget to start the i-MSCP daemon again.

Depends on your DNS settings. If you disable IPv6 for the old server and direct the IPv4 to the new one, it should work. You can always change the DNS settings fully to the new server, it just might take a few hours to take effect.

To the letsencrypt part, do you use the plugin or do you use certbot?

Quote from cynric

I do have trouble with the i-MSCP service Lets Encrypt certs though. These were are still present from the old server and linkes to its hostname. If I click renew that won't work because Lets Encrypt expects the validation to be on the old server's hostname. I probably need to remove the existing certs from i-MSCP to have it request new ones instead. How can I do that?

Best try to delete the related row in the letsencrypt table of the imscp database, then, retry. You should also remove the related row in the ssl_certs table of the imscp database.

Quote from cynric

The next thing that gives me a headache is switching the mailserver over. Rsyncing the contents worked well, but my old mailserver is running in dual stack mode and my DNS "mail." records (which is the target of my MX record) A and AAAA currently point to it. The server switch tutorial suggested using rinetd to redirect service requests to the new server. However rinetd does apparently not support IPv6. So if I stop Postfix and Dovecot and just setup the IPv4 redirect (while still having the old IPv6 mail record out there), will this work? Or will it lead to remote servers trying to deliver mails via IPv6 and failing miserably?

You mean, for the DNS propagation time? What was the TTL set for your DNS record? If the TTL is not so big, I would advise to just shutdown the SMTP server (old server). Most SMTP servers will retry mail delivering for the next 5 days... So yes, mail delivery will be a bit delayed that way but this is the easy way.

Another way would be to setup the old mail server relayhost parameter and remove the local maps for the mail account/domains. Then the mail would be redirected to the new server which would accept or not the mails according its local maps. That being said, I don't know any MX that prefer IPv6 over IPv4...

Edit: Sorry DrCarsonBeckett We posted at the same time and so I didn't see your answer before...