0

I have a website up and running on a VPS instance from Vultr running Ubuntu 18.04LTS, everything is fine. I wanted to try out a snapshot of the instance in a restore session just in case something bad happened to the system. So I created a new instance and deployed that snapshot as expected, but I couldn't view my website and got error establishing a database connection after changing the DNS to the new IP address. So the restore session failed in this case and didn't achieve its goal. I contacted the support team but they only pointed out that I must correct some network configuration on the new instance after the snapshot restore, but no specific instructions as to how to do that on Ubuntu 18.04LTS. I consulted their documentation, but it didn't mention something about the new network setup of netplan replacing ifupdown in Ubuntu 180.04LTS servers.

enter image description here

Let me go point-to-point in the documentation, I noticed the following:

  • on my new instance the /etc/udev/rules.d/70-persistent-net.rules file is empty, nothing in there.
  • when I reviewed the contents of /etc/network/interfaces there was no IP addresses inside, instead I have this commented out message.

# ifupdown has been replaced by netplan(5) on this system. See # /etc/netplan for current configuration. # To re-enable ifupdown on this system, you can run: # sudo apt install ifupdown

So I reviewed /etc/netplan setup and there I have two files:

01-netcfg.yaml, and it is empty.

The other one 10-ens3.yaml file has this setup inside:

network:
version:2
renderer: networkd
ethernets:
ens3:
dhcp4: yes

So given that, I am totally lost with this setup. I feel it is irrelevant to the new netplan system. So I would be very grateful if you could help me with the right networking configuration in this case scenario to have my live website restored.

doctorate
  • 101
  • 4
  • You got an error from WordPress. Why are you messing with the network configuration? If you were able to see WordPress at all, then the network configuration is fine. – Michael Hampton Sep 05 '18 at 21:40
  • @MichaelHampton am glad to hear that from you, but one concern though, their outdated documentation emphasized that post-restore network correction. Moreover, their team support two days ago told me again I need to make that correction after restoration. Sure, I must believe what I get, if debugging WordPress would solve it, I have no idea where do I need to start that debugging, probably MySQL remote access, must be handed over to the new IP address, otherwise "everything" should be just a replica of that old instance. Any help would appreciated. – doctorate Sep 06 '18 at 14:10

1 Answers1

0

The hint kindly provided by @MichaelHampton prompted the debugging action on the WordPress side of the setup. Yes, my duplicated site is now up and running once again and ready to be in public after changing DNS. However, I am not going to do it now, because I was just examining this method to have it handy in case something bad happened to my system. By the way, this opened roads for me as how to develop my website(s) on a different VPS server. Yes, one might think the downside of it you have to pay for that server, but that's fine, this will push me to do the development as fast as I can afford paying the new server (relatively cheap per hour payments). Another advantage, I can have others visit the development site and have their opinion before going to production site.
All I have to do is telling them the new IP address and the domain name, of course, they will then edit their /etc/hosts accordingly on their machine in this manner: [new-ip-address-no-brackets-pls] example.com www.example.com they may clear browsing data on their browsers and then view that development site deployed from a snapshot of the current live site, while all other universe views the same site in its original state, what a wonderful setup for website development!

Definitely this would be my go-to method for development. I don't know any other method that can easily beat this one, glad if someone would like to share some.

Solution

simply put 'change the IP addresses' wherever found to the newly given one on the new instance: - wp-config.php

  • /etc/mysql/my.cnf two locations host and bind-address

  • /etc/ee/ee.conf but that might be not needed

  • now the tricky part is to do MySQL editing, I am using MariaDB. First of all you wouldn't be able to login as before to your mysql even after all of the replacements done above, I wouldn't be given the permission to login to mysql on this new server no matter what (no idea why). So a workaround would be to logging as localhost which was scenario-saving:mysql -u root -h localhost -p

Then you must be logged in: once there you can do the database replacement of all your users@old-ip-address to user@new-ip-address for example:

mysql> RENAME USER root@[old-ip-add-without-square-brackets] TO root@[new-ip-address-again-without-square-brackets];

Make sure to replace the IP address for all your users and finally do:

mysql> FLUSH PRIVILEGES; and then I could view my newly restored instance with all of its sites. If you have more than one site, it is obvious you have to change IP address inside the respective wp-config.php files, all other replacements under /etc/ are central on the server no site-specific.

doctorate
  • 101
  • 4