Le weblog entièrement nu

La dixième conférence Debian, cette année à Cáceres (Espagne), commence officiellement demain. Moi j'y suis arrivé depuis quelques jours déjà, après trois jours de moto avec deux membres de la cabale italienne (qui essaient d'infiltrer la française, d'ailleurs).

Donc ça fait quelques jours que je suis au Debcamp, le rassemblement des geeks Debian qui viennent pour travailler ensemble. Et même pour des gens habitués au mail et aux messageries instantanées, se retrouver autour d'une table constitue un gain énorme en productivité. Et ça marche bien : bientôt sur vos écrans, une annonce sur ce que j'ai fait de mon temps, mais visiblement de nombreux pans de Debian ont pas mal progressé aussi. Et ça n'empêche pas de boire une bière le soir, voire de jouer à des jeux qui nous font passer pour des malades.

Debcamp, c'était une centaine de personnes. La Debconf elle-même est prévue pour accueillir environ le triple. Donc une centaine de personnes sont arrivées aujourd'hui, et encore autant sont prévues pour demain. L'ambiance change du tout au tout, et l'énergie est presque palpable dans l'air. Ça parle un mélange de toutes les langues (en changeant au milieu des phrases quand un nouveau arrive dans une conversation), ça se retrouve après des années même s'il ne s'est écoulé que quelques jours depuis la dernière conversation électronique, ça s'échange des idées, ça les met en place, des trucs géniaux apparaissent en une heure, et les conférences elles-mêmes n'ont même pas encore commencé. Donc ça va être encore plus concentré quand tout ça devra se faire en-dehors des présentations.

Ma dernière Debconf remonte à la Debconf 6, et je me rappelle maintenant pourquoi je regrettais de ne pas avoir assisté aux suivantes.

Quand j'étais petit, mon papy me racontait l'histoire du type qui était mort à 1000 ans et celle de celui né à 40 ans. Et ça me faisait beaucoup rire.

Eh ben aujourd'hui, c'est pas pour me vanter, mais j'ai à la fois 20 ans, 40 ans et 100000 ans. Et 32. Et c'est pas demain la veille que ça va se reproduire, donc fiesta !

(Le monde se divise en 10 catégories : ceux qui comprennent le binaire et ceux qui se creusent la tête.)

Si vous n'avez pas passé les trois dernières semaines sous un caillou ou dans un monastère, vous savez déjà que la version 5.0 de Debian GNU/Linux, nom de code « Lenny », est sortie le 14 février dernier. Pour accompagner la publication de cette nouvelle version majeure de Debian, Raphaël Hertzog et moi-même avons également mis à jour le Cahier de l'admin Debian. L'édition portant sur Lenny est déjà disponible en version électronique sur Izibook, et la version papier sera chez les libraires le 19 mars. Elle ne constitue pas une révolution (on ne change pas une formule qui est devenue au fil des ans la référence en français), mais principalement une mise à jour, avec des ajouts pour combler quelques vides (par exemple, de nouvelles sections sur OpenVPN et les partitions chiffrées).

Pour certaines des précédentes éditions, il avait été lancé un concours où les personnes faisant la meilleure promotion étaient récompensées par des exemplaires du livre. Pour cette édition, nous avons gardé l'idée, mais l'objet du concours est différent : il s'agit non plus de faire la promotion du livre, mais de participer à la communauté Debian. Pas besoin d'être un super-développeur, il suffit d'apporter une contribution qui va faire progresser Debian d'une manière ou d'une autre, à condition que ce soit tangible. Raphaël écrit une série d'articles sur le sujet, vous pouvez donc aller y piocher des idées. J'en ajouterai deux, complémentaires :

• Publier un blog qui donne une visibilité aux évolutions récentes, en cours ou prévues de Debian unstable et/ou testing, voire experimental. Quelques exemples de ce qu'on pourrait y voir serait l'arrivée d'une nouvelle version majeure du noyau ou de Gnome, la disparition d'un paquet au profit d'un autre, l'arrivée de nouveaux paquets intéressants, leur migration vers testing, etc. Pas une liste de tous les changements de chaque bibliothèque mineure, mais juste une vue macroscopique de ce qui se passe de visible pour les utilisateurs.
• Dans un registre un peu différent, il serait intéressant de publier (peut-être aussi sous forme de blog) un baromètre de l'état actuel d'unstable, avec les migrations en cours, les paquets importants connus pour être cassés, etc. Le but est de faciliter l'usage d'unstable par des utilisateurs courageux-mais-pas-téméraires. Un exemple de ce que j'y verrais bien est une mention du bug 511009, assorti d'une mention que c'est pas une bonne idée d'upgrader CUPS pour l'instant (ça m'aurait évité quelques heures d'interrogations) ; et un autre billet quand c'est résolu. Là encore, trop de débit ne servirait à rien, il suffirait d'une vision macroscopique de l'état des différents sous-systèmes.

