Chroniques d'un gnou libre

Aller au contenu | Aller au menu | Aller à la recherche

dimanche, février 10 2013

TradeSchool @ Paris - Session 2

Par glenux le dimanche, février 10 2013, 14:20

Samedi dernier, c'était l'inauguration de la saison 2 de TradeSchool Paris, dans les locaux de Mutinerie Coworking.

Qu'est ce que TradeSchool ? C'est une nouvelle forme d'école en peer-to-peer basée sur le troc. Elle accueille tous les savoirs et savoir-faire sans faire de distinctions entre enseignements académiques et amateurs.

Pour y participer, rien de plus simple. Allez sur leur site et inscrivez-vous : en tant que professeur indiquez votre theme, la date et ce que vous souhaitez comme contrepartie pour le cours et en tant qu'élève, dites ce que vous apportez. C'est tout. :-)

Ci dessous, les slides de mon cours du 4 février, intitulé « Que restera-t-il de notre civilisation numérique » :

P.S: Je vous invite également à suivre TradeSchool sur Facebook qui diffuse des informations complémentaires au site (photos, etc.).

aucun commentaire aucun rétrolien

lundi, juillet 23 2012

rbenv, ruby-build et qtbinding

Par glenux le lundi, juillet 23 2012, 11:01

Comme je vous le disais dans le billet précédent, je travaille actuellement sur Qasim, un modeste outil pour gérer vos montages SSHFS.

Ainsi, récemment, j'abordais avec enthousiasme le développement de l'interface de configuration qui lui manque. Sauf que problème... impossible d'utiliser les bindings Qt sur les versions de ruby installées sur mon système !

La moindre installation de qtbindings au sein de rbenv plantait lamentablement, avec une trace comme ceci :

$ gem install qtbindings
[...]
make[3]: entrant dans le répertoire « /home/warbrain/.rbenv/versions/1.9.2-p320/lib/ruby/gems/1.9.1/gems/qtbindings-4.6.3.4/ext/build »
[ 82%] Building CXX object ruby/qtruby/src/CMakeFiles/qtruby4shared.dir/Qt.o
[ 82%] Building CXX object ruby/qtruby/src/CMakeFiles/qtruby4shared.dir/handlers.o
[ 83%] Building CXX object ruby/qtruby/src/CMakeFiles/qtruby4shared.dir/marshall_types.o
Linking CXX shared library libqtruby4shared.so
/usr/bin/ld: /home/warbrain/.rbenv/versions/1.9.2-p320/lib/libruby-static.a(array.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/home/warbrain/.rbenv/versions/1.9.2-p320/lib/libruby-static.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** [ruby/qtruby/src/libqtruby4shared.so.2.0.0] Erreur 1
make[3]: quittant le répertoire « /home/warbrain/.rbenv/versions/1.9.2-p320/lib/ruby/gems/1.9.1/gems/qtbindings-4.6.3.4/ext/build »

Alors la solution ?

Comme expliqué sur cet autre billet, il s'agit du linker qui veut utiliser une bibliothèque dynamique alors qu'il trouve seulement la versions statique de la bibliothèque : libruby-static.a. De plus si vous regardez dans le dossier d'installation de ruby, vous constaterez que libruby.so est absent...

La solution est simplement de recompiler ruby avec l'option de configuration --enable-shared et de le réinstaller. Cela créera la bibliothèque dynamique manquante en plus de la version statique.

Facile, non ?

Le combo rbenv et ruby-build ... et qtbindings

Il faut d'abord savoir que depuis la dernière fois, j'ai amélioré mon environnement de développement pour ruby et ce faisant j'utilise désormais rbenv.

Qu'est ce que c'est ? rbenv, c'est un outil permettant à un utilisateur de faire cohabiter plusieurs versions de ruby, de passer de l'une à l'autre ou d'en définir une par défaut au niveau d'un répertoire. Pour ceux qui connaissent, c'est à peu près comme RVM, mais en plus propre.

Je vous renvoie à ce tutorial pour les détails de son fonctionnement. C'est vraiment pratique et très efficace, je vous le conseille.

ruby-build est le compagnon idéal de rbenv. Il s'intègre dans ce dernier et permet de compiler et installer à peu près n'importe quelle version de ruby dans l'environnement de rbenv, en une ligne de commande.

Si vous avez déjà installé une version de ruby avec rbenv, voila ce qu'il vous reste à faire :

D'abord supprimer la version problématique (par exemple la 1.9.3-p194)

rm -fr ~/.rbenv/versions/1.9.3-p194/

Ensuite la réinstaller avec les bons paramètres de compilation. À cette occasion j'ai découvert que certaines variables d'environnement comme CONFIGURE_OPTS étaient prises en compte par ruby-build, et c'est très pratique pour ce qui nous intéresse... il suffit donc de taper ce qui suit :

$ CONFIGURE_OPTS="--enable-shared" \
  rbenv install 1.9.3-p194

Changez ensuite votre version de ruby

$ rbenv local 1.9.3-p194

Et enfin installez le gem qui vous embêtait :

$ gem install qtbindings
Fetching: qtbindings-4.6.3.4.gem (100%)
Building native extensions.  This could take a while...
Successfully installed qtbindings-4.6.3.4
1 gem installed
Installing ri documentation for qtbindings-4.6.3.4...
Installing RDoc documentation for qtbindings-4.6.3.4...

Et enfin, ça fonctionne !

Pour les versions anciennes de ruby, préciser quel gcc !

Si vous utilisez la méthode précédente "telle quelle" sur une version plus ancienne de ruby, par exemple la 1.8.7-p358, l'installation de qtbindings risque de mal se passer et vous obtiendrez quelque chose de comme ceci:

$ gem install qtbindings
/home/warbrain/.rbenv/versions/1.8.7-p358/lib/ruby/1.8/timeout.rb:60: [BUG] Segmentation fault
ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux]

