Ça peut paraître incroyable mais pourtant c'est vrai :
date('Y-m', strtotime('2008-02')) = '2008-03'

Du moins, les 29 (sauf si l'année est bissextile), 30 et 31 de chaque mois. Il semblerait que strtotime remplace l'absence de numéro de jour par la date du jour courant. En ce qui me concerne, je m'attendais plutôt à ce qu'il considère ça comme le jour 0, jour 1 au pire.

La même règle est valable pour les mois à 30 jours parsés un 31...

Déplacer un site entier d'un serveur (ou hébergeur) à un autre n'est pas toujours chose aisée, surtout quand il s'agit d'un site dynamique et actif.

Beaucoup ignorent le fonctionnement de la propagation des zones DNS (et des TTLs ou durées de vie). L'erreur numéro 1 à ne surtout pas commettre est de changer les serveurs DNS, leur pointage et le serveur en même temps. L'erreur est fréquente et conduit au mieux à des sites "parallèles" : deux versions à gérer, et des interactions aléatoires avec les utilisateurs. Au pire : le site disparaît, les mails n'arrivent plus et le monde s'écroule.

J'ai récemment vu plusieurs fois ce genre d'annonce de service :

Bon allez, c’est parti, la copie du blog est en place sur le nouveau serveur et la base remontée, je modifie le DNS et la propagation devra se faire dans les 24, 48h. Demain [le blog] aura donc changé de serveur si tout est Ok. [...]

Les éventuels commentaires postés sur l’ancien serveur pendant la période de migration ne seront pas présent sur le nouveau serveur. Ce post ne sera pas visible non plus sur le nouveau serveur.

(bold ajouté par mes soins)

Même si prévenir ses utilisateurs, lecteurs et clients est une bonne chose, je trouve dommage de s'avouer si vite vaincu par un outil technique inconnu. Et de leur faire subir, également.

Voici quelques exemples de migrations mal planifiées malgré une certaine notoriété des sites et/ou de leur responsable :

• Jeremie Berrebi change son blog de serveur : ... Bon, c'est pas trop grave, seulement quelques commentaires perdus. Le contenu était toujours accessible (en dehors des nouveaux articles bien sûr)
• Eric Dupin déménage Fuzz, domaine, DNS et serveur en même temps. Résultat : plus de 72 heures de downtime... Et autant de frustration pour les utilisateurs de ce service web.
• Mathilde décide de déménager Bagatelles.fr : catastrophe ! Outre l'indisponibilité du site, l'export se passe mal (visiblement un problème d'encodage), mais surtout pendant plusieurs jours, pas de commande ni d'email... Dans le e-commerce, non seulement la perte est quantifiable, mais c'est aussi le sérieux, l'image et la confiance de l'enseigne qui est remise en cause.

Heureusement, tous les déménagements de serveur ne se passent pas aussi mal et tout un chacun (un minimum réceptif à la technique) peut parvenir à déplacer son site sans problème et surtout sans le classique délai inexploitable de 24 à 48 heures... Il suffit de faire les choses dans le bon ordre !

Voilà ma procédure :

On suppose que :

• le domaine est configuré pour recevoir ses emails (MX) sur un serveur tiers (Google Apps, par exemple), le contraire étant pour moi une hérésie.
• on n'a pas de solution type "IP fail-over" permettant de basculer le routage d'une adresse IP instantanément (et annulant la problématique des DNS)

Y a-t-il transfert de domaine ?

OUI : S'il y a transfert du domaine d'un registrar à un autre, il faut prévoir au moins 2 à 4 semaines pour avoir la certitude que le transfert sera fait au bon moment. Pour un .com, c'est plus rapide, pour un .fr, ça peut être plus lent... La procédure varie selon l'extension du domaine et les registrars entrant et sortant, je ne la détaille donc pas plus. Attention toutefois à bien laisser les mêmes serveurs DNS que précédemment, sans quoi le domaine risque d'être "parké"...

NON : Rien à faire pour l'instant.

Y a-t-il changement de serveurs DNS ?

OUI : Il faut s'y prendre au moins une semaine à l'avance. Dans un premier temps, configurer la nouvelle zone à l'identique de l'ancienne. Seuls les champs SOA et NS diffèrent, puisqu'ils doivent contenir l'identité des nouveaux serveurs DNS. Ensuite, lancer la procédure au niveau du registrar. Il peut se passer plusieurs heures (habituellement entre 6 et 48 heures) avant que le changement soit bien pris en compte partout. Toutefois, même pendant la transition, le site est accessible et fonctionnel. Zéro coupure.

Note : S'il y a transfert de domaine ET changement de serveurs DNS, la procédure au niveau du registrar peut n'être effectuée que sur le nouveau registrar au moment du transfert, tant que les nouveaux serveurs DNS sont configurés correctement. D'une pierre deux coups, et toujours aucune coupure malgré une transition un peu longue.

NON : Rien à faire pour l'instant.

Étapes préliminaires

Le nouveau serveur

Il faut bien le faire à un moment, ça peut être fait bien avant les transferts de domaine et DNS, ou pendant, ou après.

Commander, installer, configurer, et tester le nouveau serveur (ou hébergement). Mais surtout, y installer une copie du site : si le site crée/supprime des fichiers (upload d'images/vidéos par exemple), on utilisera de préférence rsync. Si les fichiers sont statiques (comme un blog : aucun fichier n'est créé en dehors des images ajoutées aux billets), une copie pure et dure à coup de scp ou via FTP est également possible. rsync est nettement plus souple (ne copie que ce qui diffère) et rapide (liaison serveur à serveur vs serveur vers client vers serveur), mais ne peut pas toujours être utilisé (il faut un accès SSH et/ou un hébergeur sympa).

Y installer une copie de la base de données. Un réimport de backup à peu près à jour peut faire l'affaire. J'ai une commande magique et extrêmement rapide pour ça, mais c'est secret défense :) Ce qui compte, c'est que la structure SQL soit à jour, peu importe pour les données elles-mêmes.

Pour pouvoir tester correctement le nouveau site sur le nouveau serveur, la meilleure solution à mon goût est de modifier temporairement son fichier hosts (ce fichier permet de passer outre les serveurs DNS pour résoudre un nom en adresse IP) pour tester le site sur le nouveau serveur et ajuster les petis détails si besoin (un module oublié, une permission mal remise, etc.). L'emplacement du fichier dépend du système d'exploitation, mais Google a la réponse.

Cette étape de test permet un passage en production sans aucun problème.

Réduire les TTLs au niveau de la zone DNS

Malgré des acronymes barbares, les TTLs (pour Time To Live) sont de précieux alliés s'ils sont bien utilisés, mais sont aussi la cause de tous les problèmes cités plus haut quand ils ne sont pas compris et maîtrisés. La propagation, ennemie jurée ? Je dirais plutôt amie incomprise...

Une fois les transferts administratifs effectués et effectifs (soit minimum 48h après l'application du changement de serveurs DNS et au moins autant après la notification de fin de changement de registrar), il faut donc réduire les TTLs. La procédure change du tout au tout selon l'entité qui gère les DNS : interface d'administration ou fichier de configuration... Le principe reste le même : il faut que chaque enregistrement dans la zone expire le plus vite possible. Par défaut, la valeur est souvent de 86400 secondes (24 heures). Je recommande une valeur de 5 minutes maximum (300 secondes), 1 minute si possible (60 secondes). Il ne faut surtout pas modifier le pointage des enregistrements pour l'instant.

Cela aura pour effet de rendre les prochains changements rapides, et de réduire la période de propagation à quelques minutes... Et pour l'instant toujours rien de visible par les utilisateurs, lecteurs et clients.

Transfert des données

Quand toutes les étapes précédentes sont terminées et vérifiées, on peut passer au transfert réel des données.

Afin de conserver l'intégrité des données, il convient de passer l'ancien site en lecture seule, sans quoi des évènements aléatoires peuvent se produire. Il faut ensuite mettre à jour les fichiers (rsync ou FTP) et la base de données. C'est pendant cette étape que la migration apparaît aux utilisateurs, puisqu'ils ne peuvent plus intéragir. Dans certains cas (média), cela peut tout à fait passer inaperçu. La durée de la copie est variable et dépend directement de la taille du site.

Une fois le transfert effectué, vérifier (toujours grâce au fichier hosts) une dernière fois que le nouveau site est en état, puis changer le pointage DNS sans modifier les TTLs (au cas où un problème survient, le retour en arrière doit rester possible rapidement). Le changement sera propagé en quelques minutes seulement (penser à retirer la ligne du fichier hosts pour confirmer...), le nouveau site est en production.

Finalisation

S'il n'y a toujours pas de problème après quelques minutes ou heures, il faut remettre les choses en mode croisière : remettre des TTLs longs (1 jour / 86400 secondes), lancer une première backup sur le nouveau serveur et récupérer (et conserver) la dernière backup de l'ancien serveur.

Conclusion

Zéro coupure, zéro bizarrerie, seulement un passage en lecture seule de quelques minutes (durée égale au temps de la mise à jour des données).

Tout ça parce que la transition a été planifiée, surtout pas précipitée, et que les choses ont été faites dans l'ordre.

Les derniers jours ont été remplis d'annonces sur les mailing-lists d'OVH... Voici un petit point sur les plus intéressantes à mes yeux.

Téléphonie IP

Pour un prix raisonnable (les TPE étant la cible), il sera possible d'avoir une ou plusieurs lignes téléphoniques, avec un vrai téléphone, le tout fourni par OVH. Rien n'empêchera ensuite de faire pointer un numéro géographique (et ce dans plusieurs pays) ou un numéro surtaxé sur cette ligne (indicateur 09).

Parallèlement, il sera possible de faire acheminer du trafic voix vers un serveur dédié pour le traiter de façon 100% personnalisée (serveur vocal / audiotel) et ce gratuitement (le prix étant inclus dans celui du dédié).

En plus de ça, il y aura un programme revendeurs avec un pourcentage sur le chiffre généré par les clients.

Ce qui m'intéresse ici : une ligne fixe sur IP (donc pas cher en appels et réception d'appels) ne dépendant pas de mon FAI. Et des nouvelles techniques à bidouiller (traiter de la voix sur un dédié par exemple).

Real Private Server

Le RPS est une révolution. Lorsqu'Octave avait fait la première annonce pour ce service, en n'en donnant que le non, j'étais persuadé qu'il s'agirait d'une offre de serveurs dédiés virtuels, et donc que ça ne servirait à rien.

Tout d'abord, il faut voir ce qui existe au niveau hébergement :

Hébergement mutualisé

On vous donne un login, un mot de passe et ça fonctionne !

Des milliers de sites sont gérés par un gros cluster (plein de serveurs) et des filers (plein de disques durs). Les ressources (processeur, RAM, réseau et disques) sont partagées entre tout le monde.

C'est très bien pour des sites peu fréquentés ou à faible budget (c'est pas cher puisque tout est partagé).

Serveur dédié virtuel

Vous gérez vous-même votre serveur, de la configuration des services au monitoring de son bon fonctionnement. Pour ça, c'est la liberté. Par contre, vous restez sur un serveur partagé entre plusieurs clients (d'où le terme virtualisation : plusieurs systèmes d'exploitation indépendants sur une seule et même machine).

C'est à éviter dans tous les cas, c'est le cumul des inconvénients du mutualisé (ressources partagées) et du dédié (administration) !

Serveur dédié

On vous donne accès à une machine complète, à vous de la gérer comme bon vous semble.

Le serveur ne fait que ce qu'on lui dit, avec les ressources réelles dont il dispose. Personne ne partage.

C'est idéal, mais il faut mettre les mains dans le cambouis (ou faire sous-traiter cette partie). C'est donc plus onéreux, mais ça permet d'une part une liberté totale, d'autre part des performances optimales (enfin, ça dépend du serveur, et du site !)

Cluster dédié

Pour les très gros sites, plusieurs serveurs sont là pour gérer la charge. Pour faire court, c'est comme le dédié sauf qu'on multiplie les coûts et les performances par le nombre de serveurs.

Bon, maintenant qu'on sait tout ça, il faut placer ce qu'OVH a baptisé Real Private Server (Serveur Privé Réel).

D'après les annonces passées (ça peut encore changer), c'est une solution intermédiaire, entre le serveur dédié virtuel et le serveur dédié tout court. Peut-être plutôt à côté du serveur dédié tout court, d'ailleurs.

Le principe du RPS est de séparer les ressources de calcul (processeur et RAM) des ressources de données (disques durs). Le RPS c'est donc l'addition d'une configuration processeur dédiée et d'un espace disque mutualisé (et c'est donc l'opposé du serveur dédié virtuel).

Parmis les fonctionnalités annoncées :

• changement de configuration processeur : plus assez puissant ? Pas grave, on commande une config plus puissante, et ça fonctionne, plus besoin de déménager des sites, réinstaller des serveurs, reconfigurer tous les services...
• copie d'une image du disque : au lieu d'installer 3 serveurs, on en installe un seul, on copie son image (comme une duplication de disque dur) et on l'associe aux deux autres processeurs. Encore un sacré temps gagné ! En plus, ça fonctionne aussi comme sauvegarde...
• revente d'une image du disque : pour pousser le point précédent, Octave a donné l'exemple d'un prestataire qui installe une fois un système très particulier, puis revend une image de celui-ci à ses clients, sans avoir à réinstaller le système à chaque fois !
• grand choix dans les possibilités de configurations : Octave parlait de "3 minutes" pour passer d'une config à une autre, et au niveau du choix du processeur, AMD sera présent.

Le principal avantage du RPS est sa flexibilité : pour lancer un site / service, pas besoin de prendre tout de suite un serveur surpuissant. On commence petit, et quand ça décolle, on augmente la configuration sans avoir à modifier quoi que ce soit...

Et son principal inconvénient, c'est le système de fichiers mutualisé : moins performant qu'un vrai disque dur, et moins sécurisant pour certains types de données.

Le RPS est annoncé pour le 1er trimestre 2008, j'attends ça avec impatience et j'en commanderai au moins un pour tester et comparer.

Bravo OVH !

Pour dumper une grosse table InnoDB (manipulation inutile en MyISAM) malgré de nombreux accès clients simultanés, sans perte de performances, il ne faut surtout pas utiliser l'option --opt de mysqldump qui ajoutera un verrou sur la table et mettra en attente toutes les requêtes secondaires pendant toute la durée du dump, qui peut atteindre plusieurs minutes ou dizaines de minutes selon les cas...

Au lieu de ça, le plus efficace est d'ajouter les options suivantes :

• --extended-insert ou -e : le résultat du dump sera optimisé avec des insert multiples : moins de texte brut et plus de performances lors de la récupération des données
• --quick ou -q : pour ne pas utiliser de buffer lors de la lecture des tables (le cas contraire saturerait la RAM en quelques secondes)
• --single-transaction : le plus important, ou presque, qui permettra de ne lire que l'état de la table au début du dump, malgré les modifications qu'elle peut continuer à accepter.

Le reste des options, hormis --opt et --lock-tables, est variable et à la convenance de l'utilisateur.

Rediriger le flux STDOUT directement vers gzip ou bzip2 permet d'économiser un espace non négligeable sur le disque : pour une table de 160 Mo une fois dumpée, 13 Mo après le passage de bzip2, ça fait mal !

Conclusion : mysqldump -q -e --single-transaction base | bzip2 -c > base.sql.bz2

Après la mise à jour du serveur qui héberge ce blog (et ceux de mes collègues associés et amis), plus rien ne fonctionnait...

Au début, l'erreur affichée était très bizarre :

Fatal error: Call to a member function isEmpty() on a non-object

L'objet en question était une variable définie quelque part dans la classe "recordset" de Dotclear... Un vrai bazar pour aller la retrouver... et constater que ça n'avançait à rien.

Par chance, sur mon blog j'ai une requête SQL perso pour les tags (le plugin me plaisait pas), et elle échouait aussi. Un coup de "or die(mysql_error())" et j'ai pu voir la fameuse et surtout véritable erreur.

L'erreur ressemblait à ça :

Can't create/write to file './tmp/#sql-4e68_8.frm' (Errcode: 13)

Après recherche sur Google, j'ai trouvé une FAQ Wordpress qui a résumé le problème et sa solution :

Problem: The MySQL variable tmpdir is set to a directory that cannot be written to when using PHP to access MySQL.

To verify this, enter MySQL at the command line and type show variables;

You'll get a long list and one of them will read: tmpdir = /somedir/ (whatever your setting is.)

Solution: Alter the tmpdir variable to point to a writable directory.

Changer le dossier étant inutile à mon goût, j'ai juste chmodé /var/tmp en 777 puisqu'il était bizarrement devenu read-only (sauf par l'user root).

Et tout a remarché d'un coup (sauf le cache de Firefox...).

Sur Lexode, le principal problème de performances qu'on rencontre se situe au niveau des bases de données. La nouvelle version est donc dotée de petits outils de profiling. Objectif : repérer et optimiser les requêtes lourdes.

Lire la suite...

L'event onload est très pratique pour initialiser des scripts Javascript, mais il a une limite : il attend que tout le contenu de la page soit chargé pour s'exécuter.

Lire la suite...

Une petite expression régulière sympathique pour la route :

/^[a-z]{1}(-|(?<!--)([a-z0-9]{1})){2,18}[a-z0-9]{1}$/i

Son pitch, c'est de filtrer les pseudos de Lexode v8 selon leur nouveau format, c'est à dire en acceptant la présence de tirets. Par contre, pour des raisons d'arborescence de fichiers et de compatibilité/respect des normes, le pseudo doit commencer par une lettre et ne pas finir par un tiret. Et puisque c'est plus joli, les tirets consécutifs sont interdits !

J'ai eu la chance d'éplucher en détail la fantastique documentation de PHP (très complète !) pour écrire ce pattern un peu particulier (d'habitude, les expressions régulières sont un peu plus basiques).

Pour me faciliter la vie, j'ai décidé de mettre en place un unit test très basique et rapide pour être sûr en un coup d'œil que chaque cas prévu fonctionne comme attendu (ou pas, d'ailleurs), et j'ai écrit l'expression avec le modifier x (il permet de mettre des espaces pour faciliter la lecture des parenthèses).

Pour la petite histoire, la voilà décortiquée :

• ^[a-z]{1} on commence par une lettre
• [a-z0-9]{1}$ on finit par un chiffre ou une lettre
• {2,18} entre tout ça, on a 2 à 18 caractères : le pseudo fait entre 4 et 20 caractères de toute façon
• -|(?<!--)([a-z0-9]{1}) au milieu, on a soit un tiret, soit un chiffre ou une lettre qui n'est pas précédé(e) de deux tirets ((?<!--)([a-z0-9]{1}))

Pour exprimer cette condition sur les caractères précédents, c'est la chaîne ?<! qui importe. Et elle porte le doux nom d'assertion arrière négative.

C'est définitif : je suis amoureux des expressions régulières^[1] !

Développer une application, ou plutôt des pages (scripts) à fort trafic (même si tout est relatif) n'est pas la chose la plus évidente à faire. Ces derniers mois m'ont appris quelques éléments non négligeables que je me permets de partager ici.

Lire la suite...