Alors que Google vient d'inaugurer son nouveau moteur de recherche spécialisé dans l'indexation des codes sources, des hackers ont déjà trouvé des moyens intéressants d'en tirer parti.



Le principe de Google Code Search est très simple : ce nouveau service indexe "l'intérieur", c'est à dire le code lui même, de tous les packages que les robots de Google trouvent sur l'internet.

Pour les non initiés, un package est une archive contenant tous les fichiers nécessaires à la compilation d'un programme. Généralement, un package contient les fichiers source dans un ou plusieurs langages (php, c, perl, etc.).

Bien évidemment, la logique de Google est d'apporter plus de simplicité à la communauté open-source dont les packages sont libres d'accès et modifiables (par exemple, le code de Dotclear, qui fait tourner ce blog est librement téléchargeable et modifiable).

Mais comme Tyoogle l'a déjà démontré pour la version standard de l'outil de recherche, la puissance des robots de Google est telle que l'indexation des packages met de nombreux développeurs de logiciels propriétaires à la merci du premier hacker venu.

En effet, il suffit de lancer une recherche avec le mot clé "this file contains proprietary" pour se rendre compte que Google propose plus de 100 000 liens vers des pages de code qui, pour la plupart, n'auraient jamais du se retrouver sur Internet.

On savait déjà qu'il fallait éviter de laisser des répertoires non protégés traîner sur un serveur, maintenant il faudra également faire très attention aux .tar.gz et autres .zip contenant du code...

Si comme moi vous avez installé une béta de Windows Vista (sur une partition ou un disque à côté de votre Windows XP) et que vous voulez vous en débarrasser, vous avez certainement supprimé les fichiers de Vista sans autre forme de traitement.

Mais dans ce cas, vous vous retrouvez avec le nouveau Windows Boot Manager de Vista à chaque démarrage. En effet, Microsoft a changé le process de boot et ce dernier est prioritaire sur le boot.ini de Windows XP.

Pour vous en débarrasser, voici la solution (sous XP bien entendu puisque vous avez supprimé Vista) :

- Mettez le DVD d'installation de Vista dans votre lecteur (ou montez l'image à l'aide de Daemon Tools).

- Lancez la console windows (Menu Démarrer > Executer > cmd)

- Rendez vous dans le dossier boot sur le disque de Windows Vista (par exemple d:\boot\)

- Entrez la commande suivante : bootsect.exe -NT52 All

Cette commande réinitialisera la méthode de boot de Windows XP et supprimera cet ennuyeux écran au démarrage de votre PC.

La notion de Web 2.0 évolue rapidement. Très rapidement même. Au point de rappeller à certains la bulle des années 2000. Mais qu'est ce que le Web 2.0 aujourd'hui ?

On constate qu'en 6 mois, on est passé d'une définition purement technique (Ajax et web services : voir notre précédent billet), à une définition "sociale" du Web 2.0.

Au départ, la notion de Web 2.0, définie par Tim O'Reilly, concernait surtout l'aspect applicatif de ces nouveaux sites web. L'apparition des web services et du langage standardisé XML permettaient de lier entre eux de nombreux services sans nécessiter de grandes compétences techniques. Ainsi, les "pages personnelles" ont laissé la place aux blogs, formidables aggrégateurs de contenus. De même, de nouvelles applications sont apparues, notamment grâce à Google. Plus rapides, plus dynamiques, plus ouvertes, elles ont permis de poser les bases des usages nouveaux que permet le Web 2.0.

Mais le buzz énorme qui entoure actuellement le Web 2.0 et qui recommence à donner des frissons aux investisseurs proviens, lui, de l'aspect social engendré par ces technologies. Les notions de "communauté", de "partage de données" jouent à plein et de nombreux services surfent sur cette vague, sans qu'on sache qui tirera son épingle du jeu au final. De Flickr (pour les photos) en passant par Digg (pour les news), certains ont déjà une longueur d'avance... Mais la liste des prétendants est longue : Airset (social networking), Box.net (stockage et partage de données), BubbleShare (partage de photos), Calendar Hub (Calendriers et contacts partagés), Dogster (Communauté pour... chiens), Goowy (page d'accueil style Netvibes), Kaboodle (partage de liens), Mosuki (partage de calendriers et contacts), NowPublic (même principe que Digg), Popist (social networking), RallyPoint (partage de calendriers et contacts), Riya (partage de photos), Rollyo (aggrégateur de moteurs de recherche), Simpy (social bookmarking), Skobee (social networking), TagCloud (aggregateur de contenu taggés à la Technorati), Tagged (idem), Zoho (traitement de texte en ligne), etc.

