Thank you so much, Josh and all contributors. My stuff is working. The upgrade to 18.04 and v0.40 was very smooth. I am so happy with it!
Something I just thought of concerning a final step for the migration – the secret_key.txt file changes as part of the reinstallation under 18.04 and v0.40, and I think a reminder to store the new post-upgrade secret_key.txt safely would not go amiss.
Followed the instructions above and it was perfectly smooth sailing: did final backup to S3, rebuilt machine (Linode) to 18.04 so IP address etc stays the same, installed miab, pulled backup down from S3…PERFECT! Everything was there as if I’d never changed a thing.
Possible Gotcha Some people may overlook that even though their config is restored, it is not truly restored in it’s entirety i.e. the backup configs (from /home/user-data/backup) are not restored since they are not part of the backup in the first place. Thus you need to manually reconfigure backups via the admin control panel.
Perhaps it goes without saying, but a new machine (even if you use Digital Ocean’s rebuild option instead provisioning a new VPS) means a new ssh host key on the MiaB, and if you’re fetching local backups from the MiaB instance to somewhere else, you gotta update the known_hosts file, too, else your offsite backup scripts will get the man-in-the-middle warning.
So ALL aspects of the backup routine (local and remote) need to be checked and updated.
Just want to add that since a year I use a separate disk mounted on /home/user-data , it is a nice approach as running out of space won’t harm your system root partition and makes backups with snapshot easier.
Now I can just create a new instance with Ubuntu 18.04 and attach the same disk to the new machine without having to restore or copy (a process that can be slow), making total downtime just a minute longer than the setup script
Maybe a good thing to do since a lot of users will switch
Hey @JoshData - you may want to recommend WinSCP to users instead of FileZilla. Earlier this year the dev for FileZilla started shipping releases with “bundled offers,” i.e. adware. Some of the bundled stuff led to more bundled stuff that was straight-up malware.
Hi! Thank you for the great work on this release! I followed your instructions and I was able to go through the upgrade, and now I have a 18.04 droplet humming like a bird.
Some experience notes:
When I chose to destroy and rebuild the droplet as 18.04 I discovered that it did not include my ssh key. So, then I created a new separate 18.04 droplet with my ssh key included from which I then took a snapshot backup.
When I then selected to destroy and rebuild the droplet I was not able to select the newly created snapshot. It turned out that I had to resize my old 10$ droplet to the new 10$ 50GB droplet type. I was then able to select the new snapshot and rebuild from that.
When I tried to ssh into the newly rebuilt droplet I had to give a root password, which had been sent to me on my Digital Ocean mail which was hosted on my mailserver. So, I had to restore my 14.04 DO snapshot, have it running, before I could change my DO account email to an email not hosted by MIAB while I was upgrading the droplet.
After changing the DO account email I was then able to rebuild and log into the 18.04 droplet. I then installed MIAB and uploaded my local backups and did a restore which worked well.
My migration to Ubuntu 18.04 went flawlessly minus one issue. PHP files are not being processed in my www/default directory. I have a one line file that just echo’s a string. In Chrome I get a 200 HTTP response but an empty page. No errors in access or error nginx log files. Anyone have this similar issue? Any help appreciated.
My suggestion for everyone would be to make sure to copy the latest secret key somewhere safe. Test it and make sure it will actually decrypt the backup files.
Unfortunately, it seems the old secret key I had stored from when I first setup up MIAB is bad and will not decrypt any duplicity backups. I should have tested my backups before doing this process. I’m now stuck with useless backups and will have to start over from scratch. Live and learn, I guess.
Deployed an Ubuntu 18.04 VM, installed MIAB using the script, copied my user-data from the 14.04 VM to the 18.04 VM. Rebooted the server. A bunch of DNS errors in the admin interface status page. Waited for some hours and nothing changed.
Made a change to one of my domains (deleted a forwarding domain then re-added it) and got a general error in the admin interface (something like ‘Error Adding Domain’) - but then all the DNS errors went away, and mail started pouring in.
I succeeded in upgrading without too much trouble. A couple of things I could have done with - the restore from backup command says you need to use the path to the backup, however, what it actually wants is the path to the encrypted folder inside the backups folder, that is (by default) /home/user-data/backups/encrypted. One thing worth knowing is that it can take a long time to copy a backup to a new server, so I recommend using rsync rather than filezilla or scp - a first sync of backups might take an hour, but after a repeat backup, a second rsync only takes a few seconds, meaning you can have less downtime for your users. In case you’re wondering, an appropriate rsync command would be:
The --delete option is there to ensure you don’t get any obsolete files in your destination folder after a repeat sync (e.g. files that were obsoleted by a repeat backup).
The other small change I made was to preinstall the ppa:ondrej/nginx-mainline PPA. This resulted in it installing nginx 1.15.8 and openssl 1.1.1, meaning I could get latest TLSv1.3 support, and that all worked fine for admin and webmail. I also tightened up the default sshd_config settings to remove some old cruft, insecure MACs, ciphers etc - I could turn that into a PR if anyone’s interested.