Ubuntu Migration Plan

It is the end of the year, so that means we only have 4 months until Ubuntu LTS 14.04 will be thrown out the window, because it will be May 2019, 5 years after Ubuntu LTS 14.04 was created, and will lose support.

Now, we have a Ubuntu Bionic branch. What is the plan for switching people over to Ubuntu LTS 18.04, because it will need to happen within the next 4 months.

Is there an emailing list where we could notify people they will need to switch? I understand that Ubuntu Bionic github branch working last time I tried it. Can we create a period of time (maybe 2 weeks to a month) where both branches are supported, and encourage all new downloads to be for Ubuntu Bionic?

The big next step is testing the ubuntu_bionic branch enough for it to be ready for general use. There’s one outstanding bug for fresh installs and a few pull requests on GitHub that have to be looked at.

After that, we’ll release it. If all goes well, v0.29 will be the last version to support Ubuntu 14.04. We’ll support Ubuntu 14.04 until it’s EOL’d. But the Mail-in-a-Box website will only mention Ubuntu 18.04 going forward.

As I last understood, the plan was that the first release for 18.04 would do the system upgrade from 14.04 to 16.04 to 18.04 … did I understand that correctly? Or will we need to reinstall from scratch on a clean Ubuntu 18.04 ‘droplet’ when v 0.30 is released?

Will you also confirm whether ALL current instances of MiaB will need to be running v 0.29. I am certain that there are likely some people who are running older versions of MiaB (yes, I am guilty on one instance myself) and will need to know this.

Any current information on the planned upgrade path would be appreciated so that we can start preparing now.


The only upgrade path I am considering supporting right now is creating a fresh Ubuntu 18.04 box from scratch and then doing a backup + restore to move old files over. A lot of things can go wrong during upgrades and it can leave the box in a lot of different configurations, so I don’t really want to encourage anyone to go that route.

Because of limitations in ownCloud/Nextcloud migrations, the Ubuntu 14.04 box must be upgraded to v0.28 or later before the backup + restore process or else Nextcloud may not be able to migrate its data to the current version.

I fully agree with your thoughts and reasonings. Thanks for choosing what will hopefully be the path of least resistance. I have seen some of those upgrade issues and they are not pretty.

Are there any anticipated issues with the backup/restore between different versions? I know in the past there have been reports on the forums of upgrades from one version to a newer one using a backup not going well. Any suggestions to alleviate any possible issues that may come in to play?

1 Like

I think the one thing missing from the existing backup/restore instructions is that a directory maybe needs to be created first. Other than that, I’m not sure. :expressionless:

Are you in need of any help with beta-testing? Please advise how to proceed if so?

This will take you literally 15 seconds to look at and fix. It is super simple: https://github.com/mail-in-a-box/mailinabox/pull/1487 . This is my first pull request ever! :smiley:

My first pull request was an epic fail on the wrong branch. I found a fix that takes 15 seconds to look at one line change: https://github.com/mail-in-a-box/mailinabox/pull/1488 .

Thank you! I will merge it right now (the second PR). :slight_smile:

Hey, I’m kinda bored, so I’m gonna see if I can fix as many bugs as possible, since this project doesn’t seem that difficult to look at and reverse engineer the code. It looks like there are a ton more bugs than what the one I fixed.

I wanted to know if you would be willing to have just one more version for 14.04, if it can streamline the end-user process of upgrading to 18.04. I want to call it V0.291, since I feel like it shouldn’t be a full V0.3 .

I’m thinking of a few processes to streamline the switch (once Ubuntu bionic is mature enough):


We replace https://mailinabox.email/setup.sh with bash script that detects which version of Ubuntu a user is running. If the user is running 14.04 and there is no mailinabox detected, it will throw an error saying “Ubuntu 14.04 is no longer supported, please install this on Ubuntu 18.04.” If the user is running 14.04 and mailinabox is detected, it will set the user up with SSH/FTP, to prepare it to migrate the data that needs to be migrated.

Then, if the script is running on Ubuntu 18.04, it will do an install. On the Ubuntu 18.04 control panel would be an option to migrate data from 14.04. The user would then be able to submit the address for the FTP/SSH server and paste the private key. From there, the new server would pull data needed from the old server.



We install a virtual machine manager, throw all the old stuff in there, do a dist-upgrade, pull everything from the virtual machine onto the host machine, and get rid of the guest machine and virtualization thing.



We have a script that does a dist-upgrade, then writes-over everything when it’s at Ubuntu 18.04, keeping all the save data.

Would it be reasonable to make a few different options for upgrading, and let the user try which ones they want? Maybe have a “recommended” one, and have other less-recommended methods? I mean, we’re not only bound to one solution.

We’re bound by my time more than anything else. Even if you can get it to work, I need to be able to review it, and the more complicated it is, the more time it will take, and as things are going I just don’t get to things that take more than a few minutes to review.

