Transferring to a new server

Hi,
I am attempting to move my Mailinabox server from Vultr to Linode. I have followed the process listed on the site. I have created a new box on the new VPS. I have restored the latest backup to the new box, but I have not been able to get the reverse DNS set up on Linode. It talks about A records - in fact every article from Namecheap to Linode talk about A records. I had a moment of clarity and realised that the A record I’m looking for is in my box dns settings.

First, how do I change the A records when the settings are set for the old server? I can’t log into the new box location as it sends me back to the old box admin panel. Do I have to change these inside

Second, I noticed that during the box installation it is failing the Owncloud install with an error message about not being able to access the config.php file? It doesn’t give this error message on the old box when I reinstall. All the permissions look correct.

Third,I noticed that in the instructions it says to restart the server once the backup has been installed. This just ends up with the Nginx server failing to start because the SSL cert isn’t correct.

If anybody has any clues or answers to how I work around these issues that would be appreciated.

In short, the process doesn’t seem to be as potentially seamless as the instructions make it out to be and I’m wondering if anybody can give me some clues on the best way to achieve a successful outcome.

Thanks heaps in advance.

rDNS is probably the last thing to worry about. It doesn’t impact the function of the server, just the deliverability to other servers.

Did you update the IP address for your glue records (e.g., ‘personal name server’) and your domain’s name server record (‘NAMESERVER’)?

Can you log into the interface at https://<ip address>/admin?

I haven’t updated the glue records yet. I wanted to ensure everything on the box was running right before completing that part.

I tried changing those settings at the registrar and MX Toolbox showed they had changed, but I hadn’t changed any of the DNS setting on the box so I think that’s why the rDNS settings were failing. I changed them back so I still had an operational mail server while I figured out what my next steps were.

I can’t actually login using the IP address. It just sends me to the old box admin interface.
So, I’m thinking I’ll just restart the process again clear the instance and give it another go from scratch.
The old instance is still operational so I can easily make another backup and move it across.
Is the OwnCloud permissions issue going to give me problems further along?
Given that the backup restore is putting all the old box DNS settings in there do I have to go in and change these manually as well? I’m guessing that I will have to do that.

This doesn’t make any sense. Even on a properly working MiaB installation, it does not forward from the IP address to anywhere. It just loads the admin dashboard with certificate warnings.

It is better to worry about rDNS after everything else is working. It really doesn’t have anything to do with the function of the server. If you never configured it, the worst that would happen is some mail servers always send to spam and the dashboard gives you a warning on the status checks page.

Yes, I know. Last night I logged straight in. Today, I had the flash of insight about the A records and it sent me to the old server. Maybe, that’s my browser cache. I’ll try another browser.

As a curious question. Will I need to recreate the SSL certificates on the new instance or will it all be happy with what comes off the backup?

If you have not configured your name server records for the new install location, then the old records will just be whatever they have been.

The dashboard will inform you if you need to reprovision any certificates.

OK. Thanks. I tried a different browser and I’m into the control panel. (happy)

I’ll keep digging in and get this thing to work.

Do you know what the issue would be with the OwnCloud install? I checked the user privileges and it looks exactly the same on both boxes, but during the install on the new box it gave me an error about not having permission to alter config.php.

Does the box automatically set the DNS addresses for it’s current install location? eg the A record for the box domain even though the backup will be from a different location?

Unfortunately, this is one of the few things MiaB uses I have no experience with.

I can only recommend generic troubleshooting, such as complete the restoration and see if that fixes it; search the forums and the project GitHub for the same problem.

If you follow the restoration procedure, this should all be set for you, given that these configuration settings are the reason that MiaB takes over the DNS server duties. However, I have note performed a full restoration, so I can’t speak from experience.

Thanks.
I appreciate your time and your replies.
It is greatly appreciated.
I’m almost ready to flip the switch and I’ll update once I’ve got to the other side.

Note that Namecheap places a TTL of 86400 on ns records, and MiaB now places the same on all MiaB records (as of .53), so be prepared for unavailability of your system for up to 48 hours.

That’s the bit I’m scared about. When I changed my glue records last night they showed up in MX Toolbox almost immediately. I have a secondary nameserver (Puck). So, all I’m changing is the address for one nameserver. Hopefully that will get me through. I have 4 websites relying on the DNS from the box.

You likely should also disable DNSSEC in the Namecheap dashboard until everything is working properly.

It disabled itself when I changed the records yesterday. I haven’t worried about changing it back until I get this sorted.

It looks like even maybe some of the devs prefer something other than 86400 TTL:

You may be able to figure out how to manually change the MiaB TTL from somewhere in the PR.

If most of the dns settings don’t have to change except for whatever one is providing the box location will this matter to me during this process? or does this mean that the dns server itself will be unavailable for that period of time?

If you change to the new server and it isn’t working, then you won’t be able to change to something different and see the change for the TTL of 86400.

Keep in mind, if requestors of a record don’t perform a lookup during the period before you switch back, they won’t know the difference.

I just read that link you posted. I think NameCheap was the first place where I encountered the inability to shorten my TTL times in their DNS. But, for what I’m needing to do I think the glue records change will be pretty quick. The new server IP address showed up on MX ToolBox after a few minutes yesterday and my experience with Puck appears that it updates almost immediately. All my other DNS nameserver entries for the other domains don’t need changing as they’re referencing the same servers, just in a different location.