The trashiest blog in the World...

En mars 2008, eponyme nous annonçait l'arrivée sur les canaux IRC francophones de Fedora d'un bot programmé par ses soins : trustyRC.

Voilà donc un peu plus de deux ans maintenant que trustyRC faisait son travail, répondant inlassablement aux requêtes des utilisateurs sur la documentation francophone, sur le FAS (Fedora Account System), ...

Mais la fatigue l'a malheureusement gagné. eponyme s'est tourné vers d'autres horizons, et deux problèmes principaux persistaient avec trustyRC :

• les données du FAS devaient être mises à jour à la main ; ce qui n'est fait que très rarement (il faut y penser et en avoir le courage, on connaît tous ça !),
• la recherche sur la documentation francophone de Fedora ne faisait qu'interroger le MediaWiki et récupérer un résultat HTML. Or, chacun sait que la recherche MediaWiki de base est entravée de limitations pour le moins étranges, et n'est simplement pas fonctionnelle. Les résultats ne sont en conséquence souvent pas à la hauteur de nos espérances ; ce n'est cependant pas la faute de trustyRC, le pauvre.

Depuis peu, je m'intéresse de très près à Apache Solr (une solution de recherche web basée sur le projet Lucene) ; j'ai même très récemment ajouté l'extension php-pecl-solr dans les dépôts Fedora.

Je me suis donc fixé comme but d'indexer le wiki de la documentation francophone ; puisque je connais assez bien les données et certaines recherches effectuées régulièrement (notamment sur IRC) ; c'était un bon point de comparaison pour moi.
Le résultat est assez impressionnant, la puissance de recherche de Solr n'est en rien comparable à celle d'une « simple » application PHP. comme MediaWiki Solr permet, entre autres, la suppression des caractères accentués, la mise en minuscule des caractères, le découpage de termes, le sur-lignage, le filtrage, ... Pour exemple, une recherche sur les termes réseau, reseau et network renvoie - pour l'index sur lequel j'ai travaillé - les mêmes résultats.

Afin de pouvoir tester ce système d'indexation et de recherche un peu plus avant, il me fallait une interface d'interrogation publique. Je me suis dit que ce serait une bonne occasion de refaire quelques tests de bots IRC. J'ai choisi de ne pas contribuer à trustyRC principalement car je n'ai pas les compétences requises. Au lieu de cela, j'ai cherché et testé les bots existants en python ; j'en ai trouvé plusieurs, mais seul Supybot m'a réellement satisfait (en fait, c'était le seul à ne pas subir de déconnexions très régulières du réseau FreeNode ).

Le résultat ? Un plugin Supybot pour la documentation francophone, connecté sur les canaux francophones Fedora sous le doux nom de MrBot !

Les plugins externes chargés dans cette instance de Supybot sont :

• le plugin de recherche dans le wiki fedora-fr (développé par votre serviteur, les sources sont disponibles sous licence BSD),
• un plugin de validation (X)HTML pour m'amuser (également développé par votre serviteur, sur la base du plugin de validation de Phenny, dont les sources sont également disponibles sous licence BSD),
• le plugin Fedora qui permet d'interroger les FAS et savoir, par exemple, qui maintient un paquet spécifique,
• le plugin Koji qui nous donne quelques informations sur les builders Koji de Fedora,
• le plugin Bugzilla qui affiche des détails sur une entrée du bugzilla de Fedora lorsqu'un lien valide est posté (ou une chaîne de la forme bug #{numéro de bogue}).

L'utilisation de MrBot pour la recherche wiki se fait de la façon suivante :

• .wiki ce que je cherche : effectue une recherche dans les titres du wiki. Si aucun résultat n'est trouvé, une recherche dans les textes sera effectuée automatiquement,
• .wiki plain ce que je cherche : effectue une recherche dans les textes uniquement,
• .wiki solr {requête solr} : permet d'interroger l'index avec une requête Solr (principalement implémenté pour mes tests).

L'interrogation via la commande wiki renverra au maximum deux URL ; le nombre de résultats non renvoyés sera également spécifié entre parenthèses.

Vous remarquerez que le caractère d'interrogation est désormais le . (point) ; alors que trustyRC répondait à un ! (point d'exclamation). Pourquoi ce changement ? Parce que j'en avais envie, na !
Toute plaisanterie mise à part ; un bot Supybot est déjà présent sur certains canaux Fedora anglophones - zodbot sur #fedora-devel par exemple - qui répond au . ; l'utilisation du même caractère permet simplement un peu d'harmonie.