Bien entendu, ce ne sont que des idées, et les plus originales seront peut-être les meilleures, puisqu'elles seront celles que nous n'auront pas prévues et apporteront donc une réelle nouveauté.

Les juges du concours sont, devinez qui… Raphaël et moi. Nous essaierons bien entendu d'être impartiaux et de ne pas donner dans le copinage, mais il est évident que les contributions qui nous touchent directement seront appréciées. Pour trouver une justification noble à ce favoritisme, disons que c'est pour inciter les participants à s'impliquer dans la communauté et pas juste à un aride ensemble de bugs sans humanité : nos centres d'intérêt sont largement documentés sur la toile, et ça fera une excellente manière de se familiariser avec les différents outils et sources d'informations disponibles.

Le concours est doté de 10 éditions papier du livre pour les nouveaux contributeurs, et je pense qu'on peut le comparer à un genre de stage à sujet libre (à condition qu'il ait des résultats concrets et positifs). Trois exemplaires supplémentaires seront également remis à des contributeurs plus anciens au titre de récompense « pour l'ensemble de leur œuvre ».

Références :

• Titre : Debian Lenny
• Auteurs : Raphaël Hertzog et Roland Mas
• ISBN13 : 978-2-212-12443-9
• Site web : chez Raphaël et chez Eyrolles

(Ceci est juste un résumé en français de l'annonce complète en anglais.)

Au début, il y avait SourceForge, un logiciel libre développé par une boîte qui s'appelait (à l'époque) VA Linux Systems. Ce logiciel était utilisé par plein de gens, et développé de manière plus ou moins collaborative. Un jour, VA Linux Systems a décidé que les nouvelles versions de SourceForge (à partir de la version 3) ne seraient plus libres (et qu'elles s'appelleraient Sourceforge Enterprise Edition). Plusieurs personnes sont donc parties avec la dernière version libre (celle qui aurait pu devenir la version 2.6), avec dans l'idée de maintenir ce code.

Il y a donc eu GForge, un logiciel libre développé entre autres par une boîte qui s'appelle le GForge Group. Ce logiciel était utilisé par plein de gens, et développé de manière collaborative, notamment par votre serviteur. Un jour, le GForge Group a décidé que les nouvelles versions de GForge (à partir de la version 5) ne seraient plus libres (et qu'elles s'appelleraient GForge Advanced Server). Mais comme l'hébergement du projet était maintenu ouvert, les versions 4.x ont pu être maintenues de manière libre et collaborative.

Pendant ce temps, l'appellation "GForge Advanced Server" s'est faite de plus en plus rare, et des noms plus équivoques sont apparus : "GForge AS", "GForge Express Edition" (ou "GForge EE") et, plus récemment, "GForge Community Edition", aucun de ces logiciels n'étant libre (même si certains sont disponibles en téléchargement gratuit et qu'on peut même jeter un œil aux sources).

Comme cette ambiguïté prêtait à confusion (certains utilisateurs ont installé une version propriétaire en croyant installer un logiciel libre), les principaux développeurs de la version libre de GForge (Christian Bayle, Alain Peyrat et moi-même) ont décidé de... partir avec le code, et de renommer le projet de développement et de maintenance de ce code libre.

Le résultat s'appelle FusionForge, et il est hébergé sur FusionForge.org. Nous avons plein d'idées, mais un des buts majeurs (qui a justifié le nom) est que nous allons chercher à réintégrer dans le code commun des fonctionnalités qui ont été développées localement par des utilisateurs mais non publiées. Ça tombe bien, nous sommes déjà en relation avec plusieurs de ces utilisateurs institutionnels qui semblent intéressés par cette convergence.

