This week, I doubled back down in earnest to get my webserver running on the hardware I bought a year ago.
After getting Apache, PHP and MySQL installed on the box and playing together nice, I installed WordPress and got it running. Then I tried backing up and restoring files from my existing server, and the server didn’t like that one bit.
This week, I stumbled across XCloner, which promised to make things simpler, so I put off my other projects and decided to give it a shot.
XCloner is pretty slick. You install it, and it automatically dumps the entire site–files, database, and all–into a package, and offers to transfer it to the new machine, along with a URL to visit. I just copied the three files over to the new machine myself and invoked it by visiting the PHP page. For best results, the machine needs to be running Apache, MySQL and PHP already, and have the WordPress database created but empty.
I learned that the hard way, by trying, and getting some error messages.
So I installed Midnight Commander and used it to clean up my /var/www directory (I have Webtrees running there too, and wanted to leave that alone because it works splendidly). Sure, I could do it with strategic rm commands, but rather than obsess for five minutes over whether I got each rm command right, I thought I’d set my pride aside, use Midnight Commander, and not mess anything up.
Then I fired up MySQL, double- and triple-checked to make sure I was signed in to the right machine, dropped the database and created a new, empty one.
Then I proceeded to install a days-old backup. It seemed to work, but I didn’t want to lose the changes I’ve made in the last week.
So I repeated the process again, this time with a current backup.
It was fast, and looked good. So I tuned it, saw that Apache wanted to use 9.8 gigs of RAM all to itself, shaved that down to something a lot more reasonable, and tried it again. Since it seemed to work, I actually redirected my firewall to point at the new server, then fired up the site with a web browser, and… The front page worked, but none of my links did.
So I hastily changed the firewall back while wondering why I didn’t think to try that *before* changing the firewall.
Nothing I could think of quickly got the server working properly, so I called it a night and did some research in the morning. At work, sleeping on a problem usually isn’t an option, but at home, sometimes it’s the best thing you can do.
I found a few different things to try, but my permalinks still didn’t work. Finally, I found the answer in /etc/apache2/sites-available/default — WordPress needs “AllowOverride” to be set to “All,” and it was set to “None.” Changing it both places in that file got me working. That’s the kind of stuff you forget when you don’t deal with Apache every day anymore.
So now my site is running. It’s a 2-CPU, 3 GHz machine with 8 GB of RAM and a 40 GB SSD. I haven’t seen the CPU load exceed 30% yet.
With some CPU power to spare, and a backup solution in place that I know works well, I’ll bet I’ll get lots of different ideas for things to try.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.