Pour la majorité des fonctions, il est également possible d'interroger MrBot en message privé :

• /msg MrBot wiki ce que je cherche

Pour vérifier qu'une URL donnée est valide W3C :

• .validate blog.ulysses.fr
• .validate http://blog.ulysses.fr

L'interrogation des services Fedora :

• .whoowns paquet : renvoie le nom (FAS) du mainteneur du paquet
• .fas fasname : renvoie des informations sur le compte FAS d'un utilisateur. Vous devriez probablement utiliser cette commande en message privé plutôt que sur un canal.
• .branches paquet : renvoie la liste des branches actives pour le paquet spécifié
• .what paquet : renvoie une description courte du paquet
• .list Fedora : affiche la liste des commandes disponibles pour le plugin Fedora

Ces temps-ci, je m'intéresse de très près à Apache Solr (notamment pour le travail).

Solr représente grosso modo la partie serveur du bien connu Apache Lucene (qui est lui même un système d'indexation et de recherche avancé écrit en Java).

Solr est un outil sous forme de servlet Java qui vous permet d'indexer des documents et de faire des recherches via une API web (REST), il propose de nombreuses fonctionnalités. En outre, il rend l'accès et la configuration d'index Lucene plus simple (via notamment des fichiers de configuration XML).

Solr est un outil open Source très actif, et utilisé à de nombreux endroits. Des plugins de recherche basés sur Solr existent notamment pour Drupal et eZ Publish.

Il existe aussi une extension PHP PECL pour Solr qui vous permet d'utiliser une instance de Solr depuis un script PHP5. Cette extension n'est pas disponible dans les dépôts officiels de Fedora, c'est pourquoi j'ai rapidement créé un RPM qui la fournit (afin de pouvoir tester ses possibilités depuis quelques applications personnelles).

Le paquet est disponible ici :
http://odysseus.x-tnd.be/fedora/php-pecl-solr/

Ce paquet a été construit sous Fedora 12 en 64 bits, avec la version de PHP fournie pour cette plate forme sur le dépôt de Remi. J'envisage de proposer ce paquet en revue pour les dépôts officiels, mais seulement si je l'utilise (pour le moment, je teste, on verra après :p).

J'espère que ce paquet pourra être utile à certains

La version 9.1 de l'excellent logiciel éducatif GCompris est disponible dans le dépôt "updates-testing" pour Fedora 11 et 12.

Cette version corrige de nombreux bogues présents dans la version 9.0 ; je vous invite à l'installer, à le tester, à le noter dans bodhi (pour Fedora 12 et pour Fedora 11), et à reporter les éventuels problèmes, améliorations ou autres

Pour l'installer :

$ su -lc 'yum --enablerepo=updates-testing install gcompris gcompris-sound-fr'

Pour la mise à jour, remplacez « install » par « update » dans la précédente commande. Les sons sont disponibles dans plus de 20 langues, si vous voulez entendre autre chose que du français.

Pour les besoins de mon travail, j'avais dû, il y a plus d'un an, mettre en place un système de virtualisation sur l'un de nos serveurs (qui tourne sous CentOS 5).

Je m'étais à l'époque tourné vers VMWare server, qui a rempli son office jusqu'ici. Seulement voilà, le module noyau refuse de se compiler aujourd'hui, et je trouve que le client graphique laisse fort à désirer : les touches du clavier ne sont pas mappées correctement, nous avons régulièrement des gels (voire des plantages !) du serveur Xorg sur les postes clients lorsque nous l'utilisons, .... Si nous n'avions virtualisé que des systèmes Linux, cela ne poserait pas vraiment de problèmes, mais ce n'est malheureusement pas le cas.

Aujourd'hui, KVM est disponible sous CentOS, je me suis donc attelé à son installation et à sa configuration. Comme d'habitude, un petit yum install suffit, pas de soucis notables de ce côté là. Restait à migrer les machines virtuelles existantes sous VMWare vers KVM.

Nous avons trois machines virtuelles qu'il fallait migrer :

• une Mandriva Corporate Server 4 en 32 bits
• une CentOS 5 en 64 bits
• un Windows XP en 64 bits

La solution réside en l'utilisation de virt-convert qui prend en entrée le dossier de la VM VMWare, et qui ressort une image et un fichier de configuration pour libvirt. La syntaxe est la suivante :

# virt-convert /var/lib/vmware/Virtual\ Machines/CentOS5 /home/vms/CentOS5

Lancée telle quelle, cette commande faisait plus ou moins son travail : j'avais bien le fichier de configuration XML et un disque au format RAW, mais ce disque était vide !
Je ne sais pas trop si c'est dû à l'utilisation de fichiers successifs de 2Go pour le disque, ou encore à l'allocation dynamique de l'espace ; toujours est-il que virt-convert ne parvenait pas à s'y retrouver.

Fort heureusement, VMWare fournit la commande vmware-vdiskmanager qui m'a permis de solutionner mon problème :

# cd /var/lib/vmware/Virtual\ Machines/CentOS5
# vmware-vdiskmanager -r CentOS5.vmdk -t 0 CentOS5-copy.vmdk
Creating disk 'CentOS5-copy.vmdk'
  Convert: 49% done.

Une fois la conversion du disque terminée, recréons un dossier qui contiendra les données que l'on va migrer :

# cd /var/lib/vmware/Virtual\ Machines
# mkdir mig_CentOS5
# mv CentOS5/CentOS5-copy.vmdk mig_CentOS5/CentOS5.vmdk
# cp -av CentOS5/CentOS5.vmx* mig_CentOS5/

Nous obtenons ainsi le dossier /var/lib/vmware/Virtual\ Machines/mig_CentOS5 que nous allons pouvoir migrer avec virt-convert :

# virt-convert -o virt-image /var/lib/vmware/Virtual\ Machines/mig_CentOS5 /home/vms/CentOS5
Generating output in 'virt-image' format to /home/vms/CentOS5
Converting disk 'CentOS5.vmdk' to type raw...
Converting disk '/dev/hda' to type raw...
Done.

Super, on a désormais une machine virtuelle utilisable Le dossier /var/lib/vmware/Virtual\ Machines/mig_CentOS5 n'est plus utile, on peut le supprimer sans état d'âme aucun.

Reste un petit point de détail : la référencer dans votre système. La commande virsh permet cela normalement, mais le fichier XML généré par virt-convert ne lui plaira pas. Utilisons donc la commande virt-image de la façon suivante :

virt-image /home/vms/CentOS5/CentOS5.virt-image.xml

Si tout s'est passé comme escompté, cette commande va ajouter la nouvelle machine virtuelle, que vous pourrez alors utiliser comme d'habitude.

Dans la théorie, tout cela est bien beau ; mais dans la pratique il en est autrement :

• la machine CentOS : pas de problème au démarrage, mais l'interface graphique n'a pas réussi à se charger en raison du changement « matériel » de carte graphique. Quelques adaptations dans le xorg.conf ont suffit à corriger le problème, rendant la machine virtuelle à nouveau pleinement opérationnelle.
• la machine Mandriva : kernel panic au lancement Il est possible qu'en jouant avec les options du noyau je parvienne à la lancer à nouveau, je n'ai cependant pas eu de temps à y consacrer pour le moment.
• la machine Windows : écran bleu. reboot. écran bleu. reboot. En mode normal ou en mode sans échec, ce ne serait pas rigolo sinon ! Bon, celle là ; je crois qu'il va falloir la réinstaller, je ne vois aucune solution...

Conclusion : un taux de réussite de 33%, c'est mieux que rien ; mais on peut en déduire que la migration de machine virtuelles n'est malheureusement pas une science exacte.

Il y a quelque temps, je vous parlais ici même de l'empaquetage de tuxmath, un logiciel éducatif.

Grâce aux conseils de Bouska, j'avais décidé de proposer l'inclusion de tuxmath aux dépôts officiels de Fedora, la revue a été acceptée, le paquet envoyé sur le CVS et les builds lancés

Côté tuxtype, j'ai proposé un patch correctif pour la mise à jour vers la dernière version, ainsi que pour respecter les règles inhérentes aux polices de caractères fournies directement par les logiciels. J'ai également (à l'instant) demandé à être co-mainteneur de ce paquet. Wait and see

tuxmath devrait arriver dans les dépôts sous peu, en updates-testing dans un premier temps, puis assez rapidement en stable si quelques personnes font des retours de tests positifs.

Une brève discussion sur IRC hier soir m'a fait découvrir un logiciel éducatif que je ne connaissais pas encore sous Linux : TuxMath.

Je me suis également rendu compte que ce programme n'était pas empaqueté pour Fedora, et que son équivalent pour le clavier, TuxType, datait de l'an dernier...

Bref, je me suis dit que de mettre à jour TuxType et d'intégrer TuxMath dans les dépôts officiels serait une bonne idée. En cherchant quelque peu sur le bugzilla, j'ai vu un bogue encore ouvert pour TuxType : https://bugzilla.redhat.com/show_bug.cgi?id=477472
Ce bogue concerne l'inclusion de fichiers de polices de caractères dans les paquets ; mais je ne sais pas comment le corriger... Du coup, je ne souhaite pas m'occuper moi-même de la mise à jour de TuxType, ni de la demande d'intégration de TuxMath dans les dépôts officiels.

En revanche, je voulais essayer ces deux programmes sur ma Fedora, je les ai donc construits et mis à disposition sur mon dépôt personnel. Les paquets sont disponibles pour Fedora 9 et 10 en i386 et en x86_64. Pour installer le dépôt :

# rpm -ivh http://rpms.ulysses.fr/fc10/x86_64/trashy-release-fc10-1.noarch.rpm

Pour Fedora 9, utiliser l'URL : http://rpms.ulysses.fr/fc9/x86_64/trashy-release-fc9-1.noarch.rpm

Pour installer les deux programmes :

# yum --enablerepo=trashy install tuxtype2 tuxmath

J'ai installé ces deux programmes sur l'ordinateur de mon épouse afin qu'elle puisse les tester, et elle est actuellement en train de se prendre la tête sur TuxMath

Les paquets ont été uniquement testés sous Fedora 10 en x86_64, je n'ai as d'autre version sous la main...

Amusez-vous bien !

Depuis l'annonce officielle de la sortie de la version 3 d'OpenOffice, je m'étais dit qu'il serait bien de la tester...

Je n'en avais pas encore eu le temps, ni le courage cependant

C'est désormais chose faite, et, pour l'occasion, j'ai reconstruit les RPM disponibles pour la future Fedora 10. Le travail ne fût pas très compliqué, mais relativement long, le temps de reconstruire les quelques dépendances manquantes dans F9 et de recompiler OOo (plus de 5 heures de travail sur mon pc pour la seule version x86_64... Plus de 10 heures pour la version i386, l'autre pc étant sensiblement moins rapide).

Le résultat pour la version 64bits : 96 paquets pour un total de 1,3Go !

Comme il aurait été dommage de ne pas en faire bénéficier la communauté, j'ai mis en place rapidement un dépôt pour Fedora 9 (i386 et x86_64) qui contient pour le moment tous les paquets OpenOffice.org 3 ainsi que les dépendances manquantes sous F9.

Pour l'installer :

rpm -ivh http://rpms.ulysses.fr/fc9/x86_64/trashy-release-fc9-1.noarch.rpm

• Les paquets x86_64 : http://rpms.ulysses.fr/fc9/x86_64/
• les paquets i386 : http://rpms.ulysses.fr/fc9/i386/
• les SRPM : http://rpms.ulysses.fr/SRPMS

Ensuite, vous pourrez utilisez yum pour mettre à jour et/ou installer ces nouveaux paquets (notez que le dépôt est désactivé par défaut) :

yum --enablerepo=trashy update openoffice\*

Ces paquets ne sont fournis qu'à des fins de tests, aucune maintenance ne sera effectuée, je ne prévois pas non plus pour le moment de mise à jour (au vu du temps que ça prend pour recompiler le tout, je suis certain que vous me comprendrez :-D).

Le seul moyen d'avoir une version 3 d'OpenOffice installée et maintenue sur votre Fedora sera d'installer Fedora 10 dès sa sortie !

Joyeux anniversaire !

Après le succès du passage de Fedora 7 vers Fedora 9 via preupgrade sur mon ordinateur portable, je me suis décidé à faire subir le même sort à mon ordinateur de bureau, qui lui était équipé d'une Fedora 8 en x86_64.

Je dois malheureusement avouer que cette mise à jour ne s'est pas aussi bien passé que la première, loin s'en faut. Je suis assez surpris, puisque la migration vers une Fedora n+2 n'est pas très conseillée...

Jour J, démarrage de ma Fedora 8. Pour gagner un peu de temps, et alléger la mise à jour, je supprime des paquets dont je n'ai pas besoin (les jeux, etc...), je sauvegarde mes bases de données (mysql, postgres) et lance preupgrade.

La première fois, l'application cherche les paquets à mettre à jour, les télécharge... Puis bloque sur la récupération de l'image de boot Bon, soit. On ferme, et on recommence... Le second test fût plus rapide, tous les paquets ayant déjà été téléchargés.

À la fin de l'opération, il m'est proposé de redémarrer, ce que je fais avec plaisir. Mais voilà... Lors de la vérification des paquets, Anaconda me dit qu'un paquet, gnome-panel-libs pour ne pas le citer, et soit manquant soit corrompu. Il semble essayer de le télécharger, mais sans succès. Le « souci », c'est que pendant ses tentatives de téléchargement, on ne peut pas savoir quel est le paquet incriminé (vous comprendrez le problème dans la suite de ce billet).

Retour à la case départ. Je relance preupgrade, reboot et... Même combat Retour sous Fedora 8, où un yum remove gnome-panel m'annonce 30 dépendances seulement (je m'étais attendu à beaucoup plus). Je prends soin de noter ces dépendances désinstallées dans un coin, supprime gnome-panel et tente ma chance à nouveau.
Devinez ? Même résultat. Mais sur un autre paquet, nas-libs cette fois. Seulement voilà, je m'aperçois qu'anaconda me parle de nas-libs en .i386 ! Un petit ctrl+alt+f2 histoire de voir ce qu'une console peut raconter. Le ping fonctionne, déjà, j'ai un accès réseau. Le système principal est chrooté, je vais donc voir un peu les paquets téléchargés pour la mise à jour, et me rend compte qu'effectivement le paquet nas-libs est présent en x86_64, mais pas en i386.