Il y a déjà eu plusieurs billets publiés ici et là au sujet du récent problème de sécurité portant sur OpenSSL sous Debian, mais certains (notamment que j'ai lus sur Planet Libre) contiennent des infos erronées qui donnent une illusion de sécurité. Donc, je me permets un résumé/rectificatif. Attention, c'est important, et il ne suffit pas de mettre à jour les distributions pour se retrouver en sécurité.

Le cœur du problème : pour des raisons tout-à-fait légitimes, et suite à une mauvaise communication avec les auteurs amont d'OpenSSL, les versions d'OpenSSL distribuées par Debian (et toutes ses dérivées : Ubuntu, Mepis, Linspire, Knoppix, etc.) utilisaient un générateur de nombres pseudo-aléatoires (pseudo-random number generator, que l'usage abrège en PRNG, et qu'un abus de langage abrège encore plus en RNG) absolument pas aléatoire, du genre de celui-ci en à peine mieux. On peut chercher des responsables pour les mener au bûcher, on peut essayer de faire en sorte que ça ne se reproduise pas, ou on peut essayer de corriger les effets néfastes. La première option ne m'intéresse pas, la deuxième a déjà été traitée par des gens bien (Linux Weekly News par exemple), je me concentrerai aujourd'hui sur la troisième.

Je ne vais pas vous faire un cours de sécurité informatique, mais une grande partie de cette sécurité repose sur de la cryptographie. Or, la cryptographie repose souvent sur des secrets, que le méchant adversaire pirate terroriste ne doit pas pouvoir deviner. En général, ces secrets sont générés aléatoirement. Par un RNG. Donc quand le RNG renvoie des résultats prévisibles, ça casse pas mal de choses.

Concrètement, le RNG d'OpenSSL était utilisé par un certain nombre d'applications. Je ne vous parlerai ici que des deux trucs les plus courants, je vous laisse lire le reste sur le wiki de Debian.

Premièrement, la génération de clefs. Toutes les clefs SSH et SSL générées sur un système Debian ou apparenté au cours des deux dernières années sont à jeter. Parce que le RNG étant ce qu'il est, ces clefs sont en nombre très réduit, et qu'il est très facile de les générer toutes, y compris les clefs secrètes. La liste de ces clefs faibles est déjà plus ou moins connue, et les paquets OpenSSH de Debian et Ubuntu l'intègrent déjà sous forme de liste noire pour refuser les accès. Et il existe un script qui permet de vérifier si une clef fait partie de cette liste, le fameux dowkd.pl.

Deuxièmement, l'utilisation de l'authentification par clef pour SSH. Les clefs de type DSA (ou DSS, c'est vaguement synonyme) sont souvent utilisées pour établir des connexions SSH sans mot de passe. Manque de bol, l'utilisation du protocole DSA a intrinsèquement besoin d'un bon RNG pour protéger la clef secrète (cf. l'explication mathématique). Je répète : quelle que soit la clef DSA, même vraiment aléatoire, quelle que soit sa date de création, elle n'est protégée dans une transaction que par un nombre aléatoire. Le simple fait de s'en servir sur une machine où le RNG est faible rend trivial l'accès à la clef secrète, autant pour l'autre bout de la connexion que pour n'importe qui sur le chemin. Donc toutes les clefs DSA sont à considérer comme compromises dès le moment où elles ont été utilisées sur une machine affectée par le bug. Malheureusement, il n'est pas possible d'établir une liste de ces clefs.

Voilà pour les effets. C'est assez dévastateur, il convient donc de prendre les mesures appropriées.

Pour les sites HTTPS : les vieilles clefs RSA (plus de deux ans) ne sont pas affectées. Les clefs RSA plus récentes doivent être remplacées, de même que toutes les clefs DSA. Pour vérifier votre site, cherchez l'algorithme de signature des certificats dans les « détails du certificat » (que votre navigateur doit vous afficher sur demande).

Pour les clefs SSH : pareil, les vieilles clefs RSA ne sont pas affectées (mais je vous encourage quand même à les remplacer, ne serait-ce que pour faire du ménage). Les clefs RSA plus récentes doivent être remplacées, de même que toutes les clefs DSA. Pour vérifier le type de votre clef, regardez la partie publique (le fichier blabla.pub). S'il commence par ssh-dss ou ssh-dsa, poubelle. Il est recommandé de créer les nouvelles clefs au format RSA. Ça s'applique autant aux clefs des clients qu'à celles du serveur (celles de /etc/ssh/ssh_host_*). Bien entendu, il ne suffit pas de générer des nouvelles clefs, il faut aussi bloquer les anciennes : c'est une excellente occasion pour faire le tour de tous les fichiers authorized_keys et y faire du ménage. Le plus simple est d'y virer toutes les lignes qui commencent par ssh-dss ou ssh-dsa, voire carrément toutes les lignes tout court, et d'utiliser ssh-copy-id pour remettre la bonne clef publique (la nouvelle, en RSA) dedans.

Note : étant donné la proportion potentiellement énorme de clefs compromises parmi les clefs DSA même « fortes », plusieurs organisations ont choisi de refuser pour l'instant toutes les clefs DSA. En particulier les machines *.debian.org, notamment Alioth, mais aussi d'autres instances de GForge.

Je me permets de me répéter : beaucoup de clefs DSA, même si elles ne sont pas dans la liste noire, sont compromises, quoi qu'en disent dowkd.pl et ssh-vulnkey et consorts. Il suffit qu'elles aient été, à un moment donné, utilisées sur une machine Debian ou assimilé (et ça fait du monde). Il est donc vital de désactiver ces clefs. Le plus direct est de régénérer une clef RSA (pour ne pas risquer qu'elle soit compromise par la suite), après avoir mis à jour vos systèmes bien entendu, et de faire un grand ménage de printemps dans les authorized_keys.

Attention, je n'ai ici parlé que de SSH et HTTPS, mais ça a un impact sur beaucoup d'autres services, dès qu'ils utilisent SSL d'une manière ou une autre. GnuPG n'est pas affecté, mais les serveurs POPS, IMAPS, les VPN etc. sont à vérifier aussi. Le wiki Debian contient des instructions détaillées.

Voilà. Il n'y a pas lieu de paniquer, mais il faut quand même se bouger pour rétablir une situation normale, et ne pas garder une illusion de sécurité.

Autant pour ne pas oublier que pour en faire profiter les amis, voici une méthode rapide pour mettre en place l'IPv6 par la méthode de transition 6to4 sur une machine Linux.

Pré-requis : un ordinateur sous un noyau Linux un peu récent (pas d'inquiétude, ça marche même avec une Debian stable, que les mauvaises langues se plaisent pourtant à qualifier d'obsolète dès sa sortie). Avec une adresse IPv4 publique fixe.

Première étape : ajouter ce qui va bien dans le fichier /etc/network/interfaces. Pour pas s'embêter, on prend le script suivant qu'on appelle avec ./6to4.sh <adressev4>, et on copicolle le résultat.

#! /bin/sh
set -e

ip4=$1
echo "$ip4" | grep -q '^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*$' || \
{ echo 'Syntax: $0 a.b.c.d'; exit 1; }

ip6=$(printf '2002:%02x%02x:%02x%02x::1' $(echo $ip4 | sed 's/\./ /g'))

sed s/IP6/$ip6/ << EOF
auto sit0
iface sit0 inet6 static
      address IP6
      netmask 64
      gateway ::192.88.99.1
EOF

Deuxième étape : activer cette interface, avec ifup sit0. Pouf, on a de l'IPv6.

Troisième étape, optionnelle : configurer un firewall pour cette interface (attention, c'est avec ip6tables et plus avec iptables).

Quatrième étape, optionnelle aussi : configurer une zone DNS reverse sur un serveur, et faire référencer ce serveur. Ça se passe sur 6to4.nro.net, et il suffit de remplir les champs du formulaire en faisant la requête depuis la machine concernée.

...et voilà. Évidemment ce mini-HOWTO devrait n'être utile que pendant une période limitée (juste le temps que tous les FAI fournissent de l'IPv6 natif), évidemment il ne couvre pas le routage automatique pour le réseau situé derrière la machine, il ne couvre pas les configurations compliquées, mais au moins, pour le prochain serveur dédié que je prendrai, j'aurai la manipulation prête et documentée.

On entend parfois parler dans les magazines d'information de l'arrivée imminente des connexions Internet par fibre optique, utilisant différentes techniques regroupées sous le nom de "FTTH" (fiber to the home, la fibre jusqu'à la maison). Enfin, imminente... apparemment les syndics de certains immeubles commenceraient à être contactés par les opérateurs. Mais ça reste assez limité, et réservé à quelques privilégiés. Pour les autres, ceux qui habitent dans les petites villes (moins de dix millions d'habitants), ça reste assez flou et on sait ni trop comment ça marche, ni quand ça sera réellement disponible.

C'est donc avec une certaine excitation que j'ai participé à une expérimentation pilote pour le déploiement de FTTH (dans sa variante FTTH-PY, pour ceux qui connaissent). Je n'ai pas pu tester en profondeur, faute de préparation préalable (mea culpa), je ne peux donc vous livrer que mes premières impressions.

D'abord, la disponibilité du matériel : impression très favorable de ce côté-là, on peut trouver les équipements d'émission/réception en grande surface sans problème (testé dans une seule grande surface, mais je ne pense pas que le Carrefour de chez moi soit plus spécialisé qu'un autre). Pour la fibre elle-même, c'est à peine plus compliqué, mais elle est elle aussi largement disponible dans les magasins spécialisés. Le prix est également très raisonnable, et le système est probablement parmi les moins chers du marché (il entre en concurrence directe avec les réseaux floppynet).

Pour la mise en place, c'est pas encore tout-à-fait plug and play, hélas. Les contraintes de courbure de la fibre imposées par le système de modulation font que la longueur de la fibre doit être calculée au millimètre près, et ne peut donc pas être connue à l'avance. Il faut donc prendre les mesures soi-même et couper la bonne longueur de fibre. De même, les terminaux étant génériques, ils peuvent s'adapter à plusieurs dimensions de fibre, et il faut les préparer à recevoir la bonne. Il faut également effectuer le raccordement proprement dit. Ça reste très accessible (pas besoin de pince à sertir ou d'outillage particulier), et le tout peut être réglé en quelques minutes, mais on espère que la standardisation aidant ça pourra être simplifié pour les versions finales.

Arrive le gros point noir : le FTTH-PY est censé, à terme, permettre de faire transiter plusieurs types de communications, que ce soit de la voix ou de la donnée, mais pour l'instant seule la voix est réellement opérationnelle. Il n'y a malheureusement pas encore de pilotes disponibles (ni sous Linux, ni a fortiori sous Windows ou Mac OS), et il faut donc passer par des systèmes de conversion des flux de données en signal sonore plus ou moins audible. L'avantage est que ce système de modulation-démodulation (oui oui, c'est un modem) peut être réalisé intégralement en logiciel, l'inconvénient est que les logiciels existants ne sont pas encore à un niveau de stabilité suffisant pour une utilisation réelle. Et même s'ils finissent par y arriver, les prévisions sont pessimistes quant aux performances. Je n'ai donc pas réussi à établir de connexion de données sur ma fibre, j'en suis très déçu. Je ne peux donc que vous transmettre les informations que l'on m'a données, à savoir que les performances attendues pour ce qui concerne les transmissions de données sont de l'ordre de celles obtenues en RFC1149 (IPoAC) pour ce qui concerne le débit et les taux d'erreur, mais sans les problèmes de latence variable. C'est prometteur, mais encore une fois, j'ai pas testé donc je peux pas confirmer.

J'ai donc principalement testé la voix, avec des résultats plutôt positifs. C'est un peu nasillard, mais on peut aisément reconnaître la voix de son interlocuteur. Et je n'ai à aucun moment rencontré les problèmes classiques des nouvelles solutions de téléphonie, notamment VOIP : pas d'écho, absolument aucun effet Larsen, pas de micro-coupure... Également, pour autant que ce soit réellement mesurable à l'oreille (je ne dispose pas de bancs de tests sérieux pour ce genre de mesures), il semble que le temps de propagation soit raisonnablement rapide, ce qui est particulièrement appréciable pour les conversations. En revanche, le signal semble perdre en puissance avec la distance. La longueur d'un brin de fibre sera donc calculée en conséquence. Pour les communications plus longues, il faudra mettre en place des répéteurs, mais la qualité du signal s'en ressent, la voix des interlocuteurs étant pas mal altérée voire rendue méconnaissable selon les répéteurs.

Je n'ai hélas pas pu pousser mes tests au-delà, et je ne peux donc vous donner que cet aperçu très partiel.

Mon verdict : de ce que j'ai pu en voir, le FTTH-PY me semble avoir encore du chemin à faire. Les applications de voix sont actuellement bien traitées, mais la transmission de données n'en est encore qu'à ses balbutiements, et je crains que les concurrents dans la course pour le marché FTTH n'aient déjà pris une avance trop importante. Ceci dit, il peut probablement subsister sur des marchés de niche, en raison de son très faible coût de mise en place et de maintenance. À titre d'exemple, un réseau point-à-point de deux postes peut être entièrement constitué pour le prix de deux pots de yaourt et de dix mètres de fil de pêche.

Pour terminer, je voudrais remercier Philippe, qui travaille chez l'opérateur télécom, pour m'avoir proposé de (et encouragé à) participer à cette expérimentation, et sans qui ce billet n'aurait pas été écrit.

Voici quelques nouvelles de GForge en français, pour changer, parce qu'il y a visiblement un fort contingent d'utilisateurs francophones de GForge. Si le blabla ne vous intéresse pas, sautez quelques paragraphes, y'a une annonce qui peut vous intéresser.

Je m'en doutais un peu à vrai dire : je savais déjà qu'il y avait des instances de GForge en usage dans un certain nombre d'entreprises et d'administrations françaises. Je déplorais d'ailleurs que ces usages soient privés, voire secrets... On n'en entendait parler que par la bande, au détour d'une conversation. Et chacun avait ses bricolages locaux, et ses améliorations personnelles, dont personne ne profitait.

Heureusement, les différents utilisateurs francophones de GForge (de forges en général) ont fini par plus ou moins se retrouver, et des discussions ont commencé sur la liste Picolibre Forges. On s'aperçoit donc que de nombreux utilisateurs existent, qu'ils ont souvent des besoins communs, et que certains ont même déjà des solutions à apporter à certains de ces besoins. Il se pourrait bien que ces utilisateurs (et ces développeurs) se mettent à communiquer et à relancer une vraie dynamique de communauté autour de GForge (pour l'instant, il y a une poignée de développeurs, et quelques utilisateurs qui ne communiquent pas, donc j'hésite à appeler ça une communauté). Quelques-uns de ces utilisateurs et moi-même nous sommes rencontrés à la conférence Qualipso la semaine dernière, normalement nous devrions nous retrouver au salon Solutions Linux la semaine prochaine, et une réunion spéciale forges est même organisée après ça. Donc, ça prend forme.

Concrètement, ce que j'espère principalement est que les modifications de chacun seront partagées, de sorte qu'elles puissent être intégrées au cœur de GForge, et portées sur une version plus récente (puisque l'immense majorité des utilisateurs actuels sont basés sur une version 4.5.x patchée). Le « tronc » Subversion de GForge devrait donc intégrer, dans un futur que j'espère pas trop lointain, les évolutions suivantes :

• Intégration du bug-tracker Mantis : au moins deux (et vraisemblablement trois) entités ont déjà réalisé cette intégration, et j'essaie de récupérer les patches pour que tout le monde en profite. Pourquoi tout le monde se focalise sur l'intégration d'un nouveau tracker au lieu d'exploiter la flexibilité de celui de GForge pour l'étendre, ça me dépasse, mais je ne suis pas là pour juger. De même, je trouve vraiment dommage que ce développement ait été fait deux ou trois fois de manière indépendante et sans concertation. Vous avez dit gaspillage de temps humain ?

• Ajout d'un système d'intégration continue (on me dit « Maven »). Là encore, normalement ça a déjà été fait, il ne devrait plus rester qu'à publier les patches et les porter vers l'état actuel du code.

• C'est peut-être lié à l'item précédent (je manque de détails), mais on devrait aussi voir apparaître une intégration dans GForge d'un système de tests automatisés.

...et je ne doute pas que d'autres utilisateurs, qui ont eux aussi ajouté leurs propres fonctionnalités sans rien dire à personne, vont aussi se révéler au grand jour et collaborer avec la communauté (n'est-ce pas ?). Peut-être même que des gens vont remettre au goût du jour l'empaquetage RPM, abandonné depuis plusieurs années.

Histoire de ne pas être en reste, je fais ici l'annonce publique suivante : le plugin Mediawiki pour GForge est enfin publié. Ce plugin fait suite à une intégration faite « avec des contraintes de temps assez serrées » (comprendre « un peu à l'arrache ») pour un client, et à une autre intégration faite plus proprement pour un autre client. Le dépôt SVN de gforge.org contient donc présentement le code qui va bien, et la prochaine version des paquets Debian qui seront publiés fournira un nouveau paquet binaire appelé gforge-plugin-mediawiki. Je dispose également d'une version du plugin pour GForge 4.5.x, mais comme Mediawiki nécessite PHP 5, il faut également extraire de ma branche client la conversion PHP 4 → PHP 5 de GForge 4.5 (et en retirer les fonctionnalités réellement spécifiques au client), ce qui explique que ce n'est pas encore publié sur mon dépôt APT (ni déployé sur Alioth). J'y travaille, promis.