N'en jetez plus ! Il suffit de visiter tous ces sites pour se rendre compte rapidement d'une chose très simple : il va y avoir des morts. La plupart se recoupent dans leurs fonctionnalités, leur présentation , leurs arguments et, surtout, reprennent des modèles déjà largement matures et dominés par un leader (Flickr, Technorati, del.icio.us, Netvibes).

De plus, la position même de ces "leaders" du Web 2.0 est très incertaine, avec la bataille de géants que se livrent Google, Yahoo et Microsoft pour acquérir la place de leader du Web. En effet, ces trois mastodontes ont lancé une page d'accueil à la Netvibes et n'ont de cesse d'ajouter des services Web 2.0 à leurs portails.

Plusieurs de ces nouvelles start-ups ont déjà d'ailleurs été englouties dans cette lutte à coups de millions de dollars... Flickr, racheté par Yahoo, Writely, Picasa, Blogger, tous rachetés par Google...

Alors, est-ce (déjà) la fin du Web 2.0 ? Certainement pas, mais on peut cependant affirmer que la plupart des applications de networking sont désormais maîtrisées, quoique leur modèle économique soit encore loin d'être démontré.

Mais il ne faut pas oublier le fondement même du Web 2.0 : la technologie et l'accessibilité. La possibilité d'accéder en ligne à des applications qui concurrencent de plus en plus les applications de bureau (comme le nouveau Yahoo! Mail) laisse encore entrevoir de nombreuses possibilités. L'apparition de normes comme l'Open Document Format qui définit une norme de formatage XML des documents de type Office, laisse entrevoir la fin du leardship total de Microsoft sur la bureautique.

C'est dans ce domaine qu'il reste des choses à inventer et que les technologies les plus avancées (XUL et XAML) se dirigent.

Lors de la conception de Firefox, les développeurs de la fondation Mozilla ont eu la bonne idée de créer toute l'interface du logiciel dans un langage créé pour l'occasion : XUL.

Basé sur XML et Javascript, il permet de réaliser très simplement des interfaces graphiques, en offrant une impressionante gamme de balises capables de repondre aux besoins les plus complexes. Associé à l'objet xmlHttpRequest (technologie Ajax), ce jeu de balises permet de construire des applications web dynamiques très proches d'une application compilée.

Proche d'Ajax dans sa définition et ses outils communs (Javascript, CSS, etc.), XUL s'en distingue cependant sur plusieurs aspects :

Alors qu'Ajax a une vocation de compatibilité universelle, XUL ne peut s'exécuter que dans le contexte des applications de la fondation Mozilla (Firefox, Thunderbird...). C'est un avantage en terme de portabilité, les applications mozilla étant multiplateformes, mais c'est un inconvénient en terme d'universalité puisque l'application web ne fonctionnera pas dans Internet Explorer. On utilisera donc XUL dans un contexte on l'on maîtrise le navigateur utilisé par les utilisateurs (cas typique d'un Intranet par exemple). A oublier pour les sites grand public.

L'autre différence réside dans la possibilité de réaliser de véritables applications de bureau en XUL, à travers le module XULrunner de la fondation Mozilla. XULrunner vous permet de créer un véritable exécutable qui embarque le moteur logiciel Gecko qui permet de faire tourner XUL. Le meilleur exemple étant bien entendu Firefox, dont toute l'interface utilisateur a été réalisée en XUL.

XUL est donc un langage dédié à la création d'interface utilisateurs de gestion et non à l'affichage d'informations, comme l'est Ajax. En gros, il sert à concevoir des logiciels, prêts à s'exécuter dans le navigateur ou indépendamment de celui-ci. Bloxor est un bon exemple d'application XUL en ligne (lire notre article à son sujet).

Le fonctionnement de base de XUL est extrêmement simple, en voici un exemple tout bête :

<?xml version="1.0"?>

<?xml-stylesheet href="chrome://global/skin" type="text/css"?>

<window title="Ma première page en XUL"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

<description><html:h1>Mon premier boutton XUL</html:h1></description>

<box align="center">
<button label="Cliquez-ici" oncommand="alert('Vive Web Interdit !');" />
</box>
</window>

Il vous suffit de copier ce code dans un fichier texte, de l'enregistrer avec l'extension .xml et de le mettre sur votre serveur pour obtenir ce résultat, si toutefois vous utilisez Firefox ou un navigateur basé sur Gecko.

La lecture du code est limpide : les balises XUL s'utilisent exactement comme du HTML, mais en beaucoup plus puissant.

Vous l'aurez compris, XUL est idéal pour toutes les applications qui agissent sur de l'information formatée : finance, back office de sites web, applications de gestion... Mais attention, XUL ne s'occupe que de l'interface utilisateur. Il faudra derrière développer l'application en elle-même, que ce soit une application web basée sur php ou une application en C.

