The trashiest blog in the World...

IIP Image server sous Fedora et RHEL/CentOS

trashy — Sun, 19 May 2013 23:47:00 +0200

Depuis un certain temps (mars 2009), je maintiens à titre totalement officieux un paquet RPM du serveur IIPImage dans mon dépôt personnel.

J'ai récemment décidé de l'intégrer dans les dépôts officiels, le but de mon dépôt n'étant pas de fournir des paquets sur le long terme, mais davantage de me servir d'incubateur en quelque sorte.... J'ai donc soumis une revue sur le Bugzilla.

Grâce aux conseils toujours très avisés de Remi sur cette revue, j'ai fait évoluer le paquet, apportant certaines modifications qui ne sont pas dénuées d'intérêt :

le paquet ne dépend plus de apache HTTPD, ceux d'entre vous qui utilisent d'autres serveurs web peuvent donc installer le paquet sans dépendances disons... farfelues
une unité Systemd qui permet d'exécuter le serveur seul, sur un port spécifié. Le service n'est disponible que sous Fedora 18 actuellement.

Les paquets nécessaires sont disponibles via mon dépôt pour les versions 17 et 18 de Fedora, ainsi pour les versions 5 et 6 de RedHat (et équivalents). Une fois la revue menée à bien, les paquets seront disponibles sur les dépôts officiels et seront supprimés de mon dépôt personnel.

Si vous souhaitez utiliser Apache HTTPD et mod_fcgid avec le serveur IIP, installez dans un premier temps les paquets adéquats :

$ su -lc 'yum --enablerepo=trashy install iipsrv-httpd-fcgi'

Vous trouverez dans le dossier /etc/httpd/conf.d un fichier nommé iipsrv.conf, dont vous pouvez vous inspirer pour votre configuration spécifique. C'est à peu près aussi simple que ça ; votre serveur IIP est désormais installé. Pour vérifier son fonctionnement de base, rendez vous à l'adresse http://localhost/iipsrv (ou celle que vous aurez configurée) ; vous devriez voir une simple page avec le nom du logiciel, sa version, un lien vers son site web et le nom de l'auteur.

Il semble qu'il ne soit actuellement pas possible de fournir de façon correcte des fichiers de configuration pour les autres serveurs, aussi, si vous souhaitez utiliser le serveur IIP avec un autre serveur web, ou directement en tant que service, installez uniquement le paquet iiprsv ;

$ su -lc 'yum --enablerepo=trashy install iipsrv'

Référez-vous ensuite à la documentation du serveur IIP ainsi qu'à celle de votre serveur web pour paramétrer tout ça correctement.

Si vous souhaitez utiliser le service, notez que l'adresse IP et le port sont configurables via un fichier actuellement disponible dans /etc/iipsrv/iipsrv.conf, dont le contenu est le suivant :

IP=127.0.0.1
PORT=9002

Une fois les valeur adaptées, lancez le serveur comme vous en avez l'habitude :

$ su -lc 'systemctl start iipsrv'

Votre serveur IIP est en route !

Vous pourrez tester ça avec Apache 2.4 et mod_proxy sous Fedora 18, par exemple. Ajoutez à votre configuration la ligne suivante (en adaptant l'hôte et le port si vous avez modifié la configuration par défaut) :

ProxyPass /iipsrv fcgi://127.0.0.1:9002/

Relancez Apache, et le tour est joué. L'adresse http://localhost/iipsrv devrait vous renvoyer la page par défaut.

Notez que par défaut, SELinux ne permettra pas à Apache de se connecter à un port qu'il ne connait pas. Pour y remédier, il vous suffira d'avoir recours aux bons et loyaux services de semanage :

$ su -lc 'semanage port -a -t http_port_t -p tcp 9002'

Notez enfin que ce paquet n'est peut-être pas actuellement dans sa version finale (tant que la revue n'est pas terminée), les modifications ultérieures ne devraient cependant pas avoir trop d'impacts (j'aimerai en être absolument certain, mais ma boule de cristal est malencontreusement tombée par terre récemment, et refuse catégoriquement de fonctionner :p).

N'hésitez pas à participer à la revue, ainsi qu'au projet IIPImage !

Long time no see...

trashy — Thu, 18 Oct 2012 08:17:00 +0200

(French version below.)

It's been a long time since I could take part in a Fedora event, for many reasons (good and bad ones ;)).

Saturday, a FUDCon (Fedora Users and Developpers Conferences) took place in... Paris! That was an incredible chance to see friends I've not seen for years now, to discuss FOSS (mainly Feodra, of course :p), to listen very interesting talks, and to meet new people.

It's been a very very good week-end, Id' like to thanks all participants, See you soon!

I've also took some photos, you can see them on my Fedora FUDCon Paris 2012 photo album

Cela faisait un moment que je n'avais pu prendre part à un évènement Fedora, pour différentes raisons (bonnes ou mauvaises ;)).

Samedi, un FUDCon (Fedora Users and Developpers Conferences) se tenait à... Paris ! C'était une chance incroyable pour moi de revoir des amis que je n'avais vu depuis des années, de discuter logiciel libre (principalement Fedora, bien entendu :p), de participer à des conférences très intéressantes, et de rencontrer de nouvelles personnes.

Ça a été un excellent week-end, je voudrais remercier toutes les personnes qui ont participé. À bientôt !

J'ai également pris quelques photos, que vous pourrez voir sur mon album photo Fedora FUDCon Paris 2012.

Serveur Jabber Prosody sous Fedora

trashy — Mon, 07 May 2012 09:28:00 +0200

Il y a un peu plus de 2 ans (le 01 janvier 2010 en fait) ; je posais une demande de revue pour intégrer le serveur XMPP (Jabber) Prosody dans les dépôts officiels de Fedora.

Ce fût donc un immense plaisir que d'apprendre à l'instant l'approbation de ce paquet, et qui sera par conséquent disponible assez rapidement dans le dépôt updates-testing de votre Fedora favorite Le paquet sera aussi construit et maintenu dans le dépôt EPEL pour RHEL/CentOS/Whatever en version 6.

git-flow sous Fedora

trashy — Tue, 21 Feb 2012 09:22:00 +0100

Il y a quelques semaines, j'entendais parler de git-flow, un ensemble d'extensions Git qui aide à respecter le modèle de développement Git de Vincent Driessen ; modèle que je ne connaissais pas d'avantage. git-flow simplifie les choses pour suivre ce modèle.

À l'occasion de la sortie de la nouvelle version de Galette (pleins de nouveautés !! :-p ), et de la migration des sources du projet de Subversion vers Git ; j'ai décidé d'utiliser git-flow.

Premier constat : pas de paquet disponible dans les dépôts :'(
Un RPM de git-flow pour Fedora 16 est donc désormais disponible dans le dépôt trashy (si d'aventure quiconque aurait envie de l'intégrer dans les dépôts officiels, le fichier SPEC et le SRPM sont disponibles )

Une fois le RPM installé, la commande git flow est disponible :

 % git flow version
0.4.2-pre

L'autocomplétion des commandes Git est une aide plus qu'appréciable au quotidien, si vous souhaitez en bénéficier pour git-flow ; il vous faudra installer un script d'autocompleteion pour git-flow (bash ou zsh). Une fois le fichier correspondant à votre shell récupéré, il suffit de faire un source fichier pour que la complétion soit disponible

Bien que je n'aie encore que peu d'expérience avec cet outil, je trouve assez pratique que ce soit lui et non moi qui soit en charge de savoir quelle doit être la branche d'origine, ou encore qu'il se charge automatiquement lors d'une correction de bogue du merge vers les branches de développement et stable, ainsi que la création du tag.
Tout dans git-flow peut être fait à l'aide de commandes Git uniquement, on peut donc facilement choisir de l'utiliser ou non...

Un outil fort intéressant à mes yeux !

Dépôt trashy pour Fedora 16

trashy — Sat, 31 Dec 2011 11:42:00 +0100

Mon dépôt personnel (le dépôt « trashy ») fournissait jusqu'à présent des paquets pour Fedora 14 et 15 ; ainsi que pour EL-5 et EL-6.

À compter d'aujourd'hui ; les paquets sont également disponibles pour Fedora 16 Cette évolution signe l'arrêt du dépôt Fedora 14, qui n'est plus supportée de toutes façons.

J'ai profité de cette mise à jour pour faire un peu de ménage, et mettre à jour certains paquets. Sur ce dépôt, vous pourrez trouver :

