Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : PenguinLand

Galette dans les dépôts Fedora

Johan Cwiklinski

Il y a quelques jours, j'apprenais que Galette avait été soumis et accepté dans les dépôts Debian (un grand merci à Raphaël pour ça). Cet ajout fait suite au subventionnement, par l'association Debian France, de la version 0.7.5 de Galette :)" class="smiley

Je me suis dit qu'il était désormais grand temps d'officialiser sa présence dans Fedora également, puisque le paquet est prêt depuis... Juillet 2008. J'ai donc soumis une demande de revue officielle pour Galette, qui finira donc (enfin, j'espère !) dans les dépôts Fedora pour les versions 18 et plus.

Vous pouvez bien entendu participer sur cette demande de revue, tester le paquet et plus généralement Galette :)" class="smiley

IIP Image server sous Fedora et RHEL/CentOS

Johan Cwiklinski

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 :)" class="smiley
  • 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...

Johan Cwiklinski

(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 :)" class="smiley

--

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

Johan Cwiklinski

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 :-)" class="smiley Le paquet sera aussi construit et maintenu dans le dépôt EPEL pour RHEL/CentOS/Whatever en version 6.

Dépôt trashy pour Fedora 16

Johan Cwiklinski

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 :-)" class="smiley 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 :

Meilleurs voeux à tous :-)" class="smiley

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

Johan Cwiklinski

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 :-(" class="smiley

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)

Johan Cwiklinski

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 :

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 :-/" class="smiley
  • 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 :-)" class="smiley

gitolite

En plus des explications fournies ici, je vous conseille vivement de consulter la documentation d'installation de gitolite ;-)" class="smiley

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 ;-)" class="smiley

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 ! :-D" class="smiley ) :

$ 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 ;-)" class="smiley ).

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 ;-)" class="smiley 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-commit.sample ./hooks/post-commit
$ chmod +x ./hooks/post-commit

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à :-)" class="smiley 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 ! :-)" class="smiley

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

MrBot : passage à supybot-gribble

Johan Cwiklinski

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 :-)" class="smiley

Installation d'une instance Solr - Fedora-fr

Johan Cwiklinski

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 :-)" class="smiley

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 :-)" class="smiley
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.

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 :

  1. 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...),
  2. copie les fichiers récupérés aux emplacements adéquats (dans le dossier courant, bien entendu),
  3. modifie le fichier de contexte tomcat (solr-tomcat-context.xml) pour adapter les chemins,
  4. 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,
  5. 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 :-)" class="smiley 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/

Page d'accueil de l'application Solr

Le lien vers l'interface d'administration de l'instance devrait vous amener sur une page semblable à : solr-fedora-fr_doc-admin.jpg

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 ;-)" class="smiley

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

Résultats de la recherche Solr network dans les titres

Qui ramène aujourd'hui 7 résultats :-)" class="smiley

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
  • ... :-D" class="smiley

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 :)" class="smiley

Fedora 15 : c'est parti !

Johan Cwiklinski

C'est parti, en ce qui me concerne en tous cas ;-)" class="smiley

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 :-(" class="smiley

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...

Mon bureau gnome-shell

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 :-D" class="smiley

Menu utilisateur

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

Johan Cwiklinski

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 :-)" class="smiley

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 ;)" class="smiley

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

Johan Cwiklinski

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

Johan Cwiklinski

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 :-(" class="smiley
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 ;)" class="smiley

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 :-)" class="smiley

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 :-(" class="smiley

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é :)" class="smiley

mercurial-server sous Fedora

Johan Cwiklinski

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 ! :-)" class="smiley 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 ;-)" class="smiley ).

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 :)" class="smiley ), 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/ :-)" class="smiley

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 ;)" class="smiley

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

Johan Cwiklinski

bye_fedora.jpg 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 :-D" class="smiley
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 ! :-)" class="smiley

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 ;-)" class="smiley

Fedora-fr : 6 ans déjà !

Johan Cwiklinski

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 ! ;-)" class="smiley 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 :-)" class="smiley
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 ! :-D" class="smiley </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 MatrixFedora 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;)" class="smiley

Recherche dans la documentation francophone de Fedora : la face PHP