XUL est pour l'instant un langage unique, mais il devrait être rejoint par son équivalent Microsoft : XAML. Mais celui ci s'annonce, comme toujours, beaucoup plus soucieux de son intégration à Windows que du respect des technologies normatives que sont XML et CSS. En gros, XAML et XUL auront les mêmes avantages et inconvénients qu'Explorer et Firefox, mais seront incompatibles. La routine quoi...

Pour gérer des milliers ou des millions d'utilisateurs, un site web se doit de mettre en place un certain nombre de technologies afin que les visites des utilisateurs soient garanties et agréables. En termes techniques, on parle de redondance et de répartition de charge (load balancing en anglais). L'association de ces deux paramètres permet d'atteindre ce qu'on appelle la haute disponibilité : en gros un service qui ne peut pas tomber en panne et qui peut facilement monter en charge.

Vous vous en doutez, aucun serveur n'est assez puissant pour gérer un gros site web, et, de toute façon, il pourrait tomber en panne.

Alors, comment font les éditeurs de sites web ?

Pour obtenir la redondance, les serveurs sont répliqués, c'est à dire qu'il coexiste plusieurs serveurs, au contenu identique. Ainsi, en cas de panne d'une machine, les autres assument la charge supplémentaire le temps de la réparation

Pour ce qui est de la charge, le principe est simple : le load balancer (qui peut être un serveur ou un dispositif hardware dédié) envoie toute requête entrante au serveur le plus disponible. Si tous les serveurs saturent, la solution est simple : on ajoute une machine.

Il y a des dizaines de configurations possibles, mais nous allons prendre un exemple assez commun, qui démontre bien la mise en oeuvre de ces principes à tous les niveaux de l'architecture d'un service web haute disponibilité sous linux.




Premier niveau : l'arrivée des requêtes sur la tête de plateforme

Quand votre requête ("je veux telle page web") arrive sur l'architecture, elle passe d'abord par un firewall. Ce dernier vérifie qu'elle est bien autorisée par l'architecture. En gros, c'est la même chose que votre pare-feu Windows. Sous Linux, le programme chargé de ce travail se nomme IP Tables (anciennement IP Chains).

Ensuite, si la requête est autorisée, elle est passée au load balancer (LVS soit Linux Virtual Server) qui décide quel serveur va répondre (en principe le moins chargé, mais de nombreux réglages sont possibles). Le load balancer envoie la requête au serveur web. A votre niveau c'est transparent : vous n'avez aucun moyen de connaître la machine qui va vous répondre.

A ce niveau, les deux serveurs sont redondés : ils ont un clone qui attend sagement, prêt à prendre le relais. Chaque serveur est relié à son clone via un petit logiciel (Heartbeat) qui pingue régulièrement le serveur en ligne pour s'assurer de sa disponibilité. A la moindre défaillance, le clone prend le relais et emet une alerte à l'administrateur pour intervention.

Deuxième niveau : le traitement des requêtes sur les serveurs frontaux