la dernière version SVN de Galette,
le serveur Jabber/XMPP Prosody (et ses dépendances),
la dernière version du logiciel éducatif GCompris (les dépôts officiels n'étant pas à jour),
le dernier mercurial-server,
le serveur d'images IIP.
la bibliothèque python-gnupg,
le logiciel éducatif Omnitux,
Smarty 3 (expérimental),
...

Meilleurs voeux à tous

Joyeusetés (ou débilités) matinales de Fedora 16

trashy — Thu, 08 Dec 2011 06:56:00 +0100

Ce matin, comme bien d'autres, je me mets sur la dos de Galette, pour résoudre quelques bogues, rédiger un brin de documentation, bref, pour bosser en somme.

Comme à l'accoutumée, je lance dans une console en root un tailf /var/log/http/error_log ; et un tailf logs/galette.log dans une autre, en user. Jusque là, rien de bien excitant me direz-vous, et vous aurez raison. Oui, mais ce matin... Le second tailf échoue ; avec un message laconique :

 % tailf logs/galette.log   

tailf: logs/galette.log : impossible d'ajouter une surveillance inotify (la limite de surveillances inotify a été atteinte).

Chouette. La sortie de tail -f ne diffère qu'à peine :

 % tail -f logs/galette.log

tail: inotify resources exhausted
tail: inotify ne peut pas être utilisé, retour à l'interrogation active

Bon, OK, c'est pas un bon matin. Première vérification : l'espace disque disponible. Tout est correct de ce côté là ; c'est pas ça

Après quelques recherches, je trouve la commande qui me permet de lister, par ordre de gourmandise, les processus qui consomment le plus de ce côté. Lançons nous :

 % for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr
      1 /proc/2655/fd/anon_inode:inotify
      1 /proc/2622/fd/anon_inode:inotify
      1 /proc/2609/fd/anon_inode:inotify
      1 /proc/2511/fd/anon_inode:inotify
      1 /proc/2503/fd/anon_inode:inotify

Et voici donc les coupables :

goa-daemon (process 2655) - qui remporte la palme toutes catégories confondues
tracker-miner-flickr (process 2622)
nautilus -n (process 2609)
tracker-store (process 2511)
tracker-miner-fs (process 2503)

Mis à part nautilus (bien que je me demande toujours pourquoi nautilus prend un malin plaisir à se charger de l'afficage de mon bureau XFCE ; mais passons ce point de détail) ; je n'ai recours à aucun des services proposés, mieux même : je n'en veux pas. Tracker (à ce que j'en sais) indexe les données présentes (je ne sais top ou d'ailleurs) pour effectuer des recherches. Chouette ; je suis super content, j'utilise uniquement la console pour effectuer des recherches quand j'en ai besoin.

J'avais déjà remarqué que certains processus tracker se lançaient pour consommer du CPU à ne plus savoir qu'en faire (ralentissant par ailleurs les machines les plus lentes) ; et comme ce n'était pas trop problématique, je les avais simplement killés. Oui mais là ; ça commence à faire beaucoup ; et je voudrai les désactiver.

Hé bien, il n'y a pas de façon simple. Supprimer tracker va virer Brasero, que je souhaiterai continuer à utiliser. La solution pour désactiver tracker, je l'ai trouvée dans un rapport de bogue au titre évocateur « provide a method to disable tracker ». Il faut créer les trois fichiers suivants :

~/.config/autostart/tracker-miner-flickr.desktop
~/.config/autostart/tracker-miner-fs.desktop
~/.config/autostart/tracker-store.desktop

Avec le contenu :

[Desktop Entry]
Hidden=true

Une solution à répéter pour chaque utilisateur du système. Révolutionnaire, vraiment. Il semblerait par ailleurs que cette méthode ne soit pas la plus adaptée pour gnome-shell (voir le commentaire #2 du rapport de bogue) ; mais je me suis arrêté là, j'utilise XFCE.

Quant au démon GOA (Gnome Online Accounts), je l'ai juste killé pour le moment, je n'ai pas plus de temps à perdre ce matin pour désactiver ce que je n'ai pas demandé, qui se lance quand même, et me bouffe mes ressources...

Hope that could help.

Mon GIT à la maison ! Git - Gitolite - cgit (ou gitweb)

trashy — Sat, 17 Sep 2011 22:11:00 +0200

Ces derniers temps, je m'intéresse de plus en plus à Git en remplacement partiel de mes anciens dépôts SVN (partiel seulement, car j'apprécie aussi Mercurial, certains de mes anciens projets ont dores et déjà migré).

Ce que je souhaite :

avoir un accès via le web au dépôt, au minimum pour consulter le code,
pouvoir assez facilement régler les droits en lecture et/ou écriture par dépôt.

Côté accès web, je dispose actuellement de nombreux outils pour naviguer dans mes dépôts SVN :

en utilisant mod dav svn et une feuille XSLT adaptée,
en utilisant ViewVC,
ou encore via WebSVN.

Mercurial n'est pas en reste ; puisqu'il est est facile de mettre en place une interface web de consultation des dépôts.

L'interface web, en plus de me permettre de consulter mes dépôts depuis n'importe quel matériel permet de lancer un navigateur web, donne aussi un aspect public pour mes projets (la plupart étant sous licence libre) ; l'écriture étant restreinte aux accès SSH.

Le pendant Git de ces interfaces est Gitweb, utilisé par de nombreux projets hébergé sous Git, comme le Projet Fedora par exemple. Cependant, j'ai très vite rencontré certaines « limites » avec gitweb, qui ne me semblent pas acceptables :

je ne suis pas parvenu (bien qu'à priori cela soit possible) à mettre en place le clonage des dépôts via HTTP
lorsqu'un dépôt n'est pas autorisé en lecture à l'utilisateur spécial gitweb, il n'est certes pas affiché dans la liste des dépôts ; mais est tout de même accessible via l'interface, pour le peu que l'on connaisse le nom du dépôt !

J'ai donc décidé de me tourner vers une alternative à gitweb : cgit.

Bien entendu, des service d'hébergement Git tels que gitorious ou github existent ; mais ce n'est absolument pas envisageable pour le travail ; et à titre personnel, j'aurai aimé avoir des dépôts privés, ce qui n'est pas possible avec les formules gratuites de tels hébergeurs. De plus, seul gitorious repose actuellement sur des technologies libres...

En ce qui concerne la gestion des accès, j'avais évoqué ici-même l'utilisation de mercurial-server sous Fedora ; dont le pendant Git est gitolite (en quelque sorte le successeur de gitosis).

Let's go :

$ sudo yum install git-all gitolite

git-all installera l'ensemble des paquets git-* présents sur les dépôts, vous pouvez si vous le souhaitez préférer ne lister à la place que les paquets que vous souhaitez réellement installer

gitolite

En plus des explications fournies ici, je vous conseille vivement de consulter la documentation d'installation de gitolite

Commençons par mettre en place gitolite. Le paquet présent sur les dépôts installera bien entendu tout ce dont vous aurez besoin :

les fichiers de l'application (ben oui, heureusement !),
un utilisateur dédié (gitolite),
un répertoire de stockage (/var/lib/gitolite - qui est également le $HOME de l'utilisateur gitolite).

Gitolite offre un accès aux dépôts Git via SSH. L'intégralité des dialogues avec le serveur passeront donc par l'utilisateur gitolite ; le programme se chargera ensuite de vérifier qui vous êtes et ce à quoi vous avez accès... ou pas :-p Il vous faut donc créer une clé SSH (si ce n'est déjà fait) :

$ ssh-keygen

Il faut ensuite copier la clé sur le serveur en la renommant de la forme username.pub. Il faudra pour la suite que cette clé soit lisible par l'utilisateur gitolite, la copier dans /tmp semble une bonne idée :

$ scp ~/.ssh/ir_rsa.pub user@server:/tmp/machin.pub

Note : le nom de la clé SSH n'est pas anodin. En effet, c'est sous ce nom que vous serez identifié ; et c'est celui qui sera utilisé un peu plus tard lors de la configuration des droits des dépôts. Cette remarque est valable d'une façon générale avec gitolite ; on y reviendra

Sur le serveur, il faudra ensuite initialiser gitolite :

# su - gitolite
$ gl-setup /tmp/machin.pub
creating gitolite-admin...
Initialized empty Git repository in /var/lib/gitolite/repositories/gitolite-admin.git/
[...]
 2 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf
 create mode 100644 keydir/machin.pub

Et... Voilà ! Gitolite est installé et configuré sur votre serveur ; vous pouvez profiter de la magie !!

L'administration de Gitolite se fait par... un dépôt Git, on peut voir qu'il a été créé et peuplé par la commande gl-setup Récupérons un clone (depuis la machine sur laquelle est installée la clé SSH uploadée. Ben ouais ; faut suivre un peu ! ) :

$ git clone gitolite@server:gitolite-admin.git

Examinons le dépôt ainsi cloné :

$ tree gitolite-admin 
gitolite-admin
|-- conf
|   `-- gitolite.conf
`-- keydir
    `-- machin.pub

On a donc un dossier conf qui contient l'unique fichier de configuration de gitolite ; et un dossier keydir dont la fonction est de recevoir toutes les clés des utilisateurs. Le fichier de configuration par défaut donne tous les droits à l"utilisateur machin sur le dépôt d'administration, un dépôt de test accessible librement à tous créé à l'initialisation est aussi configuré :

$ cat conf/gitolite.conf
        repo    gitolite-admin
                RW+     =   machin

        repo    testing
                RW+     =   @all

        repo    mailletest
                RW+      =  machin chouette
                R        =  chose gitweb

Pour créer un nouveau dépôt, il suffit d'ajouter l'entrée au fichier de configuration. Dès que vous aurez fait un git push dans le dépôt gitolite-admin, le nouveau dépôt sera initialisé automatiquement. Cool, non ? :-p
Le dépôt ajouté portera le nom mailletest ; il sera accessible en lecture/écriture aux autilisateurs machin et chouette, en lecture seule pour les utilisateurs chose et gitweb. N'oubliez pas dans ce cas d'ajouter les fichiers chouette.pub et chose.pub dans le dossier keydir, et de les ajouter au dépôt avant de commiter. En cas d'oubli, gitolite se fera un plaisir de vous informer que le ou les utilisateurs qui ont été configurés n'ont pas de clé. L'utilisateur gitweb est particulier, il définit la liste des dépôts qui seront exportés dans le fichier projects.list.

$ git add
$ git commit conf/gitolite.conf -m"Test de création de dépôt"
[...]
$ git push 
[...]
remote: Initialized empty Git repository in /var/lib/gitolite/repositories/mailletest.git/
[...]

Votre installation de gitolite est complète, votre premier dépôt est créé ! Que demander de plus ? Ha oui, une interface web on avait dit...

Si vous souhaitez en savoir plus sur les possibilités de gitolite :

Interface web

Si vous souhaitez utiliser une des interfaces web sur les futurs dépôts créés, il faudra effectuer une petite modification supplémentaire dans la configuration de gitolite. Dans le fichier /var/lib/gitolite/.gitolite.rc, changez la valeur pour $REPO_UMASK de 0077 à 0027 (les commentaires présents dans le fichier devraient être assez parlants).

La configuration expliquée ici est basée sur le serveur web Apache HTTPD. Il est évidemment possible d"utiliser les différentes interfaces web à Git avec n'importe quel serveur web capable de faire du CGI, mais cela dépasse largement le cadre de ce tutoriel.

Notez que lors de l'installation des paquets de chacune des interfaces présentées ici, un fichier de configuration par défaut sera placé dans le dossier /etc/httpd/conf.d/, nommés respectivement cgit.conf, git.conf et webgit-caching.conf. Comme nous utiliserons un hôte virtuel dédié, nous commenterons chacune des lignes présentes dans le fichier par défaut (on ne supprime pas le fichier, puisqu'il est fourni avec le paquet RPM ).

Chaque dépôt sur le serveur requiert d'être initialisé pour répondre aux requêtes HTTP :

$ cd /var/lib/gitolite/repositories/mailletest.git
$ git update-server-info

L'opération est à répéter après chaque commit. Évidemment, il y a une solution automatisée, le faire à la main n'est même pas envisageable Utilisons les hooks pour parvenir à nos fins, l'opération sera automatiquement effectuée sur le dépôt après chaque commit :

$ cd /var/lib/gitolite/repositories/mailletest.git
$ cp ./hooks/post-update.sample ./hooks/post-update
$ chmod +x ./hooks/post-update

Gérer les droits...

On arrive à une partie un peu plus sensible : la gestion des droits. En effet, les dossiers et les dépôts créés sont par défaut uniquement accessibles à l'utilisateur gitolite ; mais nous souhaitons que l'utilisateur apache puisse y accéder. Heureusement, nous avons modifié les REPO_MASK de gitolite. Voyons ce qu'on a :

# ls -al /var/lib/gitolite/projects.list
-rw-------. 1 gitolite gitolite 0 16 sept. 23:43 /var/lib/gitolite/projects.list
#  `--# ls -al /var/lib/gitolite/repositories 
total 40
drwxrwxr-x. 5 gitolite gitolite 4096 16 sept. 23:43 .
drwxr-x---. 5 gitolite gitolite 4096 16 sept. 23:13 ..
drwx------. 8 gitolite gitolite 4096 16 sept. 23:43 gitolite-admin.git
drwxr-x---. 7 gitolite gitolite 4096 16 sept. 23:43 mailletest.git
drwx------. 7 gitolite gitolite 4096 16 sept. 23:43 testing.git

Ok, commençons par ajouter l'utilisateur apache au groupe gitolite. Une fois cela fait, le dépôt nouvellement créé (mailltest.git) sera accessible depuis le web ; mais pas gitolite-admin, c'est voulu. En effet, je ne souhaite vraiment pas que le dépôt de configuration soit accessible par le web ; ne pas pas autoriser le serveur à lire son contenu est un bon moyen ; bien qu'il soit aussi possible de configurer les dépôts que gitweb n'affichera pas... L'un n'exclut de toutes façons pas l'autre « Deux précautions valent mieux qu'une ».
Nous aurons aussi à adapter les droits sur le fichier projects.list pour que apache puisse le lire :

# usermod -a -G gitolite apache
# chmod g+r /var/lib/gitolite
# chmod g+r /var/lib/gitolite/projects.list

SELinux...

Mais-heu ! SELinux, il est méchant avec moi, il me bloque l'accès à mes jolis dépôts Git avec lesquels moi je veux m'amuser !

Si SELinux est activé (je ne vois pas pourquoi il ne le serait pas, à plus forte raison sur un serveur !!), l'accès aux fichiers et dossiers de Git sera bloqué depuis les interfaces web. Il semble que la solution consiste à utiliser le contexte git_system_content_t sur les fichiers adéquats.

Toutefois, appliquer ce contexte sur certains dossiers pourrait poser problème. Un mauvais contexte sur le dossier ~/.ssh entraînerait l'impossibilité de se connecter au dépôt via SSH... Plutôt gênant, non ? :-p
J'ai donc choisi de modifier le dossier home de l'utilisateur pour séparer les données système de l'utilisateur, et les données des dépôts Git :

# usermod -d /home/gitolite -m gitolite
# mkdir /var/lib/gitolite && chown -R gitolite:gitolite /var/lib/gitolite
# chmod o-rx /var/lib/gitolite
# mv /home/gitolite/* /var/lib/gitolite/
# mv /home/gitolite/.gitolite* /var/lib/gitolite
# su - gitolite
$ ln -s /var/lib/gitolite/* .
$ ln -s /var/lib/gitolite/.gitolite* .

Appliquons maintenant le contexte SELinux adéquat :

# semanage fcontext -a -t git_system_content_t '/var/lib/gitolite(/.*)?'
# restorecon -R -v /var/lib/gitolite

Bon... On ne devrait pas être trop mal là Lancez donc votre navigateur sur votre sous domaine, et voyez si ça fonctionne !

En cas de problèmes :

si c'est SELinux qui bloque, les erreurs vous seront signalées dans /var/log/messages ou /var/log/audit/audit.log,
s'il s'agit de problèmes de droits ; vous n'obtiendrez pas d'erreurs dans les logs, juste un 404 dans le navigateur. Assurez vous que le groupe ait le droit de lire les fichier et dossiers, et de traverser les dossiers,
tout semble correct, et pourtant, votre dépôt n'apparaît pas ? Vérifiez que vous avez bien ajouté les droits en lecture sur le dépôt pour l'utilisateur gitweb dans la configuration de gitolite.

cgit

Cgit est est une application CGI écrite en C, un peu comme gitweb. Pour l'installer :

$ sudo yum install cgit

La configuration de cgit passe par le fichier /etc/cgitrc. Il suffira d'ajouter les lignes suivantes à ce fichier :

enable-gitweb-owner=1
project-list=/var/lib/gitolite/projects.list
scan-path=/var/lib/gitolite/repositories/

Ensuite, nous configurerons notre hôte virtuel apache pour utiliser cgit :

# git repositories
<VirtualHost *:80>
        ServerName git.domain.com

        # Logs :
        ErrorLog /var/log/httpd/git_error_log
        CustomLog /var/log/httpd/git_access_log combined

        Alias /cgit-data /usr/share/cgit
        ScriptAlias /cgit /var/www/cgi-bin/cgit

        RewriteEngine on
        RewriteCond %{REQUEST_URI} !^/cgit
        RewriteRule (.*) http://git.domain.com/cgit$1 [P]

        <Location />
                Options FollowSymLinks

                # Limitation commits
                <Limit POST PUT>
                        Require valid-user
                </Limit>
        </Location>
</VirtualHost>

Vous aurez ainsi accès à l'interface cgit depuis l'URL http://git.domaine.com ; et pourrez cloner un dépôt en utilisant le protocole HTTP :

$ git clone http://git.domaine.com/mailletest.git

Vous pouvez afficher automatiquement les différents URL de clonage de vos dépôts via cgit, en renseignant dans le fichier de configuration :

clone-prefix=http://git.domain.com ssh://gitolite@git.domain.com

gitweb

Gitweb est aussi une application CGI. Pour l'installer :

$ sudo yum install gitweb

Créons ensuite notre hôte virtuel dans le fichier /etc/httpd/conf.d/git.mondomaine.com.conf avec le contenu suivant :

# git repositories
<VirtualHost *:80>
        ServerName git.mondomaine.com
        DocumentRoot /var/www/git/

        # Logs :
        ErrorLog /var/log/httpd/git_error_log
        CustomLog /var/log/httpd/git_access_log combined

        <Directory /var/www/git>
                DirectoryIndex gitweb.cgi
                Options ExecCGI FollowSymLinks

                ## Controls who can get stuff from this server.
                Order allow,deny
                Allow from all

                <Files gitweb.cgi>
                        SetHandler cgi-script
                </Files>

                # Limit commits
                <Limit POST PUT>
                        Require valid-user
                </Limit>

                # Redirections
                RewriteEngine on
                RewriteRule ^$ gitweb.cgi [L]
                RewriteCond %{REQUEST_FILENAME} !-f
                RewriteCond %{REQUEST_FILENAME} !-d

                RewriteRule (.*) /gitweb.cgi/$1 [QSA,L]
        </Directory>
</VirtualHost>

Le fichier de configuration principal de GitWeb se trouve à /etc/gitweb.conf. Pour notre configuration, il faut simplement configurer deux choses : le fichier qui liste les projets, et le dossier contenant les différents dépôts. On ajoutera donc au fichier gitweb.conf les lignes suivantes :

$projects_list = "/var/lib/gitolite/projects.list";
$projectroot = "/var/lib/gitolite/repositories/";

Clonage via http

Le clone d'un dépôt en utilisant le protocole HTTP n'est pas natif avec la configuration mise en place. D'abord, nous allons ajouter sur la pages des différents projets l'URL de clonage. Ajoutez la ligne suivante dans le fichier /etc/gitweb.conf

@git_base_url_list = qw(http://git.mydomain.com)

Normalement, il suffit d'ajouter une règle de ré-écriture semblable à celle-ci pour que le clonage avec une adresse du type http://git.domain.com/mailletest.git soit opérationnel :

RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ gitweb.cgi%{REQUEST_URI}  [L,PT]

Je ne suis cependant pas encore parvenu à faire fonctionner ceci :'(

gitweb-caching

giweb-caching fournit les mêmes fonctionnalités que gitweb, mais avec le support du cache en sus. Pour l'installer :

$ sudo yum install gitweb-caching

Pour l'activer il suffira de remplacer les deux occurrences /var/www/git par /var/www/gitweb-caching dans le fichier de configuration de l'hôte virtuel apache.

Le script CGI installé par défaut ne possède pas le contexte SELinux adéquat pour fonctionner, il faudra le modifier :

# semanage fcontext -a -t httpd_git_script_exec_t '/var/www/gitweb-caching/gitweb.cgi'
# restorecon -v /var/www/gitweb-caching/gitweb.cgi

Et c'est tout !

Notez que les remarques concernant le clonage de dépôts par HTTP sont également valables pour gitweb-caching :'(

Galette : la cuisine continue !

trashy — Sun, 04 Sep 2011 23:53:00 +0200

Tout est dans le titre. Merci de m'avoir lu.

Non, mais je plaisante ; je vais développer un peu tout de même
Je ne sais trop par où commencer...

Design

Le design de Galette a pas mal changé depuis que je suis aux commandes ; et je me suis décidé récemment à laisser tomber le rendu XHTML (et les nombreux problèmes qu'il a pu engendrer sur Galette) pour HTML5. J'ai ainsi pu utiliser les nouveautés de HTML5, notamment en ce qui concerne la gestion des formulaires (champs requis, ...).

Pour vous donner une idée, voici un aperçu avant (0.63.3)/après (0.7) des pages d'authentification et d'enregistrement :

Vous pouvez souhaiter voir la comparaison complète pour la page d'enregistrement.

L'actuel thème de Galette est compatible avec la majorité des navigateurs récents (Firefox, Chromium, Epiphany, Internet Explorer 9, ...).

Fonctionnalités

L'un des ajouts les plus récents concerne la mise en place d'un historique des E-Mailings envoyés aux adhérents, et la possibilité de les réutiliser comme modèle Le travail est encore en cours, il n'est actuellement pas encore possible de modifier les destinataires par exemple... Pas très pratique me direz-vous, et vous aurez raison ; mais c'est en bonne voie

Une autre modification relativement importante concerne la gestion des transactions. Il est désormais possible, depuis une transaction, d'adjoindre une contribution existante (en profitant pleinement des possibilités de la liste des contributions) ou d'en créer une nouvelle. Jusque maintenant, on pouvait uniquement créer une nouvelle contribution juste après la saisie d'une nouvelle transaction, sans ajouts ultérieur possibles.

Documentation

Outre quelques ajustements du côté de la documentation d'installation, deux choses à noter :

le début de rédaction d'une documentation utilisateur (sont traités les champs dynamiques, la traduction de libellés, et le textes des courriels envoyés),
la refonte de la page d'accueil pour la rendre un peu plus sympathique :-p

Base de données

Courant juillet, je me suis rendu compte que le framework de bases de données que j'avais choisi il y a quelques années, MDB2, n'était plus vraiment actif. En effet, la dernière version stable (2.4.1) date de 2007 ; et la dernière version de développement (2.5beta) de 2010. MDB2-2.4.1 n'est pas compatible PHP 5.3, je me suis donc décidé à passer en 2.5.0b3 (beta). Oui mais voilà : toutes les requêtes préparées de Galette échouaient, et silencieusement ; ce qui a rapidement causé des bogues très difficiles à tracer et à résoudre..

La coupe était pleine !

Ayant récemment découvert le fait que la partie Db du Zend Framework était utilisable sans avoir recours à l'intégralité du framework lui-même ; mon choix était fait. Une branche a été créée pour effectuer la migration. 2 semaines et demie et environ 180 commits plus tard ; la branche était mergée avec le trunk : Galette est désormais gérée par Zend.

J'ai profité de cette migration pour définitivement exclure les bouts de code qui utilisaient encore et toujours Adodb ; et aussi pour passer certains aspects du logiciel en POO.

Il s'agit d'une modification fort importante, qui a nécessité de récrire une grande partie du code existant ; bien qu'invisible pour l'utilisateur final.

Tester !

Si vous souhaitez tester Galette, j'ai récemment mis en place une archive mise à jour quotidiennement depuis le dépôt SVN :
http://download.tuxfamily.org/galette/galette-0.7-dev.tar.bz2

Cette fois, je peux vous dire merci de m'avoir lu, sans avoir à me reprendre :-p

Bon appétit !

Galette : version de développement et documentation

trashy — Sun, 17 Jul 2011 17:10:00 +0200

Depuis quelques années, je suis le mainteneur de Galette, un logiciel libre de gestion d'adhérents et de cotisations en ligne à destination des associations.

Beaucoup de travail a été effectué sur le logiciel, mais de gros chantiers ont été entamés, et pas mal de péripéties (pas forcément en rapport) ont fait que les versions stables du projet n'avancent pas des masses (j'avais notamment cessé tout développement sur le projet pendant 15 mois, pour ne reprendre que récemment)

Version de développement de Galette

De nombreuses fonctionnalités ont dores et déjà été ajoutées, notamment un système de plugins qui devrait à terme permettre de proposer de nouveau une version de Galette pour les associations sportives, ou encore les associations automobiles !

Cette version de développement devrait être aujourd'hui relativement utilisable, j'ai récemment corrigé pas mal de bogues qui ont été mis en évidence par les tests qu' a effectués Roland, un gentil utilisateur de Galette... Seulement voilà, la seule solution pour tester la version de développement de Galette, c'est de la récupérer via le dépôt SVN... Je dis « relativement utilisable », car je n'ai pas l'occasion de tester l'intégralité des fonctionnalités régulièrement, et il m'est impossible de savoir ce que ça peut donner chez divers hébergeurs ; des bogues peuvent donc subsister.

J'ai donc mis en place récemment un système de « nigthly » ; qui met à disposition quotidiennement (à 0h30) cette version de développement sous forme d'archive à télécharger ; disponible à l'adresse :
http://download.tuxfamily.org/galette/galette-0.7-dev.tar.bz2

Pour les utilisateurs de Fedora, j'ai également mis à disposition un RPM de Galette 0.7 via mon dépôt personnel que je vous conseille d'utiliser au lieu de l'archive quotidienne, les problématiques de droits et de contextes SELinux étant intégrées directement dans le RPM

Les RPM sont disponibles pour Fedora 14 et Fedora 15 actuellement, je n'ai pas prévu pour le moment de fournir des paquets pour RHEL/CentOS.

Notez qu'il y a une petite modification à apporter au fichier de configuration apache fournit par le paquet ; il s'agit de déclarer votre fuseau horaire. Pour ce faire, dans le fichier /etc/httpd/conf.d/galette.conf, ajoutez simplement la directive php_value date.timezone Europe/Paris (où Europe/Paris correspond à votre fuseau horaire) dans la section Directory /usr/share/galette :

<Directory /usr/share/galette>
    Options None
    AllowOverride Limit Options FileInfo

    Order Deny,Allow
    Allow from all

    php_value date.timezone Europe/Paris
</Directory>

Nouvelle documentation

Une toute nouvelle documentation a également vu le jour :
http://galette.tuxfamily.org/documentation/

Cette nouvelle mouture de la documentation ne concerne que Galette 0.7, et n'est disponible (pour le moment) qu'en français. Cette documentation est axée sur trois grandes parties :

Actuellement, le manuel de l'utilisateur est très peu avancé, c'est une tâche qui demande elle aussi beaucoup de temps, et je n'en ai que trop peu... À votre bon coeur !

Cette documentation est rédigée avec Sphinx (le système de documentation utilisant reStructuredText et utilisé -entre autres - pour la documentation du projet Python), elle est hébergée sur un dépôt GIT chez Tuxfamily. Pour en savoir plus sur la nouvelle documentation de Galette...

MrBot : passage à supybot-gribble

trashy — Sun, 22 May 2011 21:00:00 +0200

Le bot qui hante différents canaux IRC francophones relatifs à Fedora est propulsé par Supybot, qui fonctionne très bien et fait exactement ce que je lui demande.

Je souhaitais intégrer (depuis quelque temps déjà) une commande similaire à sed : il arrive régulièrement sur IRC lorsque quelqu'un fasse une erreur, il la corrige ensuite à l'aide d'une syntaxe sed. Le but du plugin est de sortir la phrase originale modifiée. Un petit exemple :

<trashy> bojour les gens
<trashy> s/bojour/bonjour/
<MrBot> trashy voulait dire : bonjour les gens

Et voilà ! :-p

Cela dit, ça pose un problème, et de taille... Les plugins requis pour une telle fonctionnalité n'existent pas sur Supybot (qui ne semble plus être terriblement actif), mais a en revanche été intégrée à la version Supybot Gribble. Je ne souhaitais pas utiliser cette version qui n'existe pas dans les dépôts officiels ; mais j'ai constaté qu'une revue d'intégration de supybot-gribble dans les dépôts Fedora est en cours, et que les plugins présents sur les dépôts ont également été modifiés en conséquence ; il ne peut en effet y avoir que l'un des deux qui soit installé.

Je suis donc passé à cette version (les plugins supybot-fedora et supybot-koji dans la version requise sont encore dans le dépôt updates-testing à l'heure où j'écris ces lignes), rien à déclarer sauf que la commande « sed like » fonctionne désormais

Installation d'une instance Solr - Fedora-fr

trashy — Sun, 22 May 2011 13:10:00 +0200

J'ai déjà parlé ici même de la mise en place d'un système de recherche alternatif pour la documentation francophone de Fedora, basé sur Solr, et utilisable via une interface de recherche PHP et un bot IRC.
Les annonces faisant suite à la mise en place du système de recherche et du bot IRC ainsi que l'annonce de la mise en ligne de l'interface de recherche PHP sont toutes deux disponibles dans les archives de mon blog.

J'expliquerai ici comment s'installe le système de recherche, et comment indexer des données, je l'ai promis à un fantôme qui a passé du temps à essayer d'installer ça sans grand succès

Installation

Solr est une application web écrite en Java, qui nécessite l'installation et la configuration d'un moteur de servlets. La distribution officielle de Solr embarque une instance Jetty, mais j'ai préféré utiliser tomcat, que je connais bien mieux
Sous Fedora, lancez simplement (en root) :

# yum install tomcat6 tomcat6-webapps

Lors de l'installation de ce paquet, un utilisateur nommé tomcat est créé, mais le compte n'est pas accessible par défaut. Il est toutefois possible de s'y connecter en spécifiant le shell à utiliser :

# su -s /bin/bash tomcat

Le reste des opération est à effectuer avec l'utilisateur tomcat. Si vous préférez ne pas utiliser les RPM de tomcat, vous devrez vous assurer que l'utilisateur qui fera tourner le serveur a bien tous les droits nécessaires dans les différents dossiers. Dans tous les cas, il faudra procéder à une petite modification du fichier /etc/tomcat6/server.xml en raison de certains problèmes d'encodage... Cherchez le connecteur HTTP, et ajoutez l'attribut URIEncoding="UTF-8" :

<Connector port="8080" protocol="HTTP/1.1" 
  connectionTimeout="20000" 
  redirectPort="8443"
  URIEncoding="UTF-8" />

Récupérez tout d'abord les fichiers de configuration propres à la documentation francophone, le script d'installation et les outils nécessaires sur mon dépôt mercurial (vous pouvez récupérer directement une archive) :

$ hg clone http://hg.ulysses.fr/solr-config_fedora-fr

Vous obtiendrez un dossier avec le contenu suivant :

$ cd solr-config_fedora-fr
$ ll
drwxrwxr-x. 4 trasher trasher    4096 21 mai   23:13 cores
-rwxrwxr-x. 1 trasher trasher     455 21 mai   23:33 install.sh
drwxrwxr-x. 2 trasher trasher    4096 21 mai   04:17 preprocess
-rw-rw-r--. 1 trasher trasher    2115 21 mai   23:43 README
-rw-rw-r--. 1 trasher trasher     230 21 mai   23:30 solr-tomcat-context.xml

Dont voici un bref descriptif :

dossier cores : contient la configuration de l'instance, et contiendra aussi par la suite les données d'indexation de cette instance,
fichier install.sh : script basique d'installation,
dossier preprocess : relatif à l'indexation, voir plus bas ;),
fichier README : est-ce utile de préciser ? :-D,
fichier solr-tomcat-context.xml : configuration de l'application web dans tomcat.

Le script d'installation effectue quelques tâches rébarbatives et basiques, à savoir :

télécharge les fichiers Solr (war et jar) depuis mon propre site (et non le site officiel, l'archive officielle pèse environ 80Mo alors que nous n'avons réellement besoin que de 9Mo...),
copie les fichiers récupérés aux emplacements adéquats (dans le dossier courant, bien entendu),
modifie le fichier de contexte tomcat (solr-tomcat-context.xml) pour adapter les chemins,
crée un lien symbolique nommé solr.xml dans le dossier /etc/tomcat6/Catalina.localhost/ vers le fichier de contexte. De cette façon, lors du démarrage de tomcat, l'application sera déployée automatiquement,
modifie, dans la configuration de l'instance, le chemin vers le fichier des données à indexer.

À ce stade, vous devriez être en mesure d'accéder à l'application Pour vérifier :

lancez le service :

service tomcat6 start && tailf /var/log/tomcat6/catalina.out

vérifiez la sortie de la commande tail pour voir si des erreurs se sont produites au démarrage de tomcat
si tout est ok, vous devriez pouvoir accéder à l'application à l'adresse :

http://localhost:8080/solr/

Le lien vers l'interface d'administration de l'instance devrait vous amener sur une page semblable à :

L'exécution de la requête par défaut ne renverra aucun résultat, et c'est bien normal, nous n'avons pas encore traité les données. Allez, hop ! La suite ! :-p

Indexation des données

Les données du wiki sur Fedora-fr.org sont stockées dans une base de données MySQL. Il serait possible avec Solr d'indexer directement le contenu de cette base, mais cela demandez bien entendu à avoir accès. Je ne souhaitais pas le moins du monde ouvrir le port MySQL sur le serveur ; j'ai donc décidé de passer par un dump.

Puisque XML est utilisé à toutes les sauces, que MediaWiki permet un export au format XML de ses données, et que je travaille actuellement avec du XML/XSLT au quotidien, c'est tout naturellement que j'ai choisi ce format :-p

L'export côté MediaWiki s'effectue avec la commande :

$ php {mediawiki}/maintenance/dumpBackup.php --conf {mediawiki}/LocalSettings.php --full --output=gzip:wiki.xml.gz

Copiez le fichier .gz résultant dans le dossier preprocess.

Il aurait été possible de travailler directement sur l'export XML de MediaWiki pour indexer les données, ça ne m'a pas semblé être un bon choix. En effet, les informations récupérées pour les articles se cantonnent principalement au titre et au contenu intégral. Plutôt limité alors que sur le wiki, les articles sont attachés à des catégories, des macros pour stipuler les auteurs et contributeurs de l'article sont utilisées, de même qu'un balisage spécifique qui avait été mis en place il y a quelques années par Pascal pour son export PDF de la documentation. Il était donc possible et surtout intéressant d'enrichir nos index de recherche avec ce type d'informations.

J'ai donc travaillé sur une feuille XSLT qui effectue les tâches suivantes :

suppression de toutes les anciennes révisions, seule la dernière version de l'article nous importe ici,
extraction de la liste des auteurs (macro Auteur et Auteurs), contributeurs (liste des utilisateurs ayant édité l'article), catégories, applications (balise <app>) et paquets (balise <paquet>,
récupération des noms (les comptes sur le wiki étant créés selon le schéma PrénomNom.

Une fois l'export XML récupéré depuis MediaWiki, il faut donc lui appliquer les transformations XSL décrites dans le fichier preprocess/wiki.xsl. Cette feuille utilise des techniques (notamment les expressions régulières) qui ne sont pas présentes dans la version 1.0 de XSLT, mais uniquement en XSLT2... Les outils qui ne gèrent pas XSLT2 (tels que xsltproc) ne pourront pas être utilisés ; on utilisera saxon :

$ cd preprocess
$ gunzip -c --stdout wiki.xml.gz > wiki.xml
$ java -jar ./saxon9he.jar -t -s:wiki.xml -xsl:wiki.xsl -o:wiki_formatted.xml

À titre d'exemple, vous pouvez consulter l'export XML de l'article sur l'installation et la configuration d'Apache, puis le résultat de la transformation XSL appliquée à cet article.

C'est bien entendu le fichier résultant de la transformation XSL que nous allons indexer avec Solr. Le fichier XML (et, oui, encore du XML !) cores/doc/conf/wiki.xml définit la liens entre les éléments XML et les index Solr configurés. Ce fichier indique aussi le chemin complet du fichier contenant les données ; ce chemin a normalement été mis à jour automatiquement si vous avez utilisé le script d'installation (vérifiez la valeur de l'attribut /dataConfig/document/entity/@url , il devrait pointer sur le fichier preprocess/wiki_formatted.xml.

Maintenant que tout est bien configuré, que les chemins sont corrects, et que l'export XML de MadiaWiki est passé à la moulinette XSLT ; il reste à indexer les données, en appelant simplement l'URL :
http://localhost:8080/solr/dataimport?command=full-import

Ces opérations sont « automatisées » dans le script indexation.sh fournit dans le projet Mercurial. Ce fichier me permet de récupérer l'export XML sur le serveur defora-fr.org ; vous devrez donc commenter les lignes rsync et gunzip pour l'utiliser

Pour tester le fonctionnement, nous allons effectuer une recherche dans les titres uniquement (champ titleText) sur le terme « network » ; qui devrait nous ramener les articles dont le titre contient les termes « network » et « réseau » :
http://localhost:8080/solr/fedora-fr_doc/select/?q=titleText:network&version=2.2&start=0&rows=10&indent=on

Qui ramène aujourd'hui 7 résultats

L'URL http://localhost:8080/solr/admin/cores?action=STATUS vous donnera des informations sur l'instance :

le nombre de documents indexés,
la date de dernière modification des index,
le chemin de stockage des données de l'index,
...

Et voilà ; l'instance Solr de recherche dans la documentation francophone de Fedora est en place. Bien entendu, un système comme Solr apporte de nombreuses fonctionnalités, qui ne sont pas forcément exploitées ici ; pour de multiples installations par exemple, il serait bien plus efficace d'utiliser les fonctions de réplication offertes par Solr, mais je n'ai pas encore eu l'occasion d'y regarder.

Voici quelques petites choses que Solr peut faire :

affichage des résultats aux formats xml, csv, json, php, phps (php sérialisé), ... Pour modifier le format de sortie, ajoutez (ou modifiez) le paramètre d'URL wt : wt=php
choix des informations affichées dans les résultats : lister les champs voulus (séparés par une virgule) voulue avec le paramètre d'URL fl (field list) : fl=titleText,author,category
...

Je vous invite à consulter la liste des fonctionnalités de Solr pour en savoir un peu plus sur le produit lui même, la documentation concernant l'écriture de requêtes Solr, et aussi la documentation des paramètres communs de requêtes Solr pour aller un peu plus loin. L'interface d'administration de l'instance fournie par Solr peut également vous aider à effectuer des recherches plus facilement

HTML5 et CSS3 pour le blog de Zia

trashy — Fri, 20 May 2011 23:28:00 +0200

Voilà un peu plus de 3 ans maintenant que le blog de Zia est en ligne, le thème datait de la même époque.

J'ai récemment fait l'acquisition de l'excellent ouvrage CSS avancées vers HTML5 et CSS3 de Raphaël Goetter) - ouvrage que je vous recommande vivement.

J'avais déjà revu mon site personnel suite un article paru sur Alsacréations (du même auteur, d'ailleurs ; et avec un s à Alsacréations ;-)) ; j'ai décidé de tester de nouveau les possibilités de CSS3 pour effectuer une refonte complète du blog de ma fille.

Ce résultat est valide HTML5, probablement pas CSS (grâce notamment à l'utilisation des préfixes -moz et -webkit :-p), et est certainement perfectible... Un petit « bémol » pour Dotclear : la zone de recherche ne peut pas être modifiée via le système de templates, il faut visiblement ouvrir le capot pour ce faire :'(
J'ai également constaté une chose qui m'a paru étrange : le texte alternatif des images n'est pas affiché sur les navigateurs Webkit il semblerait. J'ai pu observer ce comportement avec les navigateurs Epiphany et Midori...

Côté compatibilité navigateurs, le site fonctionne de façon équivalente sous Epiphany (et autres navigateurs à base Webkit) et IE9. Sous Firefox 4, on obtient en prime un dégradé sur le menu principal Le site est lisible sous IE8, mais la perte des arrondis et couleurs transparentes se fait cruellement sentir. J'ai décidé d'abandonner complètement le support IE7 et IE6 pour ce thème ; laissons les vieilleries mourir en paix Pas de version mobiles pour le moment, je n'ai pas encore lu ce chapitre

Merci à Pingou, Remi, number81, MrTom et ma petite femme pour leur aide et leurs conseils

Petite note complémentaire : c'est la première fois que j'utilise la toute nouvelle interface d'administration apportée par Dotclear 2.3.0 ; ça change et c'est agréable Bravo !

Fedora 15 : c'est parti !

trashy — Sun, 01 May 2011 20:50:00 +0200

C'est parti, en ce qui me concerne en tous cas

La version 15 de Fedora n'est pas encore sortie, elle n'est prévue que pour 25 mai à l'heure où j'écris ces lignes. Vous pouvez vérifier si la date a changé sur le calendrier des versions de Fedora 15.

Cependant, la version Beta est disponible au téléchargement depuis 19 avril, et j'ai décidé d'y regarder de près. Je gère, entre le travail et la maison, 6 stations de travail qui tournaient sous Fedora 14 ; j'ai commencé par migrer la moins critique d'entre elles (qui sert très peu à vrai dire), principalement pour pouvoir me faire une idée de Gnome 3 (et de gnome-shell évidemment !).
Mes précédentes expériences avec gnome-shell n'étaient pas des plus positives, car elles dataient des vieilles versions disponibles dans les dépôts de Fedora 14, ou via jhbuild (qui ne fonctionnait pas à tous les coups), et qui était de toutes façons une version de développement.

Ces versions plus anciennes, ont pu me donner un aperçu de ce que serait gnome 3, mais ce n'était pas forcément très bien intégré au système en place. La première mise en route de Fedora 15 Beta m'a conquis. Certains aiment Gnome 3, d'autres pas... Moi, j'aime.
J'ai été utilisateur de KDE pendant des années, pour me détourner de ce gestionnaire de bureau petit à petit à l'arrivée de KDE4 et des programmes qui suivaient (à commencer par Amarok que j'ai remplacé par gmusicbrowser, puis akregator remplacé par liferea, etc, et enfin KDE lui même remplacé par Gnome après plusieurs versions - j'ai testé quand même). Mon épouse aime aussi, et son poste de travail fut le suivant à migrer.

Mon poste de travail au bureau « n'a pas supporté » la migration... Mon dossier home est sur un volume LVM chiffré à part, et n'est pas monté automatiquement au démarrage ; ce dernier ne se termine pas

Les 4 autres postes sont passés sans soucis ; une fois exécuté un yum remove \*nvidia\* pour supprimer définitivement les appels aux pilotes propriétaires qui étaient nécessaires sur ces postes sous Fedora 14. Une décision que je n'ai pas eue à regretter, toutes mes cartes semblent bien fonctionner pour gnome-shell avec les pilotes nouveau.

La mise à jour de ma machine personnelle est toujours un peu plus critique, beaucoup de services, de fichiers, etc. dont j'ai besoin en dépendent. C'est donc celle là qui est passée en dernier, pour me réserver deux jolies surprises...

Tout d'abord, le paquet python-urwid n'a pas pu être mis à jour. C'était environ le 1800ème sur 2200 ! Il a juste suffit que je relance le processus de mise à jour, et les seuls paquets restants ont alors été téléchargés et installés avec succès. Il est à noter que le processus de mise à jour fonctionne comme yum : il installe le paquet dans un premier temps, et nettoie dans un second temps. Pour les 1800 premiers paquets, le nettoyage n'avait pas été fait, la commande package-cleanup --cleandupes me les a supprimés (exécutée depuis l'installation chrootée en mode rescue ; vous comprendrez rapidement pourquoi).

Le second problème, et non des moindres : un kernel panic au démarrage. Aie. Cela m'a remémoré mon premier contact avec Fedora, FC 2 à l'époque, pour laquelle j'avais du reconstruire le initrd du média d'installation, ce dernier ne fonctionnait pas sur la carte mère que je possédais... Sympathique souvenir, mais je préfère toujours éviter ce genre d'ennuis

Après moult tests et corrections (notamment les package-cleanup), je n'avais toujours pas réussi à corriger le souci, et j'ai tenté en dernière instance un yum reinstall kernel qui a fonctionné à merveille, et me permet depuis de profiter gentillement de ma toute nouvelle Fedora 15, ainsi que de participer à la rédaction d'un article sur gnome 3/gnome-shell sur le wiki de fedora-fr.org

Prosody 0.8 pour Fedora

trashy — Sat, 16 Apr 2011 13:39:00 +0200

Il y a quelque temps, j'annonçais ici même la disponibilité de paquets RPM pour Prosody.

J'ai très récemment mis à jour prosody en version 0.8 sur le dépôt trashy, et ajouté aujourd'hui le paquet lua-dbi nécessaire pour utiliser le stockage en base de données.

Prosody 0.8 apporte plusieurs fonctionnalités, dont deux m'intéressent plus particulièrement :

Pour modifier la configuration de Prosody, il suffira d'éditer le fichier /etc/prosody/prosody.cfg.lua en fonction de vos besoins

Note : des paquets sont disponibles sur mon dépôt pour EL-5, mais je n'ai pas eu l'occasion de les tester (mes serveurs jabber tournent tous sous Fedora 14 actuellement). Si prosody venait à ne pas fonctionner correctement, n'hésitez pas à me le faire savoir

Réseau en mode bridge avec KVM sous F-14

trashy — Sun, 27 Feb 2011 17:25:00 +0100

Depuis un certain temps maintenant, j'utilise les fonctionnalités de virtualisation offertes de base par Fedora, à savoir : KVM/Qemu, libvirt et les outils virt-manager, virsh, etc.

Par défaut, les machines virtuelles utiliseront un réseau NAT avec un sous réseau 192.168.122.0. J'ai voulu récemment que le routeur de mon réseau local s'occupe d'attribuer une adresse IP à l'une de mes machines virtuelles ; il fallait donc revoir la configuration du réseau pour passer en mode bridge sur mon unique carte réseau.

Sous Fedora 14 ; une partie du travail est déjà faite... La configuration par défaut ajoute une interface nommée virbr0 que nous allons pouvoir utiliser en tant que bridge.

Pour ce faire, on va créer le fichier de configuration pour l'interface virbr0 (/etc/sysconfig/network-scripts/ifcfg-virbr0) avec le contenu suivant :

DEVICE=virbr0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Bridge
USERCTL=yes
NM_CONTROLLED=no
IPV6INIT=no
NAME="bridge"
PEERNTP=yes

Ici, on spécifie entre autres qu'il s'agit d'un bridge et que la configuration se fait par DHCP (puisque c'est mon routeur qui doit se charger de ça).

Ensuite, on indiquera à l'interface eth0 qu'elle doit utiliser le bridge , en ajoutant à la fin du fichier /etc/sysconfig/network-scripts/ifcfg-eth0:

 BRIDGE=virbr0

Un petit service network restart après, on peut constater que les adresses IP des machines virtuelles sont désormais gérées par le routeur, ainsi que l'attribution d'adresses IP fixes en fonction des adresses MAC, etc.

Notez que la configuration énoncée ici se réfère à l'utilisation du service network, et non NetworkManager. Il faudra donc veiller à ce que ce dernier soit désactivé au profit du service network.

Prosody (serveur Jabber) sur Fedora

trashy — Wed, 23 Feb 2011 09:16:00 +0100

Depuis pas mal de temps, j'ai un serveur Jabber qui tourne sur ma machine personnelle, j'avais mis en place ce service à l'origine pour pouvoir discuter en réseau local avec mon voisin de l'époque lorsque notre accès internet était planté (ce qui arrivait souvent :-p).

J'ai utilisé Jabberd2 pendant des années, il me convenait parfaitement.

L'an dernier, j'ai décidé d'en changer pour voir un peu ce qui se faisait ailleurs, je me suis initialement tourné vers ejabberd qui est présent dans les dépôts Fedora. Seulement voilà, je ne suis pas parvenu à m'y faire
Les possibilités offertes par eJabberd sont prometteuses, il semble que ce soit un bon système ; mais que je ne suis pas parvenu à utiliser correctement. À plusieurs reprises par exemple, je me suis retrouvé avec un service ejabberd qui refusait de se lancer, les raisons en étant souvent très obscures (en ce qui me concerne en tous cas).
Bref, je n'ai pas accroché, ça arrive

C'est alors que j'ai entendu parler de Prosody, un autre serveur XMPP qui n'était malheureusement pas disponible dans les dépôts Fedora. J'ai donc décidé d'en faire un paquet à soumettre aux dépôts (voir la demande de revue de Prosody).

J'utilise Prosody depuis, et j'avoue en être très content

Un bémol cependant... Pour le support SSL, Prosody se base sur lua-sec, qui n'est pas présent non plus dans les dépôts, il fallait donc l'y soumettre (voir la demande de revue pour lua-sec). Le problème se situe ici ; lua-sec duplique des fonctionnalités apportées par lua-socket, présent dans les dépôts et dont lua-sec dépend également par ailleurs. Vous pourrez trouver d'avantage de détails à ce sujet dans la demande de revue, notamment les commentaires de Adam Goode.

Maintenant que je ne maintiens plus aucun paquet dans les dépôts Fedora ; ces deux revues deviennent orphelines

Puisque je continue d'utiliser ce serveur moi même, les paquets Prosody et lua-sec sont disponibles dans mon dépôt personnel ; les dernières versions sont disponibles via bitbucket :

Évidemment, si quelqu'un se sentait l'âme aventureuse, il pourrait proposer ces paquets en se basant sur le travail déjà effectué

mercurial-server sous Fedora

trashy — Fri, 18 Feb 2011 23:19:00 +0100

Depuis quelque temps déjà, je souhaitais utiliser SSH plutôt que HTTPS pour effectuer des commits sur mon dépôt Mercurial. Plusieurs solutions sont proposées dans la documentation de Mercurial. J'ai été séduit par les fonctionnalités de mercurial-server et j'ai décidé de l'utiliser.

Le nom mercurial-server est trompeur ; car il ne s'agit en aucun cas d'un serveur. Les accès au compte utilisateur dédié sont simplement gérés par SSH avec un fichier authorized_keys, tandis que des hooks mercurial vérifient ensuite les permissions de l'utilisateur à qui appartient la clé.

Le paquet n'étant pas disponible dans les dépôts Fedora, j'ai donc décidé de le faire, et de le mettre sur mon dépôt personnel (le dépôt « trashy ») dans un premier temps. Dans un second temps, il devrait être proposé (mais pas par moi) pour inclusion aux dépôts officiels.

Le fichier mercurial-server.spec est disponible, ainsi que le fichier SRPM. Vous pouvez, si vous souhaitez utiliser directement mercurial-server, utiliser mon dépôt personnel :

$ su -lc 'yum install --nogpgcheck http://rpms.ulysses.fr/fedora/trashy-release-14.rpm
$ su -lc 'yum --enablerepo=trashy install mercurial-server'

Les RPM de mercurial-server sont disponibles et testés pour Fedora 14, ce sont ceux que j'utilise moi même.

Vous voilà donc parés... Bon, d'accord, on fait quoi maintenant ? On lit la doc, pardi ! La documentation de mercurial-server vous aidera dans les tâches principales de gestion et d'administration de vos dépôts mercurial. Par défaut, les dépôts sont stockés dans /var/lib/mercurial-server/repos/, la configuration dans /etc/mercurial-server/. Un utilisateur dédié, hgserver est créé lors de l'installation du paquet, son dossier home est défini à /var/lib/mercurial-server.

La configuration de mercurial-server peut se faire de deux façons, cumulatives qui plus est :

utilisation de l'arborescence dans /etc/mercurial-server/,
utilisation d'une arborescence similaire, mais au sein du module hgadmin créé lors de l'installation du paquet.

La documentation officielle indique que si les deux méthodes sont utilisées conjointement, les règles des fichiers de configuration système auront la précédence sur ceux qui se trouvent dans le dépôt mercurial hgadmin. Il est également possible de supprimer complètement les fichiers de configuration du côté du système et n'utiliser que le dépôt hgadmin. Cette technique peut vous permettre de déléguer intégralement la gestion des droits des dépôts à quelqu'un sans pour autant lui donner un accès root sur le serveur (c'est l'une des choses que j'ai trouvées intéressantes ).

Voyons un peu les différents chemins et fichiers utilisés par mercurial-server qui nous seront utiles par la suite :

/etc/mercurial-server : l'ensemble des fichiers de configuration :
- access.conf : configuration des autorisations d'accès. Par défaut, ce fichier autorise par défaut les utilisateurs 'root' à tout faire, interdit aux autres l'accès au dépôt hgadmin, et enfin autorise l'accès en écriture à tous les autres projets aux 'users'.
- hgadmin-hgrc : il s'agit du fichier de configuration du dépôt hgadmin, qui déclenche principalement les hooks mercurial (ce sont eux qui mettront à jour le fichier authorized_keys lors d'un commit sur le projet hgadmin),
- keys : dossier qui contient les clés des différents utilisateurs,
/var/lib/mercurial-server : le dossier des données, qui est aussi le répertoire home de l'utilisateur hgserver :
- repos : les dépôts mercurial eux-mêmes. Après installation, seul le dépôt hgadmin sera présent.

Pensez tout de suite à créer le dossier /var/lib/mercurial-server/.ssh et donnez lui les droits adéquats :

$ su -lc 'su -s /bin/bash hgserver'
$ mkdir .ssh
$ chmod 600 .ssh

En effet, mercurial-server utilise uniquement les possibilités de SSH pour gérer les accès entrants, il récrit donc le fichier .ssh/authorized_keys à chaque commit dans le dépôt hgadmin. Si le dossier .ssh n'existe pas, le programme ne le crée pas actuellement. Il faut que les droits sur le dossier soient corrects pour que l'authentification par clé fonctionne correctement. Normalement, le RPM de mon dépôt applique la règle SELinux adéquate au dossier .ssh ; mais il arrive que cela échoue. Vérifiez le contexte SELinux du dossier :

$ ls -alZ .ssh
drwx------. hgserver hgserver system_u:object_r:ssh_home_t:s0  .

Si le contexte est bien ssh_home_t, tout est correct. Dans le cas contraire, les commandes suivantes - en root - suffiront (référez-vous à l'article SELinux sur la documentation francophone de Fedora pour en savoir plus) :

# semanage fcontext -a -t ssh_home_t '/var/lib/mercurial-server/.ssh(/.*)?'
# restorecon -R -v /var/lib/mercurial-server/.ssh

Étape suivante : déclarer un utilisateur 'root', au sens de mercurial-server, évidemment. Regardons un peu le contenu du fichier access.conf :

init user=root/**
deny repo=hgadmin
write user=users/**

Examinons un peu ces règles pour comprendre ce que nous allons faire, gardons en tête qu'elles sont lues ligne par ligne, et que la première qui match a gagné :

init user=root/** : accorde les droits init aux utilisateurs dont les clés se trouvent dans le dossier root et ses sous dossiers. L'accès init permet la création de nouveaux dépôts, et implicitement les droits en écriture.
deny repo=hgadmin : interdit l'accès au dépôt hgadmin ; il n'y a donc que les utilisateurs root qui pourront accéder au dépôt hgadmin.
write user=users/** : autorise l'accès en écriture dans l'ensemble des dépôts (hors hgadmin, comme nous venons de le voir) pour les utilisateurs dont la clé se trouve dans le dossier users et ses sous-dossiers.

Créez-vous un dossier spécifique en tant que root, dans lequel vous pourrez placer les clés de vos différentes machines (trasher est ici le login, et odysseus le nom de la machine) :

# mkdir keys/root/trasher
# vim keys/root/trasher/odysseus

Vous placerez dans le fichier odysseus la partie publique de votre clé SSH. Ces instructions sont valables pour configurer mercurial-server côté système ou par le dépôt hgadmin. La différence fondamentale, c'est que le commit déclenchera le hook adapté, et donc la mise à jour du fichier authorized_keys. Ce n'est pas le cas côté système (évidemment ), il faut donc dans ce cas lancer la commande suivante :

# sudo -u hgserver /usr/share/mercurial-server/refresh-auth

Voilà, votre clé est ajoutée, on va pouvoir l'utiliser ! Sur le poste client où est disponible votre clé, vous devriez être en mesure de cloner le dépôt hgadmin :

$ hg clone ssh://hgserver@{host}/hgadmin

Ce dépôt ne comprend rien d'autre au départ que la configuration qui lui est nécessaire. Vous pourrez ajouter ici des dossiers et fichiers selon le même schéma que dans /etc/mercurial-server/

Pour autoriser un nouvel utilisateur nommé toto à accéder à un dépôt spécifique (projet) en écriture, il faudra (par exemple) copier sa clé dans le fichier keys/toto ; et ajouter l'entrée write user=toto repo=projet dans le ficheir access.conf. Le commit déclenchera les hooks adaptés, autorisant l'accès.

Une petite note pour finir : si vous souhaitez rendre vos dépôts accessibles en lecture par le web, ça ne pose aucun problème (même les contextes SELinux permettent ça sans modification particulière). En revanche, une telle méthode lit directement les répertoires sur le disque ; rendant possible la récupération du projet hgadmin ! Afin d'éviter que ça ne se produise, les droits sur ce dépôt particulier sont fixés à 600 lors de la création initiale du dépôt par le paquet RPM ; l'utilisateur apache ne pourra ainsi pas le lire

Ces quelques instructions vous auront permis de commencer à utiliser mercurial-server, la documentation officielle vous aidera à comprendre ses mécanismes pour aller plus loin et exploiter au mieux les possibilités de ce programme.

Goudebaille Fedora

trashy — Thu, 30 Dec 2010 00:21:00 +0100

Depuis un certain temps déjà, je me rend compte que ma motivation s'amenuise et que j'ai de plus en plus de mal à assumer certains rôles que j'ai endossés. Cela est dû principalement à des problèmes d'ordre professionnel, et aussi à un certain désintérêt de ma part pour Fedora ces temps-ci.

Non pas que je renie Fedora, ou que la distribution ou encore sa philosophie ne m'intéresse plus ; mais - pour paraphraser Remi - « Il n'y a plus assez de plaisir » : j'ai fini par m'ennuyer et par ne plus avoir envie de contribuer comme je le faisais jusqu'à présent.

Peut-être que ce sera juste passager, peut-être pas... Je n'en sais encore rien aujourd'hui. J'ai en tous cas annoncé officiellement plus tôt dans la soirée que je cessais de maintenir mes paquets actuels dans les dépôts Fedora. J'ai également annoncé que j'allais cesser de m'occuper de la documentation fedora-fr.org dans le courant du premier trimestre 2011.

Certains des pauvres paquets orphelins que je maintenais jusqu'ici ont dores et déjà trouvé quelqu'un qui prendra grand soin d'eux. Ce n'est malheureusement pas le cas pour tous ; aussi, je vous invite - si vous êtes intéressés - à demander la maintenance de ceux qui n'ont pas encore été récupérés.

Quant à la documentation... C'est une autre paire de manches.

J'entends souvent dire (ou plutôt devrais-je dire « je lis souvent ») : « Je n'ai pas les compétences. ». Bien essayé, jolie excuse. Mais sachez que je ne les ai pas non plus. J'ai commencé à utiliser MediaWiki le jour où nous l'avons installé sur fedora-fr.org pour remplacer l'ancien système (qui était loin d'être satisfaisant). Dans le genre gourou, on a fait mieux
Je ne prétend pas que c'est de tout repos, il y a tout de même un certain temps (voire un temps certain) à consacrer à tout cela de manière occasionnelle ; si tout était simple, ce billet n'aurait même pas lieu d'être !

Enfin, la situation géographique qui est la mienne depuis deux ans (Bordeaux) ne me permettait plus de me déplacer aussi facilement pour les évènements et autres qu'auparavant... Il m'était possible de faire Lille-Paris en une heure... Bordeaux-Paris ; c'est 3 à 4 heures minimum ; c'est ingérable au vu de ma situation professionnelle et familiale. Depuis lors, je n'étais plus vraiment en mesure d'assurer mon rôle d'ambassadeur Fedora ; je ne fais plus partie de cette joyeuse équipe de façon officielle à compter de ce soir.

Finalement, un petit mot sur l'illustration du billet... N'y cherchez pas une signification profonde quelconque, je cherchais juste à illustrer un peu ce billet ; et cette idée de montage m'a fait rire

Fedora-fr : 6 ans déjà !

trashy — Thu, 21 Oct 2010 08:28:00 +0200

Le site Fedora-fr existe depuis un peu plus de 6 ans (il se nommait d'ailleurs à cette époque « fedora-france », mais je ne m'y suis pas inscrit dès le départ. En effet, lors de la sortie de Fedora Core 1 (5 novembre 2003 - ça ne me rajeunit guère !) ; j'utilisais RedHat 9 et j'avoue avoir été un peu frileux à l'idée de changer...

Je me suis décidé à migrer quelque temps après la sortie de Fedora Core 2 (18 mai 2004), une fois l'image d'installation modifiée pour mes besoins (la carte mère que je possédais à l'époque posait problème avec le noyau de base sur le CD d'installation de Fedora Core 2 !!).

Bref... J'ai découvert en cours de route le site de fedora-fr ; et me suis inscrit sur leurs forums, le 21 octobre 2004. J'avais mis un doigt dans l'engrenage. Je ne le savais pas...
C'est à peu près à la même époque que j'ai « redécouvert IRC » (j'avais un peu exploré ça à la fac :-p) via le canal #fedora-fr sur FreeNode. La main était dans l'engrenage...

De fil en aiguille, j'ai commencé à passer de plus en plus de temps sur le canal IRC sur lequel j'ai fini par faire la connaissance de MrTom, à cette époque manager de l'équipe de traduction en français de Fedora. Il a évidemment eut vite fait de m'enrôler à cette tâche ô combien ingrate qu'est la traduction ! Et hop, après la main, le bras...

Je me suis de plus en plus investit dans la communauté francophone de Fedora ; pour finir - en décembre 2005 - par reprendre la responsabilité éditoriale de la documentation, et aider à la maintenance du serveur de Fedora-fr, Borsalino. Ce fut une tâche peu aisée, il fallait d'une part mettre en place l'infrastructure technique adéquate (nous nous somme arrêtés sur l'utilisation MediaWiki alors que le projet Fedora utilisait encore MoinMoin), d'autre part récupérer la documentation existante, et enfin d'ajouter des article et de faire vivre cette partie
Challenge réussi selon moi, la documentation s'est fort bien étoffée depuis lors, je tiens à en remercier chaleureusement tous les rédacteurs passés, présents et à venir pour leur bonne volonté à l'élaboration de cette base de connaissances. Et vous ? <propagande>Est-ce que vous contribuez à la documentation ? Rejoignez-nous ; c'est gratuit ! </propagande>

Bon, là, du côté de l'engrenage, on doit en être à une bonne moitié de ma personne...

Un peu de documentation plus tard, une « Install Party » (désormais nommées « Rencontres Fedora ») a été organisée à Lille. On a sauté dans la voiture de Thomas, on est passés chez un ami prendre un PC sur lequel nous avions installé une jolie Fedora Core 6 toute neuve pour présenter les premières démonstrations de Compiz. Et voilà, ma première IP à Lille ! Aie, une jambe !

Après Lille, Paris, où j'ai eu l'occasion (peut-être devrais-je même dire l'insigne honneur) de rencontrer d'autres membres actifs de la communauté francophone de Fedora... Ce fut aussi l'occasion pour moi de présenter une conférence traitant du support de Fedora. Et pan. L'autre jambe maintenant...

Début 2007, je me suis rendu au Fosdem à Bruxelles, j'ai eu l'occasion d'y faire un point avec Chitlesh sur mes débuts de packageur Fedora (merci à lui pour tout ce qu'il m'a appris !). J'ai également rencontré à cette occasion Pingou, Eddy33, et tant d'autres (que je salue au passage, je ne peux pas faire une liste de toutes les personnes que j'ai rencontrées).

Courant 2007, lors d'une autre install party à paris, j'ai pu présenter une conférence sur le thème de la création de paquets RPM pour Fedora, à l'aide de Remi et de drpixel.

On peut considérer qu'à compter de ce moment, ma tête à fini par passer au travers de l'engrenage... « ~~The Matrix~~Fedora has you ! » Et ce sans avoir suivi aucun pingouin blanc, ni avalé de pilule bleue (humour glauque...).

Depuis, je continue de m'occuper de la documentation francophone de Fedora (j'ai récemment créé un bot qui permet d'interroger la documentation sur IRC, et une page PHP qui permet des recherches plus précises que celles permises de base par MediaWiki), je suis mainteneur ou co-mainteneur de plusieurs paquets dans les dépôts officiels, je prête à l'occasion main forte pour un peu de « développement » HTML/CSS. J'ai en revanche de longue date complètement abandonné la traduction, c'est un aspect des possibilités de contribution qui ne m'a pas séduit sur le long terme malheureusement.

Entre temps, je me suis marié, j'ai eu une petite fille (qui a maintenant deux ans !) - tout ce petit monde étant bien entendu sous Fedora ; et j'essaie de continuer à contribuer à Fedora autant que faire se peut. Peut-être même vais-je essayer de m'atteler à quelque tâche inhabituelle sous peu, l'avenir le dira !

PS : vous pouvez consulter l'historique complet des sorties de Fedora ; et l'historique complet de la vie de de fedora-france/fedora-fr

Recherche dans la documentation francophone de Fedora : la face PHP

trashy — Wed, 26 May 2010 21:47:00 +0200

Il y a quelques jours, je vous annonçais la création et la mise en ligne d'un bot IRC qui permet d'effectuer des recherches dans la documentation francophone de Fedora.
Si votre mémoire est bonne (ou si vous avez suivi le lien de la ligne au dessus :-p) ; vous saurez que j'ai utilisé le moteur de recherche Apache Solr pour arriver à mes fins.

Quelque jours plus tôt encore, je parlais brièvement de l'API PHP pour Solr, ainsi que de la mise à disposition sur les dépôts Fedora (et EPEL !) de l'extension php-pecl-solr.

Il fallait absolument faire quelque chose de tout cela ! Bon... OK... mon côté petit développeur du dimanche à pris le dessus, d'accord...

J'ai donc utilisé l'API PHP/Solr et utilisé l'indexation que j'avais préalablement effectuée pour MrBot afin de produire une interface de recherche un brin plus évoluée que le simple résultat renvoyé sur IRC.
Voici le résultat : http://fedoradoc.ulysses.fr.

Cette interface apporte, entre autres, les fonctionnalités suivantes :

la recherche de termes dans les titres et/ou le texte des articles du wiki,
un « suggest »
la possibilité de filtrer sur une ou plusieurs catégories,
le sur-lignage des termes recherchés dans les résultats,
la présentation d'un extrait de texte qui permet de contextualiser le résultat.

L'intégration de cette « interface » sur le site fedora-fr.org n'est pas à l'ordre du jour pour différentes raisons :

le serveur actuellement en place ne possède pas assez de mémoire vive pour faire tourner les services actuels plus l'index Solr,
je n'ai pas envie de « perdre mon temps » à intégrer ça dans MediaWiki (ça ne m'intéresse vraiment pas d'apprendre à utiliser leur API),
il faut laisser leur chance à d'autres de contribuer,
...

En revanche, j'ai un peu pêché sur le nom de l'application ; j'étais en panne d'inspiration :'( Ça donne donc php-docfr-solrsearch, mais au diable le nom, cela importe bien moins que les fonctionnalités (illustration parfaite de l'expression « se raccrocher aux branches » diront les esprits chagrins)

Bien évidemment, tout le code source est sous licence libre (GPLv3 en l'occurrence), et disponible sur mon dépôt mercurial. Voici quelques liens « agréables », sinon « utiles » :

Bien entendu, les retours, les commentaires constructifs, les patches (on peut toujours rêver), les intégrations à MediaWiki (ben oui, on peut rêver, non ?) sont les bienvenus !

Je suis bien conscient que le fonctionnement actuel n'est pas parfait et que des incohérences et bogues peuvent survenir. Tout ça sera fort certainement corrigé au fur et à mesure.