There is a nasty Apache exploit going around right now that exploits a vulnerability in versions 1.3.x, 2.0.x and 2.2.x. Basically, it allows the process to exhaust all available memory and crash by sending GET requests with overlapping byte ranges. The methodology seems to borrow a page from the teardrop attack. Yes, I’ve been studying for a security certification….
When upgrading this site, I replaced the underlying hardware as well. The old server was just a dead end in too many regards to be worth upgrading in place, and besides, being able to run new and old side by side for a time is helpful.
This type of maneuver is routine work for a professional sysadmin. But it’s been at least two years since I’ve done a similar maneuver at all, and at least five years since I did it with Linux.
When I built the new machine, I gave it a unique IP address. Turnkey Linux makes getting an operational LAMP stack trivial, and depending on what you want to run on that stack, you may even be able to get that installed for you too.
Unfortunately for me, the Geeklog migration tool doesn’t seem to work with WordPress 3.0.1. So I had to get WordPress running on my old hardware in order to migrate. I chose WordPress 2.0.11 because the 2.0 branch appeared to be the current branch when Justdave wrote his migration tool, and 2.0.11 ran without complaint on the dated versions of PHP and MySQL that were on my old server.
After importing the content, I used mysqldump to export my databases. Specifically:
mysqldump --opt -u [mysql username] -p [database name, probably wordpress] > wordpress.sql
I should have gzipped the file, but I didn’t.
I then connected to the old server via FTP and transferred the file. Use your favorite file transfer method; I happened to have FTP set up for my internal network.
Uncompress the file if you compressed it:
Then restore the file:
mysql -u [mysql username] -p [database name] < wordpress.sql
Or, if the database already exists, like in my case:
mysqlimport -u [uname] -p [database name] wordpress.sql
Then I connected to the webserver via my web browser. WordPress 3.0.1 saw the WordPress 2.0.11 database and informed me that it needed to be upgraded. So I let it do its thing, and a few minutes later, I had a functioning WordPress site with 10 years’ worth of legacy entries.
I messed around with it for a while. Finally, I decided to go live. And at this point, I should have physically moved the new server into its permanent home. I didn’t do that, so now when I decide to move the server, I’m going to have some downtime.
To flip the IP addresses, you need to know where your Linux box stores its IP address. Debian and Ubuntu both store it in /etc/network/interfaces. As far as I can tell, Red Hat and derivatives like CentOS store it in /etc/sysconfig/network-scripts/ifcfg-eth0, but I haven’t used Red Hat or a derivative in a long time, perhaps 2003.
If worse comes to worse, try something like this to determine where it’s stored:
grep -r [ip address] /etc/
I edited the appropriate file on both boxes, changing the IP address while leaving all of the other parameters unchanged.
I then issued the command ifdown eth0 on both machines.
On my new production server, I then issued the command ifup eth0. Depending on the Linux distribution, it might also be necessary to re-issue a default route command. I didn’t have to do that.
Depending on how much Linux/Unix cred you have at stake, you could just do it the Windows way and reboot the box. Or both of them.
Once I was satisfied everything was working, I powered down the old server and celebrated.
I’ve watched my search engine traffic decrease steadily for the past few months since I changed blogging software. It seems most engines don’t care much for the super-long arguments this software passes in its URLs.
The solution is mod_rewrite, and I think my syntax looks correct, but it’s not working for me.The goal is to fake out search engines to make them think they’re looking at static files. Search engines are reluctant to index database-driven sites for fear of overloading the site. Since I can’t tell them not to worry about it, I have to make the site look like a static site.
To that end, I created a section at the end of my httpd.conf file:
# rewrites for GL RewriteEngine on RewriteRule ^/article/([0-9]+)$ /article.php?id=$1 [NC,L]
This line should make the software respond to Thursday’s entry (https://dfarq.homeip.net/article.php?story=20040902200759738) if it’s addressed as https://dfarq.homeip.net/article/20040902200759738.
Once mod_rewrite is working, in theory I can modify the software to generate its links using that format and watch the search engines take more of a liking to me again. But I’ve got to get mod_rewrite going first, and I’m stumped.
Any expert advice out there?
Thanks in advance.
Linux + Apache + MySQL + PHP (LAMP) provides an outstanding foundation for building a web server, for, essentially, the value of your time. And the advantages over static pages are fairly obvious: Just look at this web site. Users can log in and post comments without me doing anything, and content on any page can change programmatically. In my site’s case, links to my most popular pages appear on the front page, and as their popularity changes, the links change.
The downside? Remember the days when people bragged about how their 66 MHz 486 was a perfectly good web server? Kiss those goodbye. For that matter, your old Pentium-120 or even your Pentium II-450 may not be good enough either. Unless you know these secrets…
First, the simple stuff. I talked about a year and a half ago about programs that optimize HTML by removing some extraneous tags and even give you a leg up on translating to cascading style sheets (CSS). That’s a starting point.
Graphics are another problem. People want lots of them, and digital cameras tend to add some extraneous bloat to them. Edit them in Photoshop or another popular image editor–which you undoubtedly will–and you’ll likely add another layer of bloat to them. I talked about Optimizing web graphics back in May 2002.
But what can you do on the server itself?
First, regardless of what you’re using, you should be running mod_gzip in order to compress your web server’s output. It works with virtually all modern web browsers, and those browsers that don’t work with it negotiate with the server to get non-compressed output. My 45K front page becomes 6K when compressed, which is better than a seven-fold increase. Suddenly my 128-meg uplink becomes more than half of a T1.
I’ve read several places that it takes less CPU time to compress content and send it than it does to send uncompressed content. On my P2-450, that seems to definitely be the case.
Unfortunately, mod_gzip is one of the most poorly documented Unix programs I’ve ever seen. I complained about this nearly three years ago, and the situation seems little improved.
A simple apt-get install libapache-mod-gzip in Debian doesn’t do the trick. You have to search /etc/apache/httpd.conf for the line that begins LoadModule gzip_module and uncomment it, then you have to add a few more lines. The lines to enable mod_gzip on TurboLinux didn’t save me this time–for one thing, it didn’t handle PHP output. For another, it didn’t seem to do anything at all on my Debian box.
Charlie Sebold to the rescue. He provided the following lines that worked for him on his Debian box, and they also worked for me:
# mod_gzip settings
mod_gzip_item_include handler proxy-server
mod_gzip_item_include handler cgi-script
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/postscript$
mod_gzip_item_include mime ^application/ms.*$
mod_gzip_item_include mime ^application/vnd.*$
mod_gzip_item_exclude mime ^image/.*$
mod_gzip_item_include mime httpd/unix-directory
mod_gzip_item_include file .htm$
mod_gzip_item_include file .html$
mod_gzip_item_include file .php$
mod_gzip_item_include file .phtml$
mod_gzip_item_exclude file .css$
Most of the examples I found online didn’t work for me. Charlie said he had to fiddle a long time to come up with those. They may or may not work for you. I hope they do. Of course, there may be room for tweaking, depending on the nature of your site, but if they work, they’re a good starting point.
Second, you can use a PHP accelerator. PHP is an interpreted language, which means that every time you run a PHP script, your server first has to translate the source code into machine language and run it. This can take longer than the output itself takes. PHP accelerators serve as a just-in-time compiler, which compiles the script and holds a copy in memory, so the next time someone accesses the page, the pre-compiled script runs. The result can sometimes be a tenfold increase in speed.
There are lots of them out there, but I settled on Ion Cube PHP Accelerator (phpa) because installation is a matter of downloading the appropriate pre-compiled binary, dumping it somewhere (I chose /usr/local/lib but you can put it anywhere you want), and adding a line to php.ini (in /etc/php4/apache on my Debian box):
Restart Apache, and suddenly PHP scripts execute up to 10 times faster.
PHPA isn’t open source and it isn’t Free Software. Turck MMCache is, so if you prefer GPL, you can use it.
With mod_gzip and phpa in place and working, my web server’s CPU usage rarely goes above 25 percent. Without them, three simultaneous requests from the outside world could saturate my CPU.
With them, my site still isn’t quite as fast as it was in 2000 when it was just serving up static HTML, but it’s awfully close. And it’s doing a lot more work.