StevenMiles
asked on
Moving perl/apache site to a new server. Need advice on testing the new installation before switching everything over.
I have basic competence, but I'm not an expert.
I'm moving a perl/apache site to a new server. Newer hardware. I need advice on testing the new installation before switching everything over -- before telling DNS that MySite.com directs to the new hardware.
The web site, MySite.com, is run with apache. The entire site's html is generated on-the-fly by perl programs. If I just copy everything from the old server to the new hardware, then during testing, links on pages rendered by the new site will go back to "MySite.com", right back to the old server, thwarting testing. I need all links on the test (new server's) site to go to "123.456.789.123" instead, the new server's IP address, so the new installation can be tested thoroughly.
Did I explain that well enough?
What I can think of is this: just before every "print" statement in all the perl programs, the statements that "print" the html to the client's browser, I search/replace "MySite.com" with "123.456.789.123". Seems that should work, and I think it's doable, but what a pain! And there's probably some work to do in httpd.conf's rewrite section.
Is there a better way to do this? Are there pitfalls I'm not seeing? Certainly this is a situation that must be handled commonly, right?
Thanks for any advice.
I'm moving a perl/apache site to a new server. Newer hardware. I need advice on testing the new installation before switching everything over -- before telling DNS that MySite.com directs to the new hardware.
The web site, MySite.com, is run with apache. The entire site's html is generated on-the-fly by perl programs. If I just copy everything from the old server to the new hardware, then during testing, links on pages rendered by the new site will go back to "MySite.com", right back to the old server, thwarting testing. I need all links on the test (new server's) site to go to "123.456.789.123" instead, the new server's IP address, so the new installation can be tested thoroughly.
Did I explain that well enough?
What I can think of is this: just before every "print" statement in all the perl programs, the statements that "print" the html to the client's browser, I search/replace "MySite.com" with "123.456.789.123". Seems that should work, and I think it's doable, but what a pain! And there's probably some work to do in httpd.conf's rewrite section.
Is there a better way to do this? Are there pitfalls I'm not seeing? Certainly this is a situation that must be handled commonly, right?
Thanks for any advice.
Aside: I work with many... complex custom code sites like the one you describe...
Doing migrations is a massive time drain, unless you use LXD.
I'm generally... very lazy or efficient (depending who you ask)...
So with LXD migration occurs like this...
Notice the entire site code is treated as a black box.
Containers can be move around, cloned, whatever, with no care about what's running inside the container.
https://www.experts-exchange.com/questions/29189398/LXD-containers-infrastructure-on-OVHcloud-setup.html provides details about setting up LXD on a bare machine.
For custom code there's also a tool built exactly for this type of situation, moving a complex machine/host level install of unknown attributes off a physical machine into an LXD container somewhere.
The tool is lxd-p2c, which I've used many times to avoid... understanding custom code... when I take on a new project...
Once installed, here's how to convert a physical machine into an LXD container somewhere...
The trailing "/" says scrape the entire physical machine into the container, so the container OS is overwritten by the physical machine OS.
If you're running an SQL database, be sure to stop the database before running lxd-p2c.
If you end up spending massive amounts of time without getting your new migration working, lxd-p2c has worked in 100% of projects I've migrated.
Doing migrations is a massive time drain, unless you use LXD.
I'm generally... very lazy or efficient (depending who you ask)...
So with LXD migration occurs like this...
# Stop container to bring all data to consistent state
lxc stop my-crazy-perl-container
# Copy LXD container to a new machine (all files, databases, configs, cronjobs, every single bit)
lxc copy my-crazy-perl-container new-machine-name:my-crazy-perl-container
# Now on new-machine-name change new-machine-name/rootfs/etc/netplan/config to new IPNotice the entire site code is treated as a black box.
Containers can be move around, cloned, whatever, with no care about what's running inside the container.
https://www.experts-exchange.com/questions/29189398/LXD-containers-infrastructure-on-OVHcloud-setup.html provides details about setting up LXD on a bare machine.
For custom code there's also a tool built exactly for this type of situation, moving a complex machine/host level install of unknown attributes off a physical machine into an LXD container somewhere.
The tool is lxd-p2c, which I've used many times to avoid... understanding custom code... when I take on a new project...
Once installed, here's how to convert a physical machine into an LXD container somewhere...
lxd-p2c https://$lxd-target-machine:8443 $container-name-to-create /The trailing "/" says scrape the entire physical machine into the container, so the container OS is overwritten by the physical machine OS.
If you're running an SQL database, be sure to stop the database before running lxd-p2c.
If you end up spending massive amounts of time without getting your new migration working, lxd-p2c has worked in 100% of projects I've migrated.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This fix is this.
1) First destroy systemd-resolved as it's never worked... never will work... will make handling this case impossible... then replace systemd-resolved with dnsmasq.
Same for named, remove all bind9 packages.
https://www.experts-exchange.com/questions/29162917/Huge-DNS-queries-from-openshift.html
2) Once you have dnsmasq running, correctly hijacking all DNS lookups, you can just add an override for your domain into your dnsmasq config file.
3) Next in your local /etc/hosts file add an entry pointing your domain (bare domain + www host) to your new IP.
4) At this point any local access of your site will resolve to new IP (your local /etc/hosts entry) along with any self reference the site makes to itself (dnsmasq).