In an earlier post, I said I hope you have pointed your domain name at your static IP address. Well, what if you don’t want to?
The point being that the DNS entry for the domain name currently points to the production WordPress site, and really, I would like to set up this multisite WordPress installation without having to change the public DNS entry.
Also, setting up this, my personal blog, I was using No-IP DNS services. I could update the DNS entry for gerisch.org, and the DNS replicated out almost instantly. It was great. But the other web site I’m working on (the one that got me into WordPress at all), is using Network Solutions for their DNS. They take their good sweet time replicating DNS entries out to the world. I don’t really want to post an update to DNS, wait, dink around with the new site while the production site is down, decide to revert to production, post an update to DNS, wait again while Network Solutions gets around to pointing everyone back to the production web site.
It would just be better if the new web server machine never got away from it’s own self when doing lookups for the domain name it will eventually be.
So I can start the WordPress install from the IP address of the server out on the public Internet. However, WordPress during it’s install, is going to do a DNS lookup, and try to invoke code on the server where the DNS really does resolve. Which isn’t where I am. So I’m going to try to install a fake DNS server on the new server, and have it redirect all calls to the old domain to the new server.
Step the first: install dnsmasq
sudo apt-get install dnsmasq
Next, set up listening on the local host address:
sudo vim /etc/dnsmasq.conf
Find your way to the line #listen-address= and edit it thus:
listen-address=www.gerisch.org
And save and exit
sudo vim /etc/dhcp/dhclient.conf
Find your way to #prepend domain-name-servers www.gerisch.org; and uncomment this line. Save and exit.
And now it gets weird.
The Bitnami / AWS Lightsail images use something called cloud-init : https://cloudinit.readthedocs.io/en/latest/topics/modules.html
So if you were going to try to edit /etc/hosts or /etc/resolv.conf you get warned to not edit them by hand, because they will be replaced on next boot. But they sure as heck don’t tell you where to implement edits. Just don’t do it here.
Turns out there are template files in /etc/cloud/templates that hold the magic.
cd /etc/cloud/templates sudo cp hosts.debian.tmpl hosts.debian.tmpl.original sudo vim hosts.debian.tmpl
Now I’m going add a line below www.gerisch.org localhost which will be the IP address I want this machine to go to whenever it tries to resolve the domain name of the production web site
And indeed, if I use dig from an ssh session in the machine, dig reports back the local machine’s address, not the one out on the public Internet