zengun

I just updated the post about my data’s transatlantic move from San Diego to Paris, to detail troubles I’ve run into while migrating from Apache to lighttpd in the meanwhile.

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!