Je m'aperçois que quand je cause d'outils de suivi de version, il m'arrive de mentionner, en plus des standards (CVS, Subversion, Bazaar et les autres), le vénérable CPOLD. Et que souvent, mes interlocuteurs ne connaissent pas CPOLD. Et effectivement, ce n'est guère documenté dans la littérature et le web multimédia mondial. Je m'en vais donc vous présenter un peu cette formidable méthodologie de suivi de versions.

Pourquoi formidable ? Parce qu'elle ne souffre d'aucun des problèmes récurrents des autres outils :

• pas de format de fichier complexe et susceptible de corruption ;
• pas de conflits ;
• aucun besoin d'un serveur dédié (on peut tout mettre ensemble, prod et dev confondues) ;
• aucune limitation sur la gestion des branches ;
• une rapidité insurpassable ;
• une simplicité de mise en œuvre et d'apprentissage enfantine ;
• pas de modèle de développement imposé (centralisé, distribué, en quinconce, en hélice, toutes les variantes sont possibles) ;
• des sauvegardes facilitées ;
• etc.

Pour résumer, CPOLD, c'est la poudre verte du suivi de versions. Mais alors, comment ça marche ? Très simplement. Tout répertoire contenant des fichiers est déjà une archive CPOLD, pas besoin d'initialiser quoi que ce soit. Pas besoin non plus de « prendre la main » sur un fichier avant de l'éditer. Une seule commande à retenir, celle pour créer une nouvelle version de ce fichier :

