Sanity check on moving from Ubuntu 14.04 to Ubuntu 18.04

1

Hi,

I’m finally taking the plunge to move from my MIAB V0.28 Ubuntu 14.04 to MAIB V0.51 Ubuntu 18.04. yes I know, I am not only late to the party, the party is well over, the cleaning is all done and they’ve moved home without leaving a forwarding address. In my defence, we were tied into a container running Ubuntu 14.04 for a number of years and it never quite worked out for when to move. Also MIAB just worked so no big deal.

So we’re preparing for our move, we have a number of mail domains and a number of web services and around 20GB of mail. We have a new server to move into as we cannot upgrade the container to a newer version of the OS. So we’ve rebuilt it five times to day before discovering that unless the locale is US whatever, MIAB will not install. It won’t install with en_GB, we know that!

Anyway, we’re testing out the whole install and copying of backup files a few times to make sure it works and it works easily with zero hassles. We have a couple of questions that we hope somebody can help with around how we name and manage the DNS/hostname/certficates during the move. This may become obvious as we test, but we want to make sure we do it right first time on the night.

  1. We’ve created a second server with Ubuntu 18.04 on it. We’ve changed the locale to en_US or whatever and we have an install. We’ve called the server box2.<host_domain>. Our original box was called box.<host_domain>. We’re expecting to have to change the hostname from box2.<host_domain> to box.<host_domain> as one of the last things we do on the night. We know how to change the hostname, but we’re worried about what the chnage of hostname will have on MIAB and LetsEncrypt. Our assumption is that we will have to redo the LetsEncrypt work to get new certs on the night and so we need to make ssure we haven’t run out of capacity to do this.

    Whats the impact on MIAB on changing the hostname please?

    Do we simply run the LetEncrypt certficiate generation again?

  2. We will get the ISP to change the IP address over from the old server to the new server on the night. Do we have to regenerate anything on MIAB? Run the setup again?

  3. All the DKIM stuff on DNS is working, Do we have to regenerate that again, or can we live it as-is as the IP address and hostname will be the same (eventually)?

We’re OK with most of the other stuff but any help and advice on this most welcome. It does help to find the secret backup key as well :slight_smile:

All the best

Rob

2

Hi Rob,

This was already adressed in the development version a few weeks ago. Sorry, that you experienced that bug just before we are releasing a fix for this soon.

Could you give some more information about this? So your current box.<domain> is your nameserver, right?I don’t think you can just change the hostname and MIAB will be fine about it. The reason is that your hostname was inserted in various configuration files (e.g. look where primary hostname is used in the configuration: Repository search results · GitHub). If you only change the hostname without changing the underlying configuration files, I don’t think this would work out.

This is great and sounds good :slight_smile:

Generally speaking: I would follow the tutorial on how to move to a new box. The tutorial states that

When you are prompted for the box’s hostname, you will need to use the hostname that you are currently using.

So this is definitely the way I would go instead of changing the hostname afterwards.

3

@hija Rerunning sudo mailinabox takes care of this issue.

But I do agree in that I would just use the same hostname.

4

Hi @rwillett

So you have already done this in a test environment with no issues??? i just want to confirm this as to date everyone I have helped has had issues with NextCloud. Again, you HAVE spun up another instance of MiaB and restored the backup to it with NO issues???

5

Thanks for the replies to date.

The current status is that we now know how to build the current version of MIAB on a Ubuntu 18.04 server. The issue over locale is a small annoyance but now we know thats ok. We have timed copying over the backup files from one system to another. We have NOT unpacked the backup files yet.

I cannot recall an issue with installing NextCloud from the installation.

Our approach will be that we have a long time to do this, a few weeks or more and we have no issue paying for two boxes. We will keep rehearsing it until we are 100% certain of what needs to be do. We will also document this fully and try to explain what we have done for other people. This will be posted here as MIAB has been helpful to us so it only seems fair :slight_smile:

@hija

We didn’t think of searching githib <doh> for PRIMARY_HOSTNAME. We suspected that this was the case though, hence thats why we raised it.

The issue for us is that we know we can create a second and new MIAB box with the same hostname, but the external DNS name for the new MIAB box will point to the old box with the same name. So when LetsEncrypt starts its work, it will resolve to the wrong place. The implication from https://mailinabox.email/maintenance.html#moving-boxes is that you:

  1. Stop the old mailbox from receiving mail,
  2. Do a backup,
  3. Build a new server ready for MIAB on Ubuntu 18.04
  4. Change the IP address over to the new MIAB server
  5. Build the new mailbox with the new MIAB software and the old MIAB hostname and the old IP address.
  6. Let it finish installing
  7. Copy the backups over the old box (technically you could do this at the start). Don’t forget the secret key :slight_smile:
  8. Reload the backups. I am assuming as we haven’t done it, that this restores the data and the configuration for mail and web and NextCloud. No interested in NextCloud as we run that on a FreeNAS server.

My working assumption is that since the IP address and hostname is the same, none of the DNS configuration actually needs changing as ‘all’ we have done is lift and shift the server underneath the application. I know its a lot more than that, but conceptually that is the case.

