En janvier 2008, le rachat de MySQL AB par Sun fut un événement majeur et plutôt bien accueilli. Mais l’ambience était tout autre après le rachat de Sun par Oracle. J’émettais de fortes réserves sur la survie de MySQL dans le giron de l’ambitieuse société californienne.

Les craintes se sont confirmées et une grande bataille se joue en ce moment pour sauver MySQL. Michael « Monty » Widenius, le créateur de MySQL, a lui-même tiré la sonnette d’alarme en décembre et a anticipé les problèmes que vont rencontrer les utilisateurs de MYSQL.

Sans réponses claires et pérennes d’Oracle, la communauté s’organise et une pétition a été lancée pour convaincre les pouvoirs publics et les autorités de régulation des marchés d’étudier le cas de la fusion Oracle-Sun-MySQL. Libre à vous de décider de l’avenir de MySQL, mais le danger est, à mon avis, bien réel. J’attends d’être convaincu du contraire…

Pour en savoir plus : Save MySQL !

Jeudi dernier se tenait le Barcamp PHP Cheese & Wine. Même si le vin et le fromage ont été très appréciés, nous n’étions pas venus (seulement) pour ça. Alors pour les absents qui ont eu tort de l’être, voici une petite synthèse de cette longue soirée.

Un vrai barcamp

Premier bon point : c’est un vrai barcamp où les participants se présentent et définissent le contenu des ateliers. Tous les barcamps ne respectent pas cette règle de base… Xavier Gorse, président de l’AFUP, a donc joué le rôle de « maître de cérémonie » pour établir le programme d’après les souhaits de chacun  :

• PHP et sécurité
• PHP 5.3
• Déploiement d’applications PHP
• PHP et les bases de données « NoSQL »
• Outillage PHP
• PHP et testing
• Frameworks PHP

Pour ma part, j’ai participé aux ateliers :

• Déploiement d’applications PHP
• PHP et les bases de données « NoSQL »
• PHP et testing

Je limite donc mon article à ces sujets, sachant que d’autres synthèses ont déjà été publiées :

• Synthèse du Barcamp PHP toulousain, par Raphaël Rougeron
• Synthèse du Barcamp PHP toulousain, par Thomas Gasc

Déploiement d’applications PHP

Cet atelier a mis en évidence la difficulté de déployer des applications web en général (technologies nombreuses et environnement hétérogène). Tous les outils existants ont été passés en revue, du paquet Linux (.deb) aux outils spécifiques à PHP (PEAR, Phing, Phar) en passant par des intermédiaires parfois plus adaptés (makefile, Puppet, Capistrano, Ant). Deux groupes de participants étaient clairement représentés, avec des besoins très différents :

• Déploiement d’une solution sur un parc important et hétérogène (cas des éditeurs de solutions, comme Linagora avec OBM)
• Déploiement d’un projet sur-mesure sur un ou quelques serveurs, mais très fréquemment et avec des contraintes d’intégration de contenus externes (cas des agences web, avec plusieurs déploiements par jour).

Dans le premier cas, la difficulté est d’identifier la configuration des serveurs cibles et de préparer les paquets d’installation correspondants (.deb pour chaque distribution Linux, .msi pour chaque version de Windows, etc.), tout en assurant la compatibilité des données sans toujours les connaître (tests de régression).

Dans le second cas, il faut savoir intégrer pendant le déploiement les données du site en exploitation (base de données, templates gérés par un web designer externe, etc.), avec d’éventuelles transformations (ETL, Extract Transform Load).

J’ai ajouté qu’un déploiement ne se limite pas à la livraison de la partie applicative mais doit aussi savoir traiter la mise à jour des outils liés au projet (plate-forme de gestion de tickets, extranet, feuille de route, tests, sauvegardes, alertes, etc.).

En dehors de PEAR, trés utilisé et qui est un outil de déploiement à l’origine, j’ai une préférence pour Ant + Phing et Capistrano.

Bases de données « NoSQL »

Là, on entre dans une autre dimension. Les bases « NoSQL » sont des bases de données non relationnelles. En gros, on ne retrouve pas le schéma habituel « tables contenant des champs et étant reliées entre elles ». L’avantage est d’obtenir des performances exceptionnelles sur des entrepôts de données énormes. Parmi les acteurs majeurs qui développent et utilisent des bases « NoSQL », on peut citer : Google (projet Big Table qui a inspiré le projet Cassandra), Facebook ou Linkedin.

Si on revient à la dure réalité d’un acteur de dimension modeste, on constate que ces technologies émergentes et prometteuses sont encore très spécifiques. Les bases relationnelles ont de beaux jours devant elles. La difficulté est notamment de réintégrer dans l’application PHP ce qui fait la force des systèmes SQL : sélection, jointures, intégrité référentielle, etc. Le volet testing des projets en prend un coup…

PHP et testing

Atelier en petit comité (6 personnes), en concurrence déloyale avec l’atelier Frameworks qui a fait le plein ! Nous avons tenté de lister les types de tests liés à une application web, en dépassant autant que possible la simple vue du développeur :

