zengun

weblog

20051010

transatlantic move

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!


6 responses

  1. One two one two.
    Is this thing on?

    #1 michel v — 2005/10/10 at 0:30

  2. One two one two. Again.

    #2 michel v — 2005/10/10 at 0:37

  3. Copy that.

    #3 kwyxz2005/10/10 at 0:56

  4. Lapin ?

    #4 XiBe — 2005/10/10 at 13:54

  5. prout

    #5 neuro2005/10/13 at 13:44

  6. Hallo, Michel!

    I have installed ‘Boxy But Gold’ and you are there, in its blogroll. Thanks for your contribution and happy birthday!

    http://tron.blogdns.org/wordpress/

    Saludos from EU-Spain-Canary Islands

    #6 Tron — 2005/10/16 at 22:24

Your words


Required fields:
Are marked by this sign: *
XHTML:
You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
On comment spam/irrelevance:
Your comment may be moderated or considered as spam by the leprechauns running this server. If you get a 412 error or a mean message, it may be that they thought it was spam: try wording the comment differently or remind me to put up a contact form so you can warn me about the problem.
Of course, once the leprechauns are done doing their magic, I reserve the right to delete any comment for any reason.