Bon, faisons le point. Anaconda cherche à installer un paquet i386 qui n'existe pas et ne semble pas capable de le télécharger par ses propres moyens. Un petit wget ? Allez hop, c'est parti, je télécharge le nas-libs dans le répertoire qui va bien, je fais un ctrl+f6 pour retrouver anaconda qui continue de râler... Il n'a pas vu vu que je lui avais mis le fichier à disposition !

Reboot à nouveau, sélection de l'upgrade dans le grub et... Il cherche à nouveau à télécharger quelque chose. J'attends avec perplexité qu'il me dise ce qu'il cherche à faire cette fois (tout en appréhendant le nas-libs), la procédure est assez longue, comme je l'ai déjà dit plus haut. Cette fois, il se plaint de kdebase-workspace-libs, toujours en i386. Vérification faite, ce paquet existe lui aussi en x86_64, mais pas en i386 !!!

On recommence, encore, et encore, et encore... De mémoire, les paquets suivants ont posé ce problème :

• gnome-panel-libs
• nas-libs
• kdebase-workspace-libs
• qt-x11
• qt

J'en oublie peut-être. Je n'ai pas chronométré le temps qu'il m'a fallu pour résoudre toutes ces dépendances hasardeuses, mais ce fût long. Au final, anaconda a terminé son boulot, et la mise à jour sur Fedora 9 était faite.

Oui mais...

Bon, après la mise à jour via anaconda, je relance le système. Une fois sur ma F9 toute neuve, je lance une mise à jour (y'en avait pas mal quand même) et attends patiemment. La mise à jour se termine, sans encombre, et je décide de relancer ma machine pour profiter des dernières mises à jour avant de nettoyer un peu le tout avec package-cleanup.
Seulement, voilà, la bonne Fée Dora n'était pas à mes côtés, et le nouveau kernel installé ne semble pas me permettre de lancer mon système (il se plaint de bibliothèques manquantes pour rhgb - ce qui n'est pas trop gênant - et mount - ce qui est déjà un peu pus gênant -). Impossible de lancer le système, SELinux me dit être en train de re-étiquetter mon disque, mais j'en doute fort puisque le disque n'est monté qu'en lecture seule...

Au final, j'ai relancé mon pc sur le noyau F8, en attendant la prochaine mise à jour ou ma prochaine montée de courage...

Au final, je ne vais pas dire que je suis déçu de Fedora 9, loin de là, mais je m'attendais à rencontrer beaucoup plus de problèmes sur un préupgrade F7 -> F9 alors que ce fut l'inverse...