Pas terrible donc.

Afin d'éviter cela, au moment de l'installation de ruby, vous devrez également préciser une version du compilateur gcc compatible, via la variable d'environnement CC.

Voila la commande complète.

$ CONFIGURE_OPTS="--enable-shared" CC=gcc-4.5 \
  rbenv install 1.8.7-p358

J'espère que cela vous aura été utile ! N'héstez pas à laisser un petit commentaire si c'est le cas ;-)

aucun commentaire aucun rétrolien

mardi, décembre 27 2011

Qasim, le SSHFS qui vous veut du bien

Par glenux le mardi, décembre 27 2011, 18:13

L'autre jour, j'ai craqué... J'en ai eu marre d'utiliser les gestionaires d'url des deux principaux bureaux gnu-linux (KDE avec KIO/VFS et Gnome avec GIO/VFS) pour accéder à mes fichiers distant sous GNU/Linux. Ceux-ci ne permettaient l'accès aux fichiers qu'aux applications utilisant les mêmes bliothèques ou sinon en les copiant temporairement en local. Pas vraiment satisfaisant... j'ai ainsi lorgné du coté de SSHFS[1].

SSHFS c'est sympa, me dis-je, non seulement à cause de son nom imprononçable, mais aussi parce que c'est basé sur SSH et FUSE.

Petit récapitulatif, de rigueur :

  • SSH, tout le monde connaît, ça permet de se connecter sur une machine distante de façon sécurisée, c'est standard et facile à mettre en place (quand c'est pas installé par défaut).
  • FUSE[2], c'est standard, solide, fourni par le kernel linux et ça permet à toutes les applications d'accéder de façon transparente (sans modification) à un système de fichiers géré par une application. Cette application vous permettra alors de manipuler localement des fichiers distants, mais pourquoi pas aussi les entrées d'une base de donnée ou d'autres choses.

SSHFS est donc un programme fournissant un système de fichiers virtuels basé sur FUSE et utilisant SSH pour manipuler les fichiers distants.

Dans le cas général, ça s'utilise tout simplement. Pour associer le répertoire distant Config au répertoire local mnt/Config, il suffira de taper :

sshfs warbrain@daneel.glenux.net:Config mnt/Config/

En revanche, ça devient un peu moins simple lorsque vous engagez sur le chemin des options pour le port, la compression, le mapping des utilisateurs, le cypher, la re-connexion automatique, le timeout du cache, etc... Surtout lorsque ces options, les répertoires distants et les points de montage doivent varier selon les serveurs.

En général c'est à ce moment qu'on improvise une séance de shell-scripting pour configurer tout ça, selon les serveurs (ne riez pas, je suis sûr que vous l'avez fait aussi ;) ).

Par exemple en écrivant des choses comme ça:

#!/bin/sh
### Connexion au serveur example.com

### Quelques variables (à changer dans chaque script)
remotedir=user@example.com:Somewhere
localdir=~/mnt/Somewhere
remoteport=22

### La commande magique
sshfs \
      -o allow_root \
      -o idmap=user \
      -o uid=`id -u` \
      -o gid=`id -g` \
      -o reconnect \
      -o workaround=all \
      -o cache_timeout=240 \
      -o ServerAliveInterval 15 \
      -o no_readahead \
      -o Ciphers=arcfour \
      -o Port=$remoteport \
      $remotedir \
      $localdir

Et Qasim dans tout ça ?

Qasim intervient le jour où vous souhaitez laisser un utilisateur final accéder à des documents distants via SSHFS. Plus question de ligne de commande, il va falloir trouver un outil graphique...

Et c'est exactement de cela qu'il s'agit ! Qasim est justement une interface graphique (Ruby + Qt) à ces scripts SSHFS.

Cela permet à tout un chacun de monter et démonter les répertoires distants en un simple clic :

qasim.article.1.png

qasim.article.4.png

qasim.article.3.png

Le projet est utilisable, stable mais encore un peu jeune. Il manque notamment les options de paramétrage :

qasim.article.5.png

Par conséquent, pour définir un partage, il faut aujourd'hui définir manuellement des fichier .map dans le répertoire ~/.config/qasim/ ou bien dans /etc/qasim/maps.d/.

Par exemple, pour le partage example.map :

REMOTE_USER=$USER
REMOTE_HOST=example.com
REMOTE_PORT=22

MAP=Example.Documents /home/$USER/Documents
MAP=Example.Media /home/shared-media

Si ce logiciel vous intéresse, les sources sont disponibles sur Github. Un paquet debian est également à votre disposition si vous ajoutez les lignes suivantes à votre /etc/apt/sources.list

deb http://repository.glenux.net/debian/ unstable main contrib non-free
deb-src http://repository.glenux.net/debian/ unstable main contrib non-free

N'hésitez pas à me faire part de vos remarques pour améliorer ce logiciel ! :)

Notes

[1] SSHFS - http://fuse.sourceforge.net/sshfs.html

[2] FUSE - http://fuse.sourceforge.net/

aucun commentaire aucun rétrolien

- page 1 de 21