Background:
Ever since they started their business I was a client of XS4ALL, a Dutch ISP that invented Internet for the everyone in the Netherlands back in 1993. They provided the best no-nonsese internet connections for nearly 30 years. Fixed IP, reverse DNS, IPv4+IPv6, no closed ports and great support on top of it. A splendid connection for a MIAB, which I used happily on it since 2016.
Alas, as these things seem to go these days, a while ago XS4ALL was usurped by KPN, our national telecoms pride. This would not change anything for us, subscribers, we were told. Well, that turned out to be a lie. A big one. On all accounts.
So I had to transfer MIAB from my home line to a VPS in the cloud, just like everybody else here. An experience that learned me a couple of things that others might find handy.
-
The most important lesson I learned was: read the ‘upgrade’ instructions and keep yourself to it. Do not try to be smart. In my case I thought it handy to generate a VPS with a different name as the original box: box1.mydomain.eu.That seemed a smart thing to do as you can setup and test the entire box before you change over to it. Until you restore a backup. This does work, you get all your mail back, but then you run into a lot of trouble with certificates that were issued for different hostnames. I could not correct that easily so in the end I just generated a VPS with the same name as the original: box.mydomain.eu and that got rid of that problem.
-
There is an issue with restore that cripples the upgrade, at least in my specific case. The problem occurs while restoring the data from the old box. This gives an error (17) to the effect that it cannot restore a symlink called ssl_certificate.pem in the /home/user-data/ssl directory. What happens then is that, when you issue the ‘mailinabox’ command later to finalize the upgrade this bails out with a failure to start nginx.
The easiest way to solve this is, right when you have installed the new box for the first time, to remove all contents from /home/user-data/ssl. Then the restore does not give an error, the file gets copied and later in the ‘mailinabox’ command runs flawlessly. -
Probably clear to other people but not immediately to me: After installation of a new system and after restoring the backup from the old box, the system is ready. However, if you make backups from this new system these backups get encrypted with a new keypair. So you need the safely store the new secret_key.txt file to ever read back the new backup files.
-
If you backup using rsync no local backup is made. No problem, but not what I expected.
-
During the initial install on the new VPS the install process for nextcloud shows an error that it is unable to write into the config directory. AFAICS that had no implications. After restoring and issuing ‘mailinabox’ to finalize the upgrade the error is gone. And Nextcloud works fine.
-
Nothing to do with MIAB, but make sure that any designated secondary nameservers are working and able to renew the info from the primary (the box). I had a problem with one of them which led to DNS problems until I solved the issue on the secondary.
-
Don’t forget to remove the locally loaded backup files after a successful restore. They take a lot of space which used to be free but that I now have to pay for
-
Don’t forget to configure the backup for the new box, as these settings seem not to be backed up.
-
Don’t forget to read and act on this to save you some frustration later when the time comes that licenses are automatically renewed.
All in all I found the entire process of moving from one server to another on working quite well. It still amazes me how well designed MIAB is. Many thanks for everyone involved in its creation an support!