Johan Cwiklinski

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... ;-)" class="smiley

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) ;-)" class="smiley

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.

French documentation, IRC and searching

Johan Cwiklinski

bochecha on #fedora-fr tells me that would be a good idea to translate my last blog post in english. So, here it is! Thanks to him for his help on the present translation :-)" class="smiley

In march 2008, eponyme annouced arrival on the french IRC channels of a bot he has developped : trustyRC.

For about two years now, trustyRC has endlessly answered to users requests on the french documentation, on the FAS (Fedora Account System), ...

But he's now tired. eponyme is off on new adventures, and two major issues remains with trustyRC:

  • FAS datas has to be updated by hand ; that was rarely achieved (someone has to think of it, and have the guts, we all know that!),
  • search within French Fedora's documentation only asks to Mediawiki and gets an HTML result, although everyone knows that MediaWiki base search is very rather limited, and is simply not functionnal. As such, search results are not as relevant as we would like them to be, but let's not blame that poor trustyRC.

Recently, I've been taking a close look at Apache Solr (a Lucene-based search solution); I've also recently added php-pecl-solr extentsion in Fedora's repositories

solr.jpg

My goal was to index french documentation wiki ; because I know quite well datas and queries (at least from IRC) that are perfomed; that was a good comparison point for me.
Result is quite impressive, Solr's search power is really not comparable to the one a "simple" PHP application like MediaWiki can provide. Solr can, among others, remove special characters (like our beloved 'é', 'è', or 'à' ;-)" class="smiley ), lower case characters, split terms, highlighting, faceting, ... For example, a search on terms like réseau, reseau and network would produce - on the index I'm working on - the same results.

In order to test that indexation and search system, I needed a public querying interface. That was a good opportunity to make some tests against several IRC bots. I've decided to not contribute to trustyRC mainly because I do not have required skills. Instead, I've taken a look and tested several existing python bots; I found a few but only Supybot really satifies me (in fact, that was the only one that did not reconnect every five minutes to freenode network :(" class="smiley ).

The result? A Supybot plugin for French documentation, connected on French IRC Fedora channels, with the name MrBot!

External plugins loaded into this Supybot instance are:

  • the French documentation search plugin (developped by myself, sources are available under BSD license),
  • an (X)HTML validation plugin, just for fun (I've developped it as well, its based on Phenny validation plugin, and code source is also available under BSD license),
  • the Fedora plugin you could use to query FAS and know, for example, who maintains a specific package,
  • the Koji plugin which give some informations against Koji builders,
  • the Bugzilla plugin that displays details on each valid bugzilla URL entered (or with a string like bug #{bug number}).

MrBot usage for the documentation stands as follows:

  • .wiki what I search: search in wiki titles. If that did not return any results, then it will perfom a plain text search automatically,
  • .wiki plain what I search: force plain text search only,
  • .wiki solr {solr query}: query with a Solr request (principally for my testing usage).

Searching with the wiki command will return two links maximum, not showed results count will also be returned.

For most functions, it is possible to ask MrBot in private:

  • /msg MrBot wiki what I search

To check an URL validity against W3C validator:

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

Fedora services querying:

  • .whoowns package: returns package maintainer name (FAS)
  • .fas fasname: returns FAS account informations for the user. You'd probably use these command in private and not on a channel.
  • .branches package: returns active baracnhes list for specified package
  • .what package: returns a brief package description
  • .list Fedora: shows available commands for Fedora plugin

Documentation francophone, IRC et recherches

Johan Cwiklinski

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.

solr.jpg

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 :(" class="smiley ).

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 ! :-D" class="smiley
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

L'API PHP pour Solr en route vers les dépôts...

Johan Cwiklinski

L'API PHP5 pour Solr sera bientôt disponible dans les dépôts officiels de Fedora ! :-)" class="smiley

J'avais il y a peu décidé de tester cette solution, et j'en suis pleinement satisfait ; je donne donc suite en proposant l'extension php-pecl-solr sur les dépôts officiels de Fedora. Pour les plus impatients, les build Koji sont là : http://koji.fedoraproject.org/koji/packageinfo?packageID=10338