Passage de Celeonet à DreamHost

dimanche 16 octobre 2005 par Sébastien (lien permanent)

Au cas où vous ne le saviez pas (et ce serait normal), jusqu’à ce week-end ce site était hébergé par Celeonet. Je finalise en ce moment le passage à un hébergeur d’outre atlantique : DreamHost.

Ce changement n’est pas dû à un quelconque problème avec Celeonet, je n’ai jamais eu à me plaindre de leur service. Seulement l’offre de DreamHost était trop alléchante et j’ai décidé de tenter l’« aventure Â».

Tableau comparatif des offres Celeonet et DreamHost
  Celeonet
Celeoprimo		 DreamHost
Crazy Domain Insane
Version PHP 4.3.10 4.3.10
Version MySQL 4.0.24 4.1.14
Espace disque 100 Mo 4800 Mo
(augmente de 40 Mo par semaine)
Bande passante mensuelle 8 Go 120 Go
(augmente de 1 Go par semaine)
Domaines / sous-domaines 1 / 10 illimité / illimité
Nombre de bases MySql illimité illimité
Comptes e-mail 10 600
Coût annuel 35,74 â‚¬ 119,40 $

La migration a été un peu délicate et m’a permis au passage d’apprendre pas mal de choses sur Apache, PHP et MySQL (et j’ai encore de la marge).

Si vous êtes un jour dans la même situation, voici les problèmes que j’ai rencontrés.

Les identifiants de session PHP

L’option PHP session.use_trans_sid est activée sur DreamHost. Cela avait une conséquence aussi incompréhensible que pénible. Lors de la première connexion au site (et uniquement la première, pour chaque session du navigateur), PHP ajoutait l’identifiant de session aux URLs relatives (et uniquement pour les URL relatives). Ce problème, qui peut paraître cosmétique, est en fait fatal pour un site servi en tant que XHTML. En effet PHP n’écrit pas du HTML valide (encore moins du XHTML) et les sessions PHP qui se greffent sur une query string existante le font avec une esperluette non convertie en entité (& au lieu de &). Pour ceux qui ne le savent pas encore, une entité non convertie en XHTML équivaut à une erreur de formation, ce qui entraîne l’arrêt immédiat du parser : la page ne s’affiche pas du tout.

Il y a plusieurs solutions possibles. J’aurais pu tout simplement supprimer toutes les URL relatives, mais je les trouve bien plus pratiques (j’aime me référer à la racine du site avec un href="/"). De plus un oubli est vite arrivé… L’autre solution consiste à interdire à PHP de réécrire les URL. Cela se fait assez facilement avec :

<?php
ini_set('url_rewriter.tags','');
?>

Notez que de cette façon les cookies doivent être activés pour que les sessions fonctionnent.

Ressources

L’option Apache +MultiViews

DreamHost n’applique pas l’option Apache +MultiViews par défaut, contrairement à Celeonet. J’utilise cette option pour avoir des URL « propres Â», sans extension. Le résultat fut que « http://sebastienguillon.com/contact Â» renvoyait une erreur 404, car il n’y a pas de répertoire « /contact/ Â» sur le serveur. Il y a en revenche une page « /contact.php Â», que +MultiViews devrait trouver.

La solution est simple, ajouter cette ligne dans un fichier .htaccess placé à la racine du serveur :

Options +MultiViews

Ressources

Format timestamp de MySQL

La version 4.1 de MySQL comporte un changement incompatible avec les versions précédentes concernant le format des champs timestamp. Ces champs ont à présent le même format que les champs datetime ('YYYY-MM-DD HH:MM:SS'), soit quelque chose comme 2005-10-15 12:30:00. Heureusement, lors de la récupérations des dump MySQL sur le nouveau serveur, la conversion s’est faite automatiquement (par exemple 20051015123000 est devenu 2005-10-15 12:30:00). Mais j’ai du revoir certaines fonctions PHP et certains scripts pour produire et exploiter ces timestamp nouveau format. Évidemment cela s’est révélé d’autant plus facile que la logique est à présent la même pour un plus grand nombre de formats.

Ressources

Date et heure

Un autre inconvénient avec un serveur situé dans un fuseau horaire différent est que l’heure du serveur ne correspond pas à l’heure locale du webmaster. Il faut donc adapter les fonctions qui gèrent l’affichage de l’heure de publication des billets, entre autres. Je n’ai pas vraiment fait le tour de la question. Pour l’instant j’applique juste une correction avec la fonction mktime() de PHP…

Jeu de caractères pour MySQL

Apparemment, mais ce n’est toujours pas entièrement clair pour moi, même si MySQL utilise utf-8, phpMyAdmin exporte les dump en latin-1. Les fichiers du moins sont clairement codés en latin-1. Pour les ré-importer, il faut donc cocher latin-1 et non utf-8, même si la base de destination est elle aussi en utf-8… Je serais heureux de modifier ces infos si elles étaient incorrectes, car ce point est encore assez confus.

Conclusion

Après avoir suivi les fluctuations de la propagation des DNS (très drôle de voir apparaître puis disparaître le site en fonction du serveur sur lequel les requêtes aboutissent), je pense que tout est à présent en ordre. Mais des surprises peuvent encore arriver. Cet article est le premier publié sur le nouveau serveur.

← article précédent – article suivant →

Les commentaires pour cet article sont fermés.