After our new Qmail server was up and running and all the major issues were ironed out, it was time to clone the email server’s hard drive to a backup drive we can store off site. I decided to do this at around midnight, so that our day-to-day business wouldn’t be disrupted. The biggest challenge was actually finding a workstation that was big enough to house two drives and had enough available SATA power plugs. (I realize, you can also push compacted images up to an FTP server, but I was afraid our FTP server wouldn’t have enough space to accomodate the complete disk image.)
My biggest fear was that I would clone images in the wrong direction. In other words, copy the garbage image from my intended target drive over the top of my intended source drive. But the G4L menu now has an option that allows you to identify which disk is which. So with a fairly high level of confidence, I cloned disk1 (/dev/sda) over the top of disk2 (/dev/sdb). Not sure how long it took–I went home after verifying that the process was running.
So this morning, it was just a matter of quickly inserting the original disk back into our email server and firing it up. Then I tested the cloned image on a separate (but similar) machine. Woo hoo! It works!
I struggled to install a couple of plugins and received the message: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.
Yeah, right. Try again. Try finding an explanation as to what’s causing this or how to deal with it, but no joy. Oh, I found a thread that amounted to an argument between other frustrated WP users as to whether they should start a separate thread about this issue or not–but no solutions appeared on the horizon.
So here’s what I’m going to do: Abandon this Slackware install. I googled the question, “Which is the best distro for WordPress.” The concensus seems to be either Ubuntu or CentOS, with more answers leaning toward CentOS. I’m not a big fan of Ubuntu–seems too much geared for users who don’t need or want to get under the hood. And I’d prefer not having to use sudo all the time.
So for now, I’m downloading CentOS 6.3 and will install it on a different machine.
So far I’ve been able to get WordPress running–up to a point. As long as the updates that I want to submit are saved into the MySQL database, everythings fine. But when I tried to upload a different image to customize this blog site, it started getting ugly. The site returned the message: The uploaded file could not be moved to /wp-content/uploads/2012/08.
I searched for solutions online. One suggested tweaking the upload folder, adding/removing leading / trailing forward slashes. That didn’t work. Others suggested that you have to update permissions to 777. I was hesitant to do so, because that’s just throwing the door wide open for hackers. But after messing around for several hours, I decided to give it a try–thinking that I’d be able to reset permissions afterward. For me, that fixed the issue. Our blog now displays a custom header at the top of the 2011 theme.
I also tried adding a comment to see whether I could. Since this wrote straight to mySQL, it wasn’t a problem. But I noticed that the site didn’t email me a notification–even though it appears to be configured correctly. I suspect the issue is that I didn’t install sendmail on the machine. I’m going to poke around some more to see whether I can use smtp passthrough to route emails back and forth between this new machine and our mail server. I’ll update this blog once I figure that out.
When I first set up this blog site, I hadn’t configured DNS yet, so it was easier at the time (or so I thought), to just use the intended IP address. Little did I realize that this particular IP address was being saved into the underlying MySQL tables! Only later, when the blog server received its final static IP address assignment and I updated DNS accordingly, did I realize how much of a challenge this would prove to be.
Googling for ‘WordPress IP Address change’ resulted in a number of links confirming that yes, this was not going to be a cake walk. The accepted solution on stackoverflow was this:
update wp_options set option_value=’http://www.yourblogname.com’ where option_id = 1;
update wp_options set option_value=’http://www.yourblogname.com’ where option_id = 39;
While that helped, it didn’t totally resolve the issue. Ultimately I ended up doing a mysqldump of the database, opening it up in Notepad++ and substituting blog.iotechno.com for the original IP address. After saving the file to a different name (just in case importing the .sql script might screw up the database structure), I launched mysql and imported the new script. Worked like a charm!
After a fairly steep learning curve, I finally have WordPress up and running on a Slackware 12.37 box. It was actually easier the second time around, after I spent several days trying to install Qmail, then configuring and deploying it on a new machine (also running Slackware 12.37).
I’m sure there would have been an easier way than the one I took–deploying a barebones install of Slackware (deliberately NOT installing Apache, MySql or PHP during the setup), then manually installing the components. But for the life of me, I couldn’t get the three from the base install to peacefully coexist.
But hey, it’s working now!