zengun

If you can read this, then you’re reading a page served by a lighttpd instance in Paris.
More on the migration later…

Update : the whole thing. Hopefully this serves as a guide of sorts to whoever runs through the troubles I’ve faced.

Part I : fetching files

Using rsync over ssh, it was a no-brainer.
I just made sure that I had the same /home/$username on both hosts, in order to avoid editing some web apps’ config files to correct absolute paths.

Part II : setting up lighttpd

It was only after I was done that I noticed the lighttpd wiki has a cheat sheet to help you migrate from Apache.

Since I serve multiple sites, I went for a vhost setup using conditionnals, and then set each site’s accesslog, errorlog, and so on (so that my hostees could see their own access logs).

Mod_rewrite rules were another problem. You basically have to understand the rewrite rules that your apps generate (I can only hope you understand those you manually typed in), in order to simplify them and put them in the right order in lighttpd’s config file.
Also, since I didn’t care to remove .htaccess and .htpasswd files, I denied their access. They’re still useful for when an app (think WordPress or another CMS) wants to regenerate rules.

Part III : setting up PHP

Easy as pie with fastcgi in lighttpd. I took the occasion to harden its settings, and add stuff.
Each vhost runs PHP as suexec.

Part IV : struggling with tildas, aka using real utf-8 with MySQL

Here comes the part that took me ages to figure out. I made a dump of my databases, then when I loaded the dump on the new host I had double-encoded utf8. Both hosts are running MySQL 4.1, so I was rightly puzzled.
Turns out that, to have a future-proof MySQL setup I let it use utf-8 by default, while on most webhosts (including TextDrive) the default encoding is iso-8859-1, which leads to what I would call “fake utf-8″ content.
There were multiple solutions to this problem: I could set MySQL’s encoding to iso-8859-1 (no!), I could set the database with the problem to use iso-8859-1 (no!), or I could tell whichever app depended on “fake utf-8″ in utf-8 tables to use iso-8859-1 for its communication with MySQL.
This can be done with the SQL command SET NAMES 'latin1' at the beginning of the app’s execution.

In my case, WordPress was the app that used fake utf-8, so in order not to modify the code everytime I would upgrade WP, I made a simple plugin (latin1-fix.php), activated it, and voilà!, my text was readable again!

Part V : sleeping

Thank $DEITY there was no part V!

When there’s more than one way to do it, for the love of Pete, don’t use the worst way to compress your CSS files (using PHP).

Using PHP’s ob_gzhandler will indeed compress your stylesheet.
But let’s look at the costs first:

• CPU cost: PHP will have to parse a file where it only needs to execute one or two functions.
• Browser/proxy cache cost: PHP won’t send the right HTTP headers by default, so the file will never get cached right. Traffic costs will actually rise unless your visitors only visit one or two pages on your website.
• Valuable time cost: do you really want to add these lines of PHP to each and every CSS file you serve?

Horrific, isn’t it?
Instead, here’s a solution that only takes one line in your .htaccess, and mod_gzip:

mod_gzip_item_include	file	\.css$

There, instant compression on all your .css files.
This may sound like the obvious solution, but still too many are using PHP for this task because they didn’t know better, so I felt I had to blog it…