cp fichier fichier.old

Bien entendu, le .old peut être remplacé par n'importe quel suffixe ou combinaison de suffixes, il suffit de définir une convention de nommage et de s'y tenir. On pourra ainsi avoir fichier.old.test.2, la troisième révision archivée de fichier dans une branche « test ». Ou, lorsque les contraintes sont moins marquées ou moins fortement ressenties par l'équipe de développement, on pourra être moins strict. Un « dépôt » CPOLD pourra alors se présenter sous la forme suivante :

roland@mirexpress ~/cpold-demo $ ls
fichier                    fichier.OK             fichier.old.old
fichier.1999-08-16         fichier.old            fichier.old.test-roland
fichier.2003-10-27.valide  fichier.OLD            fichier.prod
fichier.a-verifier         fichier.old.marchepas
roland@mirexpress ~/cpold-demo $

Alors évidemment, ce système présente quelques inconvénients, dus principalement à sa simplicité. Mais il reste tout-à-fait utilisable dans des environnements de production, j'en veux pour preuve le nombre d'entreprises qui ne jurent que par lui et n'en changeraient pour rien au monde. CPOLD, le premier outil de suivi de versions du monde, est sans doute aujourd'hui encore parmi les plus utilisés. Il a su s'adapter depuis les copies de bande magnétique à bande magnétique, a vécu son heure de gloire à l'époque des disquettes, et continue vaillamment son aventure (avec un potentiel décuplé) à l'heure des mémoires Flash et de l'Internet.

