Opening Site On IP

Hello,

I am doing some testing and I wanted to check the site out on the IP address before I point the DNS to the IP. I edited the conf.d file in /opt/easyengine/sites/domain.com/config/nginx/conf.d and replaced server_name from the domain to the ip in the server block.

I restarted nginx using ee site restart domain.com --nginx.

When visiting the ip I still get the nginx error page.

In EE4 is there somewhere else I need to edit?

Thank you

Undo the changes you made, and just edit your local hosts file on your machine to point the domain you’re testing to the IP of the server that you’re running EE on.

The reply I just posted here is a bit more info than you need but in your case all you need to do is edit your hosts file / clear your dns cache on your computer & browser then head to whatever domain you’re testing. This way you don’t need to point the actual A records on the domain anywhere, they can remain as-is until you finish testing.

@msarhan,

Thank you for the information, I highly appreciate it.

That is a great ideas for tests to check if everything is working once you complete the server and site setup.

What about if you need to access easy engine admin tools to update the database via phpmyadmin?

I know I can update the database via MySQL through the command line and usually do this but I would like to find a better way because enabling admin tools gives you access to phpmyadmin anyway. I figured a quick way would be to simply show the site on the ip, make the quick imports and changes, test, direct DNS.

Thank you

Hmm interesting question. I never use pma so I don’t know the answer to this but doesn’t ee install all the admin tools on a specific port and directory? I don’t see why it wouldn’t naturally work. Hang on I will try it now on one of my servers.

Awesome, thank you.

Another thing to think about: If the original server forces all traffic through https but you are unable to setup LetsEncrypt SSL on the new droplet until DNS is updated. I guess you could use wildcard in this scenario to bypass it through the txt record?

Yep. This is exactly what I do. You can have wildcard certs installed on both your live and dev server at the same time, that’s what I do since it’s totally independent from the A records (just use the --ssl=le --wildcard flag when creating your sites on both dev and live servers. The TXT validation records remains the same, so you only need to set those records once for the domain, and you’ll be able to deploy the certs across multiple servers – within LE’s weekly rate limit anyway). After you’ve set the TXT records just run ee site ssl mydomain.com on both servers and that’s pretty much it.

I enabled admin tools on one of my domains that I’m using a custom DNS record in my hosts file; everything works fine. Simply browsed to mydomain.com/ee-admin and all the tools work fine including pma.

PMA%20Custom%20DNS

EE%20Admin%20Tools

@msarhan

Very nice! I was able to get that completed. It will make testing and migrations a bit easier.

Thank you

1 Like

Speaking of migrations, if you’re using all the same flags for your sites on both servers then I’d recommend the UpdraftPlus plugin, it’s free and in this case migrations would only take a few seconds to complete. Create seperate folders on your computer to store backups from dev and live so they don’t get mixed. And be sure to double check the IP of the server your browser is accessing before you backup & restore. Not often, but sometimes I find that even after I comment out the lines in my hosts file and clearing my DNS cache on my OS (to be able to access the live server) my browser doesn’t take the hint and I need to clear the browser cache and restart the browser. This mostly happens in Firefox. Chrome is easier to deal with in this sense, I just head to chrome://net-internals/#dns and clear the browsers internal cache from there.

You can double check which server you’re accessing by opening the Inspector in your browser and in the Network tab, click on the header request for the site and read the IP address it’s giving you.

Edit: To make migrations absolutely seamless, you can use flags to make the WP admin username, email and password the same for your sites across both servers, that way you don’t need to have two seperate logins (or maybe you want to have two seperate logins, completely up to you I’m just pointing out the option). You can also use flags to make the database host, username and password for your sites the same across both servers, that way again when you access pma on either one, it’s all the same credentials. But again that’s up to you, I am not sure if that is a negative thing security wise, it does make things a lot more convenient and efficient though. I employ this method but I have my servers set to disallow root logins and only login via private keys, with a seperate key (and seperate password to the key) for each server, so with those factors in mind, and also considering that the ee-admin password is different across both servers, in my own case I don’t see a problem using the same credentials.

1 Like