if this is the logic, the key things is that we stop the old MIAB working and we have downtime whilst we are doing all the rest of the work and if it goes wrong, we have to change the IP address back andwork out where some of the transitent mail is. I’d like to be able to rehearse this a few times so it’s slick and easy.

My preference would be to stand a new server up AND have the old server stood up until the work is almost done. I don’t think that’s possible and that you have to take down the old server quite early in the process

@alento

I can see that rerunning sudo mailinabox might well help here regarding the hostname, but it’s still not clear to me when the first MIAB has to go down. I will have to check again on the initial build of the new MIAB to confirm if there are any issues with NextCloud. Also I can’t confirm as we haven’t don it, whether the backups restore correctly with zero issues.

Thoughts and views welcomed.

Thanks for the advice to date.

Rob

6

Hey Rob,

just asking a (probably) very stupid question: Why don’t you stop MIAB, do a backup and then you migrate to a new box as written in the tutorial? This way you don’t have the problem with two MIAB running in parallel and I feel like this could save you some hussle. During your downtime you are obviously not able to receive any mail, but…

  1. If you do it in the night (wherever you are), chances are you are receiving less mail than during the day and this won’t be too much of a deal
  2. Today all mail servers (should) try to resend a mail in some intervals if the message could not be delivered.

Other than that I don’t feel competent enough to help you out on this one :frowning:

7

@hija

I want to make sure that the mail migration will work and that things don’t wrong. To make sure of this I want to rehearse it as much as possible, to test that the backups work and to go through everything a couple of times. At the moment, I’m hoping and assuming things will work and sometimes things don’t go to plan, thats why we plan, check and check again. Done too many server moves where things have gone wrong and I end up pulling an all nighter (and more) stint to correct things.

The big issue is that I have to get the IP addresses moved over at the right time, so this means I can’t do it at some stupid hour in the morning as it’s a manual process at the provider. They’re more or less in the same time zone as myself, so I can’t even get the advantage of somebody being 8 hours behind or in front.

Without the right IP address, I cann’t get the certificates done (unless the backup restores the certficates), I also need to change the hostname over at the same time.

It does all seem to depend on stopping the old server mail input, setting up the right hostname, moving the IP address to the new server, putting a new IP address on the old server, doing a backup, copying the backup, starting the MIAB install, restoring the backup and then opening the front door again. If it all goes well, 90 mins? if it all goes wrong, could be a big effort to get the IP addresses put back in place.

Rob

8

This is scary. All of the issues with migration from 14.04 to 18.04 happen during restoration of the backup. Repeat you MUST absolutely do a test run including restoring the backup!

You have not proceeded into the backup restoration process, so you do not yet know. The problem is not in installation, it is when you restore the backup.

9

Random notes in no particular order @rwillett

Just a few things to mention from comments you and others have made…

Have you found the thread that documents how this is done here already? Please read this thread:

IIRC you need to update MiaB to version 0.30 before you can proceed. You said that you are on v 0.28 now. I sincerely hope that you updated Ubuntu 14.04 to the latest before it went EoL.

I strongly recommend setting up a Backup MX server to catch your email as this downtime is not solely dependent on how long it takes you, but how long until the IP address is moved.
There is not really any one good tutorial available, but this covers part of the process:

A couple of questions for you to answer please … as they will give me some insight to the total extent of your situation and may lead to me recommending a completely different means of doing this.

  1. Is your MiaB handling DNS for your domain(s). Any of them? All of them?
  2. How many users/domains are we talking about? If just a few actual users, there may be a simpler way.
10

@alento

Thanks for the comments.

We canot upgrade from V0.28 on Ubuntu 14.04 as we have tried. We are aware of this problem but the documents on moving to Ubuntu 18.04 (Mail-in-a-Box version v0.40 and moving to Ubuntu 18.04) explicitly state that this should not be a problem unles you are using Nextcloud, which we aren’t. It would be nice if MIAB had an option to not install it but we are where we are.

Not sure why not doing the backup restore test is scary. We know we have to do it, we just haven’t done it yet. We will be doing the restoration to test the system, I have no doubt we’ll do it a number of times.

We weren’t aware that the restoration is the issue for nextcloud. This is why we test.

I hadn’t seen the document [Solved] Workaround for upgrading over multiple Versions of MiaB to the latest when multiple major Versions of Nexcloud are included (first accured in upgrade from v0.30/v0.40 (NC13) to v0.42b (NC15) with v0.41 (NC14) between ) ! UPDATED! cose of backup. We will read it and learn.

We will look at setting a backup MX server. We will probably do that on premises rather than with our provider.

MIAB is not handling any DNS at all. We use easyDNS in Canada. It’s all managed from them.

We have five domains and 20-30 users per domain. Its not big, but its not small.

The move from one server to another may be really quick, but we want to make sure its really quick by doing it a number of times and testing it so we find the issues in office time, rather than at 03:00 in the morning after nine hours of problems :slight_smile:

Thanks

rob

1 Like