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!

☠ combines Java, PHP/MediaWiki, and AJAX in order to offend as many developers as possible in a single go.

Havoc Pennington, introducing Yarrr

Bad luck is:

1. seeing Firefox suddenly decide to send a form’s content as UTF-8 when it has always sent it as ISO8859-1 (the target database’s encoding),
2. seeing the UTF-8 version of ô is ô when seen as ISO8859-1,
3. finding out MSSQL Server 6.5 chokes on ´ when you try to update the field to remove the offending double byte text,
4. wondering just why the previous text appears in the SQL query at all,
5. realising you have no control over neither the remote SQL Server nor the scripts that process the form (it’s f***ing bytecode in there!).

Suffice to say that I’m tempted to hack the server, provoke a crash or something, and then sell a solution based on free software. It’s just too bloody frustrating to work with antiquated proprietary shit.

You’ve got a blog encoded in UTF8, you’re very happy with it, thanks to it your wife has a shiny coat and your dog makes love to you like never before.
Everything falls apart the day you receive a trackback from a blog encoded in ISO8859-15. Suddenly strange little squares (‘unknown character’) are disfiguring your page, the W3C says your blog is invalid trash, your readers are doubting you.

Just when the thought of blog-suicide rears its ugly head, you remember your blog is powered by WordPress, which has a très geek filters function!
The solution (after a look at the documentation) comes naturally: <?php add_filter('comment_text', 'utf8_encode'); ?>

There, now you can receive trackbacks from anyone without worrying whether they were sent in UTF8 or not!