• Tests unitaires (PHP et Javascript)
• Tests fonctionnels
• Tests d’IHM (via Selenium Core, Selenium RC et Selenium IDE)
• Tests de recette
• Tests de non régression
• Tests de performance
• Tests de charge
• Tests de conformité (normes, W3C, accessibilité, etc.)
• Tests ergonomiques (tri par cartes, paper prototyping, tests utilisateurs, etc.)
• A/B testing

Les échanges sur nos expériences ont été très instructifs. Nous étions tous d’accord pour insister sur la définition précise des cas d’utilisation qui facilite la gestion des tests pendant toute la durée du projet avec le client. D’où une phase de spécifications sérieuse qui conditionne la qualité du travail livré. Certains tests peuvent faire l’objet de validation contractuelle, comme les wireframes issus de tests ergonomiques qui servent ensuite de feuille de route aux intégrateurs et développeurs.

La difficulté avec les tests, c’est de savoir placer le curseur pour ne pas s’y noyer. Il n’est pas réaliste d’appliquer les tests de façon exhaustive. C’est un idéal en contradiction avec les budgets et les délais imposés en pratique. Il faut donc savoir réaliser les bons tests, au bon endroit et au bon moment. Par exemple, sur le calcul des prix d’un panier de site e-commerce, sur l’intégration des données lors d’un couplage entre deux systèmes, sur l’ergonomie d’une interface riche, etc.

En résumé

Une excellente soirée qui a largement dépassée les 5 heures prévues ! L’accueil de Linagora et de l’AFUP était parfait, l’ambiance très sympathique et le niveau des échanges très pointu. Il y a des gens qui savent faire des choses avec PHP en Midi-Pyrénées ! Je pense qu’on remettra ça sous peu. Prochaine étape : le Bargento, lundi 9 novembre à Paris. Je serai présent avec l’équipe de l’AFUP pour organiser et animer cette journée qui s’annonce exceptionnelle. Et à la suite, le Forum PHP 2009, tout aussi exceptionnel. Sur ce coup-là, je déclare forfait. Il faut bien travailler un peu !

Le rachat de MySQL par Sun était déjà un événement pour moi l’an dernier. Alors je ne sais plus quels mots utiliser après le rachat de Sun par Oracle aujourd’hui…

Sachant comment finissent les entreprises qui passent entre les mains d’Oracle, il reste une sacrée incertitude sur certains projets (Java et MySQL pour commencer).

Même s’ils sont ultra-surveillés et protégés, les 13 serveurs racines qui gèrent tous les noms de domaine d’internet, étaient également potentiellement concernés.

Au fait, à quoi sert un serveur de noms de domaine ? Tout simplement à faire le lien entre un nom de domaine et une adresse IP (et inversement). Chaque machine branchée sur internet possède une adresse IP qui permet de la rendre unique sur le réseau mondial. Cependant, utiliser une adresse IP ne suffit pas. D’abord, elle n’est pas facile à retenir. Et puis, comment feraient les utilisateurs de Google qui exploitent 450.000 serveurs ? Il est plus simple de taper www.google.com dans son navigateur que 64.233.167.99. Même si ça marche, évidemment (si, si, essayez !).

Le serveur de noms de domaine est donc un maillon indispensable d’internet. Quand il s’arrête, vos services internet aussi…

Bref, hier, tout le monde était sur le pont… et moi avec ! Si vous gérez un serveur DNS, n’attendez plus, mettez à jour votre installation, c’est vital ! Le correctif est publié et disponible pour pratiquement tous les systèmes.

C’est long, précis et bien écrit. Amplement suffisant pour comprendre le fonctionnement et les atouts extraordinaires de cette plate-forme e-commerce.

Bonne lecture !

Les contraintes des serveurs mutualisés sont souvent agaçantes, mais rarement insurmontables. C’est le cas chez OVH quand on veut installer Drupal 6.

Drupal ne s’installe pas si register_globals est activé, ce qui est le cas par défaut chez OVH (ce serait trop simple…). Mais il est permis de modifier le comportement du serveur, grâce à quelques directives qu’il faut ajouter au début du fichier .htaccess inclus dans le package Drupal :

SetEnv PHP_VER 5
SetEnv REGISTER_GLOBALS 0
SetEnv ZEND_OPTIMIZER 1

En gros, je passe en PHP5, je désactive register_globals et j’en profite pour obtenir les avantages de Zend Optimizer.

Il faut également décommenter la ligne RewriteBase / dans le même fichier pour que la réécriture des adresses par Apache fonctionne correctement :

# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
RewriteBase /

# Rewrite URLs of the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Et là, miracle, Drupal s’installe. Enfin, pas pour tout le monde : sur les anciens hébergements, MySQL est encore en version 4.0, incompatible avec Drupal. Pour s’en sortir, il faut migrer votre base de données vers un autre serveur SQL OVH.

Attention, l’opération est très critique… et n’a pas fonctionné pour moi ! En fait, elle consiste à détruire la base pour la reconstruire à partir de vos sauvegardes. Donc premier point : vérifier que vos sauvegardes sont intègres. Ensuite, il faut suivre la procédure OVH.