Votre requête arrive finalement sur le serveur web (appellé "frontal", car c'est lui qui renvoie la page directement sur le web). Le serveur web (Apache en général sous Linux) exécute votre demande : il exécute le code php, interroge la base de donnée, insère les variables dans la mise en page HTML et vous renvoie le tout sous la forme d'une page statique.

D'ailleurs, la plupart des serveurs vous renvoient effectivement une page statique précalculée par un système de cache : les pages les plus fréquemment demandées sont stockées "en dur" (en html) et ne sont recalculées que périodiquement, soulageant ainsi le processeur des serveurs web et évitant l'accès à la base de donnée. Le recalcul de la page peut intervenir soit après un certain délai, soit après un certain nombre d'affichages. C'est notamment le cas pour les pages dont le contenu change peu fréquemment : pages de catalogue par exemple.

Dans notre exemple, ce sont également les serveurs frontaux qui vous renvoie les images associées à la page, mais le plus souvent celles-ci font l'objet d'un stockage séparé et partagé entre les frontaux. Ce stockage est effectué sur des périphériques dédiés (SAN) aux disques durs ultra-redondants (RAID 5). Il est également courant de faire appel à un CDN (Content Delivery Network). Ces réseaux (comme Akamai) disposent de milliers de serveurs répartis sur l'ensemble de la planète. En répartissant votre contenu statique (images, médias, html) sur leur réseaux, ils permettent de délivrer l'information au plus près de l'internaute, améliorant grandement les performances des sites à audience mondiale.

Troisième niveau : la base de données

La base de données pose un problème un peu différent. Il est très difficile de gérer des écritures et lectures sur plusieurs serveurs (sauf technologies de clustering, mais restons dans une architecture simple). En effet, une base de donnée qui doit se mettre à jour simultanément sur plusieurs serveurs pose des problèmes techniques hors du spectre de cet article. Mais comme la plupart des sites web ont un rapport lecture/écriture de l'ordre de 90/10, voire 95/5, une solution alternative très simple existe : l'architecture maître-esclave (aussi appellée replication).

Le principe est simple : un seul serveur (le maître) assure les opérations d'écriture (commandes SQL INSERT, UPDATE et DELETE), tandis que les esclaves assurent uniquement les opérations de lecture (commande SQL SELECT). La synchronisation entre le maître et les esclaves est quasi instantanée. Il est donc possible d'obtenir une information ancienne (avant la mise à jour par le maître) mais ce risque concerne un nombre très minime de requêtes et reste acceptable dans la plupart des cas.

La replication apporte également l'avantage de la redondance : en cas de défaillance du maître, il suffit d'activer les opérations d'écriture sur un esclave pour disposer d'un nouveau maître.

Bien d'autres dispositifs de sécurité existent au niveau hardware des serveurs eux-mêmes (double alimentation, redondance des disques en RAID, double cartes réseau...) et bien entendu du datacenter (sécurité incendie, alimentation electrique ondulée, générateurs de secours, connexions multi-opérateurs).

L'ensemble des ces dispositifs crée la haute-disponibilité, garante d'un accès permanent à vos sites web favoris.

On parle beaucoup du web 2.0 en ce moment. Mais pour beaucoup, ceci reste de l'ordre du concept...

Parmi les technologies à la mode, on trouve Ajax. Mais si vous tapez "Ajax" dans google, vous trouverez surtout des démos, certes impressionantes, mais dont on ne voit pas directement l'utilité au quotidien.

Mais c'est quoi Ajax ?

Il s'agit d'un ensemble de technologies associant :

• HTML et CSS2 pour la présentation
• Javascript pour la couche applicative côté client
• PHP (ou autre) pour la couche applicative côté serveur
• XML/XSLT pour la manipulation et l'échange des données
• l'objet XMLHttpRequest pour les échanges asynchrones entre le serveur et l'application

L'association de ces éléments, tous standards, permet de développer des sites web très dynamiques et modulaires. En s'affranchissant du rafraîchissement page par page (mode asynchrone), les modules d'une page sont mis à jour indépendamment, produisant des interfaces riches proches d'un vrai logiciel, fonctionnant dans tous les navigateurs.

Mais cette description idyllique se heurte dans les faits à quelques problèmes :

• une standardisation théorique qui n'existe pas dans la réalité : il est nécessaire de tester l'application sur tous les navigateurs et d'adapter son code en fonction de ceux ci. Une obligation qui nous ramène plutôt à ce qu'était le web il y a 3 ans, avec les pages alternatives pour Netscape et Internet Explorer.


• une publication intégrale du code client sous forme de fichiers JS facilement copiables. Cette tendance est certes dans la tendance GNU, mais ne ravira pas l'éditeur d'un service dans un milieu concurrentiel. Des solutions d'exécution de ce code côté serveur existent, notamment en Java ou Python, mais elles se heurtent à la problématique évoquée dans le point suivant.


• une absence de framework applicatif : dans ce mix technologique qu'est Ajax, il n'existe pas de vraies conventions de développement. Les technologies utilisées se recroisent en de nombreux points et les choix de développements sont infinis. Difficile de savoir à l'avance quel sera l'architecture la plus rapide ou la plus facilement maintenable.

Cependant, les projets avancent et parmi ceux-ci Netvibes est une initiative particulièrement enthousiasmante.

Ce projet remet au goût du jour le fantasme des années 2000 : le portail personnalisable. Partant du principe qu'à l'avenir l'information piochée sur le web serait constitué de flux (les fils RSS sont là pour le démontrer), Netvibes propose à chaque internaute de se composer sa propre page d'accueil.

Composée de modules divers (Météo, Compte Gmail, Fils RSS), la page web se transforme en grand dash board où les modules sont comme des widgets, un peu à la manière de Mac OS X Tiger (en plus sobre).







Les widgets peuvent se déplacer, se réduire, se paramétrer... Toutes les préférences de l'utilisateurs sont sauvegardées, et en vous reconnectant vous retrouvez votre dashboard comme vous l'aviez laissé. Magique !


Un widget en mode Edition - Réglage des préférences

Certains widgets laissent entrevoir la puissance de l'outil : interrogation de comptes mail pop, surveillance de prix sur Kelkoo...

A l'usage, Netvibes se révèle très agréable, même s'il est encore perfectible. Et sa structure modulaire lui garantit un avenir très riche : le succès des widgets pour Mac Os est là pour en donner un apercu.

L'analyse rapide du code javascript donne une idée du travail accompli pour un applicatif relativement simple et dépouillé : Ajax et le web 2.0 sont à réserver à des développeurs plus qu'avertis...

En tout cas une chose est sûre, dans très peu de temps, notre perception du web et de son ergonomie vont radicalement changer.