Also, just as a practical matter, I really don’t think in-place upgrades are possible to make work seamlessly, and if they’re not seamless then we’re going to have a lot of stuck users to help. Making the backup/restore process easier for users to do is the best path.

I had just tested the latest commit, and it seemed to work. I got it to install on a clean box, create the admin user, nginx was actually working, and the admin console displayed what it needed to. That was as of 13 December 2018 10PM (Arizona, UTC-7), 14 December 2018 12AM (Washington DC, UTC-5), 14 December 2018 5AM (Greenwich, UTC-0 or UTC).

Now, I cannot confirm I can send/receive mail, but if it does show itself to work, can we actually make that an official release, @JoshData? Is it actually time? :smiley:

Hi, any timetable for the 18.04 release? I want to migrate to a Amazon lightsail box and they only offer 16.04 and 18.04 releases…

It might be awhile until MIAB is ready for prime time on 18.04 @JoshData knows more about that however.

That said if you need something right now that is more urgent, PM me, maybe I can help you step in the right direction.

I’m going to be very busy for about the next month so there’s no particular timeline. But the ubuntu_bionic branch on github is probably working and if you’re willing to help sort out any bugs you encounter while using it, I’d recommend using it for Ubuntu 18.04.

Yes, @slave2anubis, I, and a couple others here have said that the current development build for ubuntu_bionic works. However, in order to make an “official” release, my impression is that there has to be more extensive testing and the maintainer has to be more confident that it works and is tested to make the Ubuntu bionic development build an official release.

However, for reasonable purposes (i.e., non-business critical assets that can survive being corrupted), it is reasonable to try out the Ubuntu bionic release.

As I have said a few times on here, here is the command for getting the development build on your Ubuntu 18.04 box:

$ git clone --single-branch -b ubuntu_bionic --depth=1 https://github.com/mail-in-a-box/mailinabox.git
$ cd mailinabox
# bash setup/start.sh
1 Like


I’m going to test the 18.04 ubuntu_bionic branch upgrade on my system.

Can someone please point me to the install instructions to test?

My upgrade and test plan (untested instructions):

  • give users plenty of notice of when downtime is.
  • make sure updated to v0.29 of mailinabox.
  • take a snapshot on digital ocean of the mailinabox droplet.
  • convert backups to snapshots on digital ocean for the mailinabox droplet (so they are kept after “rebuild”).
  • make sure backup files are copied offsite and current ( https://mailinabox.email/maintenance.html#moving-boxes ). If you haven’t done a backup restore before, perhaps try restoring them on a separate practice droplet (you should practice restoring anyway!!). If you want to be extra safe do a practice restore anyway.
    And make sure you force a backup locally before you back up the files offsite. So that your backup is current.
cd mailinabox
sudo management/backup.py
  • create a fresh Ubuntu 18.04 install (keeping the same ip, use Droplet -> Destroy -> “Rebuild”. Make sure convert backups to snapshots, and make sure your backup files are current up first!!)
  • On rebuilt fresh install… check out ubuntu_bionic branch of mailinabox git repo, and install mailinabox.
$ git clone --single-branch -b ubuntu_bionic --depth=1 https://github.com/mail-in-a-box/mailinabox.git
$ cd mailinabox
# bash setup/start.sh
$ mv /home/user-data /tmp/user-data.bak
# do restore here...
  • rerun sudo mailinabox now that your old files are back.
  • test system (send/get emails, calendar, admin section, etc). Look at system checks: https://mailinabox.email/guide.html#checks
    You will see this failure message because you are running an unsupported pre-release version of mailinabox.

:heavy_multiplication_x: A new version of Mail-in-a-Box is available. You are running version Unknown. The latest version is v0.29. For upgrade instructions, see https://mailinabox.email.

  • test backup and restore of backup files also works (on a separate droplet).
  • if testing of system fails: restore from digital ocean snapshot.
  • if testing of system passes: make mental note to buy mailinabox people another beverage in the future, and do happy dance.
  • keep snapshot backup around for a few weeks in case something wrong in future is noticed.
  • keep copy of backup files in case need to restore from them again in the future.

Why “rebuild” on Digital Ocean? It keeps the IP address (it took months to gain reputation on the IP).
Your droplet will be rebuilt using your snapshot image, permanently destroying anything currently on the droplet, but keeping the IP address.https://www.digitalocean.com/community/questions/how-can-i-keep-ip-address-of-destroyed-droplet-after-i-recreate-it-using-a-snapshot-from-another-droplet

Note: these are untested instructions. Corrections very welcome!


Just one minor thing that you did not mention – and most likely should not need to be mentioned, but we all know that not everyone does updates when they are released …

Be sure that you are updated to the current version of MiaB (v 0.29) before you attempt the migration to Ubuntu 18.04. @JoshData noted recently that v 0.28 is also supported though originally he said that v 0.29 was required. I like to err on the side of caution.

1 Like

Oh, yes. Thanks for that.