Sauf que lorsque j’ai voulu reconstruire la base via le manager OVH, elle n’apparaissait plus dans la liste ! Résultat : plus de base de données ! C’est pratique…

Après l’ère du contenu généré par l’utilisateur (user generated content) et alors que nous commençons tout juste à avoir les outils pour créer facilement nos applications (user generated applications), Bug Labs commercialise des briques matérielles bien réelles pour créer ses propres appareils électroniques. Les user generated devices sont nés.

La gamme BUG se compose de BUGbase, la brique de base sur laquelle viennent se greffer les BUGmodules, tels qu’un capteur GPS, une caméra vidéo, un écran tactile, un capteur de mouvement, des touches, etc.

La BUGbase…

… et ses BUGmodules.

Même si Lego le fait depuis longtemps, n’allez pas croire que BUG est un simple jouet ! Vous avez un potentiel créatif sans limite, servi par une excellente utilisation de la programmation orientée objet, l’objet ayant dans ce cas une réalité matérielle peu fréquente. Pour développer les fonctions de son appareil, le « créateur-concepteur-utilisateur » dispose d’un environnement de développement (BUG SDK, fonctionnant sous Eclipse) qui repose sur des technologies éprouvées (Java + framework OSGi).

Le BUG SDK en action.

C’est donc tout naturellement que Bug Labs vient de remporter un CES award 2008.

Depuis 2004, on sait que MD5 n’est plus très sûr. Cependant, casser cet algorithme n’est pas à la portée de tout le monde. Aucun risque pour vos bases de données utilisateurs ? C’est sans compter sur les bases de hash MD5. Leur but : stocker des chaînes de caractères et leur hash. Comme les utilisateurs entrent souvent des mots communs ou connus, il est très simple d’interroger ces bases pour obtenir la liste des chaînes de caractères compatibles avec un hash MD5. GData en est un exemple particulièrement efficace et complet.

Vous voulez connaître le mot de passe caché derrière le hash MD5 fe01ce2a7fbac8fafaed7c982a04e229 ? Le voici en 1/10^e de seconde : demo. Et celui-ci, assez fréquent dans les bases mal paramétrées : 21232f297a57a5a743894a0e4a801fc3. C’est admin !

Il est temps de changer de méthode de cryptage…

Source : Nexen

Pas très réjouissant comme cadeau de fin d’année… L’essentiel est qu’Askimet ne croûle pas sous la charge ! Mais, connaissant les critiques récurrentes sur la vulnérabilité de WordPress face aux spams, sauvé comme par miracle par l’extension Askimet… du même éditeur, c’est peut-être là qu’est le défi que souhaite relever quelques spammers.

Qu’ils aillent jouer ailleurs !

MySQL Proxy, proposé par MySQL AB, est le genre d’outils dont le rôle semble si évident qu’on se demande pourquoi il n’existait pas avant. Comme tout proxy, il récupère les requêtes destinées à la base de données, effectue des traitements et adresse une requête modifiée au serveur MySQL. Bien entendu, l’opération inverse est aussi gérée : MySQL Proxy sait récupérer un résultat de requête et le transformer avant de l’adresser au client initial.

Fonctionnalités

Après cette petite présentation, on peut se demander pourquoi on aurait besoin d’un proxy, puisque les services applicatifs (s’ils sont correctement architecturés et codés…) devraient envoyer une requête optimisée au serveur MySQL. Une petite liste des fonctionnalités finit par convaincre de son intérêt :

• Analyse des requêtes
• Filtrage et modification des requêtes et des résultats
• Injection de requêtes
• Load balancing
• Exécution de scripts (basés sur le langage LUA)

Cas d’utilisation

Dans la pratique, on peut imaginer les situations suivantes :

• Corriger les erreurs de syntaxe communes.
• Garantir le fonctionnement d’anciennes applications utilisant des requêtes non supportées.
• Supprimer du résultat un mot de passe demandé dans la requête.
• Récupérer et fusionner avec le résultat des données externes à la base de données (fichiers, flux XML, RPC…)
• Router les requêtes vers un autre serveur MySQL ou vers une autre base de données du même serveur.
• Empiler un lot de requêtes et les contrôler avant de mettre à jour les tables.
• Dupliquer les requêtes en temps réel sur deux bases différentes.
• Exécuter un script shell avant ou après des modifications dans la base de données.
• Interdire certains motifs de requêtes.
• Verrouiller des tables selon le contexte.
• Contrer les injections SQL non désirées.

On le voit, les possibilités sont infinies et ne dépendent que des contextes de production et de l’imagination des développeurs. MySQL Proxy permet surtout d’éviter d’intégrer la gestion de l’exploitation des bases de données MySQL dans les services applicatifs. Voilà enfin une saine séparation du travail du développeur métier et de l’administrateur MySQL !

Mise en oeuvre

MySQL Proxy est encore en version alpha et son fonctionnement n’est garanti que pour les versions MySQL 5.0.x et ultérieures.

Pour découvrir ses possibilités, O’Reilly Network propose un didacticiel clair et très fourni : Getting Started with MySQL Proxy.

Source : Linuxfr.org