Bon, ceci dit, personnellement je préfère Bazaar, et je ne mentionne pas CPOLD parmi les services que je propose habituellement à mes clients (si ce n'est pour leur proposer une migration depuis CPOLD vers autre chose).

Vous êtes déjà probablement au courant vu que tout le monde en a déjà parlé, mais je vais quand même faire mon billet dessus : Free propose, depuis quelques jours, de l'IPv6 (presque) natif à ses abonnés dégroupés. Plein de sites ont repris l'annonce, je vais pas la copicoller une énième fois, mais je vais apporter quelques détails.

D'abord, comment on le fait marcher ? Dans le cas de monsieur tout-le-monde, il suffit de cliquer sur l'interface de gestion de l'abonnement et de rebooter la Freebox. Si un ordinateur classique est branché dessus, il se verra attribuer une adresse IPv6 (et même plusieurs) en plus de l'adresse IPv4 habituelle. Pouf, un monde nouveau s'ouvre à lui.

Mais, la question que tout le monde pose, à quoi ça sert ? Principalement à affecter à chacun des ordinateurs branchés sur la Freebox une adresse distincte. Beaucoup pensent encore qu'il s'agit d'un gadget qui ne sert à rien sinon à quelques geeks, et que ça n'a aucun intérêt pour madame Michu. Et du coup, ils dénigrent à tout va, et refusent d'en entendre parler. C'est bien dommage, pour plusieurs raisons.

D'abord, parce que ne l'oublions pas, ce sont les geeks qui font marcher le monde, pas les marchands de lessive ou les faiseurs d'opinion. Pas de geeks dans les années 70, pas d'informatique dans les années 80. Pas de geeks dans les années 90, pas d'Internet dans les années 2000. Donc quand les geeks disent que certaines choses sont importantes, il est souvent utile de les écouter. Expliquons donc en quoi IPv6 c'est important.

Pour Cécile Berteau, internaute dite moyenne, ça va changer quoi ? Ça dépend. Si elle vit seule et ne se sert de son unique ordinateur que comme d'un Minitel à images, probablement pas grand-chose. Mais sinon, ça peut changer pas mal de trucs. Premièrement, en IPv6 chaque ordinateur a une adresse différente, même « vu de l'extérieur ». Donc son ordinateur, celui de son fils et celui de son mari auront chacun leur adresse. Les connexions réseau initiées par ces trois ordinateurs seront donc facilement identifiables, et ne nécessiteront plus de phase de traduction d'adresse comme à l'heure actuelle (où, vus de l'extérieur, les trois ordinateurs semblent avoir la même adresse). Cette traduction d'adresse réseau ne pose pas trop de problèmes tant qu'on parle de connexions sortantes, puisque c'est la « box » qui s'en occupe et qu'elle sait faire ce qui va bien ; pour les connexions entrantes, c'est nettement plus complexe à mettre en place, puisqu'il faut configurer manuellement la box, et lui dire vers quel ordinateur envoyer les connexions entrantes, en fonction du type de ces connexions. Et bien entendu, un type de connexion sera toujours envoyé au même ordinateur. Pas question donc pour Cécile de se faire appeler en voix sur IP, puisque les connexions de ce type sont envoyées sur l'ordinateur de son fils (qui a aussi annexé les ports correspondant au partage de fichiers, pour publier les enregistrements de son groupe de rock). Ce problème disparaît en IPv6.

Plus précisément, la solution au problème est grandement simplifiée. Parce que même en IPv4 il existe toute une panoplie de bricolages qui font en sorte que ce problème reste gérable. Par exemple pour la voix sur IP, on peut préétablir des connexions sortantes, qui sont maintenues uniquement pour être capables de recevoir des appels. Mais ça ne peut marcher que si les appels passent par un point central, ce qui n'est pas toujours le cas. Et même quand ça l'est, ça ajoute de la complexité et des temps de transport sur le réseau. Si les appels de Kevin Berteau à sa copine du lycée (qui habite à trois rues de là) passent par un serveur aux États-Unis ou à Amsterdam, ça veut dire qu'il y a un délai supplémentaire (et de la charge réseau inutile, mais ça, Kevin s'en moque). Or le délai, en téléphonie, ça cause de l'écho et de l'effet casserole, et c'est un vrai problème concret. Si la connexion va directement de chez les Berteau à chez Cynthia, Kevin pourra dire ses mots doux à sa chérie dans de bonnes conditions. Parce que les deux amoureux ont chacun leur ordinateur qui discutent directement, sans passer par une fibre optique transatlantique surchargée parce que la transpacifique a été coupée par un cargo ou une pelleteuse (ça arrive régulièrement).

Le fait que chaque ordinateur ait sa propre adresse facilite aussi le filtrage des trafics, bien entendu. Si Kevin s'initie à la réalisation de sites web, et qu'il veut mettre un serveur sur son ordinateur, il pourra rendre ce serveur accessible depuis l'extérieur, puisque les connexions entrantes à sa destination sont facilement détectables. A contrario, les connexions vers les Windows des parents seront bien entendu bloquées, pour éviter qu'ils ne se retrouvent infestés de virus. Et les connexions en voix sur IP de Cécile qui appelle sa meilleure amie resteront prioritaires sur la page web du groupe de Kevin. Parce qu'un quart de seconde de retard, c'est à peine perceptible sur une page web, mais ça empêche une conversation téléphonique, donc il faut pouvoir prioriser les trafics selon leur type, donc les identifier facilement.

Je pourrais aussi vous parler de chiffrement et d'authentification de trafic réseau, de fracture numérique entre les pays qui ont des milliards d'adresses IP réservées et ceux qui n'en ont que quelques milliers (ou centaines !), de simplification des mécanismes de routage, de configuration automatique, et de plein d'autres choses vachement importantes mais qui n'ont pas un impact aussi direct sur le fameux « internaute lambda », mais d'autres le font mieux que moi et ce n'est pas le sujet. Je cherche aujourd'hui à expliquer que non, il ne s'agit pas uniquement d'une lubie de geeks, en montrant du doigt quelques problèmes concrets qui existent maintenant et qu'IPv6 permet de résoudre. Gardez à l'esprit que les nouvelles applications dépendent de plus en plus d'un réseau simple, fiable et rapide, et que ces conditions sont de plus en plus complexes à réunir avec IPv4. Surtout si on commence à voir se répandre l'Internet mobile (tiens, encore un truc qui va consommer plein d'adresses supplémentaires).

Alors maintenant, pourquoi cela a tant traîné ? Pourquoi ça continue à tant traîner, d'ailleurs, à part chez quelques fournisseurs d'accès ? Je pense qu'il y a plusieurs facteurs, mais aucun ne me satisfait. « Chez moi ça marche », certes, mais quid des pays émergents (je pense à la Chine et l'Inde, qui vont très bientôt être d'énormes consommateurs d'adresses IP, mais les autres pays ne doivent pas être oubliés) ? Lorsqu'ils seront en IPv6 (obligés, puisqu'il n'y aura bientôt plus de nouvelles adresses IPv4 à leur affecter), devrons-nous rester dans notre confortable cocon IPv4 ? « On trouvera des solutions », comme on en a déjà trouvé. Des bricolages à base de traduction d'adresses, probablement. Peut-être même à plusieurs niveaux. Avec, à chaque niveau supplémentaire, une complexité de mise en place et de maintenance qui augmente les coûts et diminue la fiabilité. « On a encore le temps » et « ça fait des années qu'on nous annonce qu'on va manquer d'adresses et y'en a encore plein », ça me semble irresponsable. Je suis ahuri de constater que les catastrophes annoncées suffisamment à l'avance ne sont pas prises au sérieux par les décideurs. Enfin, « pourquoi se compliquer la vie avec ça ? », ça me fait doucement rigoler (doux-amer, quand même), puisqu'au contraire ça simplifie la vie de tout le monde. Après une phase de migration, certes, mais elle devient elle-même plus complexe au fil du temps. Et « y'a pas de demande », c'est à la limite du malhonnête... La demande, c'est de l'Internet qui marche, dans un sens ou dans l'autre. Effectivement, quand on essaie d'expliquer à madame Michu que IPv6, c'est 128 bits d'adressage, c'est des facilités pour le filtrage, c'est du routage automatique, c'est des tas de choses qu'elle ne comprend pas, elle ne voit pas l'intérêt et a une réaction de rejet, parce que pour l'instant ça marche alors ne touchez à rien. Mais si on lui expliquait IPv4, ça lui ferait peur exactement autant, il me semble. Je me vois mal lui expliquer la traduction d'adresse, par exemple. Donc je ne pense pas que l'argument pèse en faveur de la stagnation ; bien au contraire, puisque ça aura tendance à simplifier les choses.

Voilà. Une fois ces choses dites, je me réjouis que le mouvement semble engagé, et j'espère que cela pourra servir d'impulsion pour d'autres fournisseurs d'accès et de services réseau. J'espère aussi que ces quelques explications auront pu débouter l'idée reçue qu'IPv6 ne sert à rien. Et si vous n'avez pas tout suivi, faites-moi confiance, je suis un geek (et vous pouvez bien utiliser la lessive que vous voulez, ça ne me fait ni chaud ni froid).