Le langage C m’a toujours paru difficile à aborder. Non pas au niveau de sa syntaxe, mais au sujet de l’accès à sa documentation et aux librairies disponibles. Pour moi qui suis habitué à Java ou à Python, j’ai regardé Vala comme un moyen de mettre un pied dans le C. Je vais essayé de présenter ma manière de le voir, après avoir fait une petite plongée dedans…

Présentation

Le langage Vala à été créé par les développeurs de Gnome pour qu’ils puissent disposer d’un langage de haut niveau. Gnome ayant eu pendant quelques temps un pied ( dansant ) dans mono, Vala en est très inspiré. ( Je ne connais pas mono et ne peux donc pas lancer de comparatif, je vous renvoie donc à celui présenté par Gnome par rapport à C#, et pour Java ). Le langage est ensuite compilé en C, et GCC est utilisé pour la compilation d’un exécutable.

On est donc dans un langage intermédiaire, qui reste très proche du C comme nous allons le voir par la suite.

Analyse

Langage objet haut niveau

Vala est tout d’abord un langage haut niveau : on y retrouve des interface ( pour pouvoir moduler le code facilement ), des delegate ( qui permettent de de définir un type de fonction pour un callback ), une gestion événementielle ( gérer le déclenchement de plusieurs méthodes dans le code par un appel unique ) … On dispose donc d’un langage objet assez riche pour éviter d’avoir passer du temps sur des détails et se concentrer sur le programme et son déroulement. Il est pensé objet et l’on retrouve vite ses marques, tout comme l’on sent qu’il est assez facile d’« abstraire » le code pour faire une application qui n’en reste pas un simple script…

Je n’ai pas envie de détailler la syntaxe du langage et tout ce qu’il intègre car vous pourrez trouver tout cela en ligne. Je vous renvoie au tutoriel qui explique la structure du langage en détail, qui présentent des exemples détaillés.

La GLib

Le langage est basé sur la GLib, la librairie standard utilisé dans les applications GTK. La plupart des types primitifs ( int… ) sont donc en réalités des types issus de cette librairie ( gint…). On accède ainsi à l’ensemble des méthodes de la GLib, diffusées sous formes de classes objets et bien documentées ( la valadoc ). Cela rejoint l’histoire de Vala puisque La GLib est tout utilisée par les développeurs Gnome ( on constate d’ailleurs que la plupart des composants Gnome ont une entrée dans cette Valadoc ).

Il ne faut cependant pas croire que l’on dispose avec cette bibliothèque standard d’un ensemble de routines aussi riche que dans le package standard d’un Java ou d’un Python : la GLib est avant tout destinée à des développeurs C, et beaucoup des méthodes standard du C n’y sont pas disponibles. Pour parer cela, Vala propose une classe POSIX[LIEN] proposant les méthodes standard du C, mais celle-ci n’est pas exhaustive et il nous arrive souvent de tomber sur une fonction qui ne nous est pas accessible via le langage haut niveau qu’est Vala.

Les Bindings

Pour répondre à cela, propose la possibilité de mettre en place un binding vers une libraire C de manière native. ( Normal me direz vous, le code en sortie de Vala est du C ! ) On peut donc très facilement utiliser n’importe quelle libraire existante. Vala étant un langage objet, il devient donc possible d’utiliser les librairies standard au sein d’un code objet de haut niveau. Cela ne demande que quelques lignes, demandant au minimum le fichier dans lequel se trouve la définition de la méthode, et sa signature.

Exemple du binding définissant la méthode execl ( issue du fichier /usr/share/vala/vapi/posix.vapi ) :

[CCode (cheader_filename = "unistd.h")]
public int execl (string path, params string[] arg);

et voici la signature de la méthode C correspondante :

extern int execl (__const char *__path, __const char *__arg, ...) __THROW __nonnull ((1));

Les types primitifs de la GLib étant basés sur les types primitifs C correspondant, il n’y a pas de problème de cast dans la plupart de cas. Toutefois, Vala utilise des char* pour définir ses string : il est parfois nécessaire de mettre en place faire un cast quand une méthode nous un char[] : même dans le code haut niveau, le C n’est jamais loin…

C’est souvent frustrant de devoir mettre en place un binding pour une fonction disponible en standard dans la libc. Je pense qu’il manque la possibilité d’inclure directement du code C dans le code vala, tout comme il est possible directement de l’assembleur dans du C. Cela permettrait un confort dans l’utilisation qui n’est pas disponible actuellement.

À noter qu’un outil permet de mettre en place ces bindings pour les composants basés sur GObjet ( Gnome toujours… ). De plus de nombreux bindings sont disponibles pour les composants Gnome. Attention, cela n’empêchera pas d’avoir à installer les headers C correspondants !

Les profils

Il est possible d’utiliser des profils de compilation. Cette option encore expérimentale a été mise en place pour répondre à des réclamations de la part des utilisateurs qui voulaient programmer en Vala sans avoir de dépendances envers la GLib. Ainsi, il est possible d’appeler le compilateur avec la syntaxe suivante :

valac --profile posix

ce qui a pour conséquence de réduire le jeu de bibliothèque par défaut à celles disponibles dans la classe POSIX. Cela permet de limiter les dépendances du programmes, mais beaucoup de types standard de Vala deviennent de ce fait indisponible; on sent bien que le langage n’a pas été pensé pour ça.

Conclusion

Pour résumer, je dirais que Vala correspond à ce qu’il annonce : un langage haut niveau pour faciliter la création d’applications Gnome. Dès que l’on cherche à sortir de ce cadre, on se retrouve confronté à des limitations ( qui ne sont bien sûr pas insurmontable ) :

• Pour ceux qui ne cherche pas à travailler sur du code Gnome, embarquement de bibliothèques qui ne nous intéressent pas forcement. ( Bien que sur ce point, la GLib est plutôt standard sur les PCs ayant X d’installés )
• Pour ceux qui cherchent un langage de haut niveau, le C est encore trop présent entre les lignes pour pouvoir l’oublier complètement. D’un autre côté, l’intégration du code C n’est pas toujours évidente puisqu’elle oblige à déclarer des bindings pour des fonctions standards.
• Mais surtout, le fait que l’ensemble des fonctions de la libc ne soient pas encore disponibles oblige à mettre le doigt dans les bindings régulièrement.

Le langage est bien sûr encore amené à évoluer, et les points que je cite ici ne sont pas pour autant rédhibitoires. D’un point de vue totalement subjectif Je trouve le langage simple mais sans trop de saveur. Ça reste un langage objet qui n’est bien sûr pas révolutionnaire; on sent qu’il ne fait que reprendre les concepts des langages qui l’ont inspiré, mais le produit est cohérent, et d’après les benchs génère un code plutôt optimisé ( en rapport avec le temps que l’on pourrait passer à produire le même code en C ). Après, je ne prend pas le même plaisir à programmer en Vala qu’en python ( j’avais bien dit que j’étais subjectif ^^ ).

Cela dit, pour moi, qui ne suis pas un développeur Gnome, je suis plus intéressé par la possibilité d’avoir un langage haut niveau qui reste très proche du C, avec les performances qui vont avec; si le prix pour cela est une dépendance vers la GLib, ça reste un coût sommes toutes assez faible.

Une des particularité est que sa configuration se fait par un fichier de script exécuté au lancement du bureau. Cela permet de paramétrer comme on le souhaite le bureau sans être limité par le WM. La contrepartie est que cela est plus difficile à prendre en main, et une erreur de code entraîne un écran gris au lieu du bureau que l’on souhaite obtenir… Le langage utilisé ( Lua ) est un langage connu pour sa légèreté. Pour l’instant, le projet étant encore assez jeune, il n’existe pas encore beaucoup de modules standardisés pour configurer le système, mais je pense que ceux-ci ne tarderont pas à venir…

Pour l’instant la configuration n’est pas encore stabilisée, certains composants changent au cours d’une version à une autre, ce qui casse parfois la mise à jour et oblige à retravailler les scripts de mise de configuration. Je pense cependant que tout cela suit la bonne direction et que ces soucis finiront par disparaître avec le temps et les versions suivantes

La plupart des actions peuvent être associées à un raccourci clavier, et si il est possible d’affiche une barre d’outil à chaque applications (« titlebar »), on prend vite l’habitude de s’en passer et de tout contrôler au clavier. On est d’autant plus aidé par cela par shifty une extension qui permet de « programmer » la manière dont on veut que les fenêtres s’affichent : sur quel écran, avec quels paramètres etc. Cela permet par exemple d’avoir une configuration pour des applications utilisant plusieurs fenêtres ( je pense par exemple à Gimp ) paramétrée comme on le souhaite…

On prend vite l’habitude également d’utiliser plusieurs « tags » ( l’équivalent de bureaux virtuels mais un peu plus étendus ) : ceux-ci peuvent être paramétrés pour afficher des applications sépicifiques ( j’ai par exemple adapté ma configuration pour que web affiche firefox, ou que news affiche le couple elinks/newsbeuter pour lire mes flux RSS…

Bien sûr le temps de paramétrage au début est un peu long, mais maintenant que l’API est stable, il n’est plus nécessaire de tout reprendre à chaque fois que l’on met à jour awesome.

Je trouvais qu’il manquait à Awesome un menu avec les actions disponibles sur les fenêtres : la faire passer au premier plan, la minimiser… Tout ceci est disponible avec des raccourcis claviers, mais il n’y a pas d’option centralisée pour les retrouver. J’ai donc décidé de me plonger un petit peu dans lua pour produire le menu que voilà :

Le menu permet les actions suivantes :

• On top : Pour mettre le client sélectionné au premier plan et le rendre flottant
• Sticky : Faire apparaître le client sur tous les tags
• Minimize : Réduire le client
• Close : Fermer le client
• Move To : Déplacer le client vers un autre tag

Le script fonctionne avec awesome 3.4.5, les versions antérieures ne sont pas forcement compatibles suite à un changement dans l’ABI du menu. J’essaierai également de le mettre à jour pour les versions suivantes ( du moins tant que je m’en servirai…)

Pour le faire fonctionner, il faut télécharger le script et le placer dans son répertoire ${HOME}/.config/awesome . Ensuite, éditer le fichier rc.lua et y ajouter la ligne suivante en en-tête :

require("mymenu")

et dans la partie Key Binding :

clientkeys = awful.util.table.join(
[…]
    awful.key({ modkey,           }, "Down",    function(c) menu_instance = newAppMenu(c)    end),

Le menu apparaîtra sur le raccourci Mod4 + Flèche du bas

Le fichier :
mymenu.lua

Ma copine m’a demandé de trouver une solution simple pour échanger des fichier avec sa sœur, msn posant des problèmes… J’ai pensé à mon serveur ssh et mettre en place une connexion sftp pour ça. Sur le principe cela a été adopté avec une petite présentation de filezilla (je ne sais pas s’il existe des clients sftp intégrés sous windows ?), j’ai donc commencé à mettre en place le système.

De mon côté, la condition principale est de n’autoriser les connexions que par clef publique ( pas de mot de passe ),  ma copine a tenu à ce que sa sœur ne puisse pas accéder aux documents présents dans son home, et du mien à ce que l’on ne puisse pas pour autant se promener dans l’arborescence du serveur : il va donc falloir chrooter l’environnement.

Il existe pas mal de documentation la dessus sur internet, mais je me suis souvent retrouvé face à des exemples incorrects ou incompatible avec le fait de passer par une clef publique, je vais donc détailler les problèmes rencontrés.

Le compte + clef publique

La première étape est de créer le compte, cela se fait assez simplement :

# adduser ${user}

et en répondant aux questions par défaut… Vient ensuite la clef publique : filezilla gère les clefs privés au format ppk ( putty ) et je n’ai pas trouvé d’outil pour les générer sous windows. Je suis donc passé par wine + puttygen pour créer la clef. Une fois celle-ci crée, on enregistre la partie publique et la partie privée de la clef.

La clef publique va être enregistrée dans le fichier ${user}/.ssh/know_host sur le serveur pour autoriser le client à s’y connecter. La clef privée sera enregistrée de son côté au format ppk pour être utilisée par filezilla (il est possible à partir de ce fichier de générer une clef privée de type openssh ).

Intégrer la clef privée dans FileZilla

Il faut ensuite intégrer la clef privée dans filezilla en passant par les paramètres : elle sera automatiquement lue à la connexion ( il faut choisir «interactive» dans le type d’authentification ). ( Attention : sous windows j’ai rencontré des problèmes avec un répertoire contenant des accents, la clef semblait être lue, mais la connexion ne se faisait pas pour autant. )

Chrooter l’environnement

Aujourd’hui il est possible de chrooter nativement un environnement sftp avec openssh. Il faut pour cela mettre en place une condition sur l’utilisateur ( ou le groupe ) pour faire le chroot :

Match user ${user}
   ChrootDirectory /var/chroot/
   X11Forwarding no
   AllowTcpForwarding no
   ForceCommand internal-sftp

Dans cet exemple le chemin /var/chroot sera utilisé comme racine lors des connexions sftp. Ce répertoire doit être détenu par root:root et avoir les droits 755. Cela veut dire que si notre utilisateur à pour répertoire home /home/${user}, il se retrouvera dans /var/chroot/home/${user} lors des connexions sftp. Il est nécessaire de conserver le répertoire home de l’utilisateur pour que ssh accepte une connexion par clef. En effet, lorsque l’utilisateur va se connecter, ssh va lire dans son répertoire personnel pour lire le fichier .ssh/know_host et autoriser ou non la clef qui se présente. Ce qui signifie que si l’on modifie le répertoire personnel, il faut aussi déplacer cette arborescence ( hors de question dans ce cas de mettre / comme racine de l’utilisateur ).

À noter : j’ai préféré faire le match sur le nom de l’utilisateur plutôt que sur son groupe ( le groupe sera utilisé par ailleurs ). Dans le cas où nous avons plusieurs utilisateurs, il est possible de les mettre à la suite ( séparés par des virgules ).

J’ai vu de nombreux tutoriaux qui indiquent comme répertoire de chroot « /home/%u » ( le répertoire de l’utilisateur standard ), et qui demandent de changer le répertoire de login de l’utilisateur par « / ». Je pense que c’est une très mauvaise idée : d’une part parce que cela oblige à déposer les clefs à la racine du serveur, mais aussi à cause de la contrainte d’openssh demandant à ce que le répertoire root soit détenu par root : cela veut dire que l’utilisateur n’a pas le droit de déposer de fichiers ou de créer de répertoires dans son propre home !

Le plus simple est donc de prendre un autre répertoire pour l’échange, et laisser le home de l’utilisateur pour la configuration. ( Cela permet aussi d’être sûr que le répertoire .ssh ne sera pas effacé par erreur par l’utilisateur… ) J’ai donc mis un lien symbolique pour lier le /home de l’utilisateur avec son répertoire d’échange :

# mkdir /home/${user}/echanges
# ln -s /var/chroot/home/${user} /home/${user}/echanges

On retrouvera ainsi la possibilité de voir les fichiers déposés en passant par le /home de l’utilisateur ( même si ce dernier ne pourra pas y aller… )

Isoler l’environnement

Maintenant que nous avons empêché l’utilisateur de se balader sur l’ordinateur, nous allons l’empêcher de se balader dans les autres répertoires des utilisateurs : cela se fait en une ligne de commande (pour chacun des répertoires que nous allons ouvrir en sftp : )

# for fichier in /var/chroot/home/*; do chmod o-r ${fichier}; done

Et voilà ! Les utilisateurs peuvent voir qu’il existe d’autres comptes que le leur, mais ne peuvent pas y accéder.

Autoriser le partage

Maintenant que nous avons fermé les droits de manière générale il nous reste à autoriser le partage des fichiers ( après tout c’était le but de la demande !) de manière plus fine. Cela implique pour moi deux choses :

1. permettre à un autre utilisateur d’accéder aux données présentes
2. permettre à un autre utilisateur de déposer ( ou de supprimer des donnée )

Pour le premier point, c’est facile il suffit d’ajouter l’utilisateur A au groupe de l’utilisateur B :

# usermod -a -G ${user} ${un_autre_utilisateur}

Et l’utilsateur un_autre_utilisateur pourra donc accéder à l’ensemble des fichier pour les lire ( et éventuellement les rapatrier chez lui).

Pour le second point ( possibilité d’écrire et modifier ) c’est un peu plus compliqué; en gros nous voulons que les fichiers déposés par sftp dans le répertoire de l’utilisateur ait comme groupe d’appartenance celui du propriétaire du répertoire ( quel que soit l’utilisateur qui dépose ) et qu’ils soient modifiable par le groupe ( g+w ) du propriétaire.

Par exemple : l’utilisateur A dépose un fichier dans le répertoire d’échange de l’utilisateur B. Il faut que les droits de ce fichier se présentent ainsi une fois le transfert terminé :

$ ls -l fichier
-rw-rw----  1 utilisateurA utilisateurB

( ainsi l’un et l’autre pourront supprimer le fichier ).

Pour cela nous allons utiliser une « bidouille » de l’os : le sgid bit. Derrière ce nom barbare se trouve un marqueur qui permet de fixer le droit de tous les fichiers qui seront créés dans le répertoire ( plus d’info ici ). Pour le déterminer on passe par chmod :

# chmod g+s /var/chroot/${user}

Cela détermine bien quel est le groupe qui sera propriétaire du fichier, mais cela ne donne pas à ce groupe le droit de le modifier pour autant ! Sous linux, c’est la commande umask qui permet de déterminer les droits des fichiers. Le problème est qu’il s’agit d’une commande lié à l’environnement de l’utilisateur, et non pas aux répertoires sur lesquels nous travaillons ( à moins de passer par les ACLs mais cela est déjà assez compliqué comme ça… ). Ici, nous sommes dans un environnement sftp, sans shell de login, donc sans possibilité d’exécuter la commande directement, il faut que ce soit le serveur sftp qui le configure. J’ai trouvé énormément de documentations ( la plupart des bidouillages ) pour contourner le problème, mais la solution la plus simple vient de la dernière version d’OpenSSH (5.4 ) sortie le 8 mars dernier.

Exemple de configuration

Une nouvelle option sur le serveur sftp permet d’indiquer quel est l’umask qui sera appliqué ( dans notre cas 002) : dans le fichier/etc/ssh/sshd_config nous allons configurer les paramètres par défaut du serveur sftp :

Remplacer :

Subsystem sftp /usr/lib/openssh/sftp-server.sh

par :

Subsystem sftp /usr/lib/openssh/sftp-server -u 002

Pour définir les droits umask qui seront appliqués par défaut pour toutes les connexions sftp par défaut. Ce paramétrage est à redéfinir pour les paramétrages personnalisés ( bloc Match ) :

ForceCommand internal-sftp -u 002

Conclusion

Nous avons un environnement bien hermétique, pouvant gérer l’augmentation du nombre de compte ( il suffit de refaire les chmod dans notre environnement chrooté  à la création du compte ), et hermétique. Le paramétrage côté serveur est effectivement assez lourd au début, mais je pense que la mise à jour ne demande pas trop de travail, et on gère les droits de manière assez fine ( en passant par les groupes ce qui me semble être dans la mentalité unix ).

Pour le client, il n’y a pas grand chose à paramétrer ( récupérer la clef et l’intégrer ), et il n’y a aucun risque que celui-ci vienne casser son paramétrage. On peut même sauvegarder sa clef privée dans son home (le vrai ), au cas où il perdrait le fichier.

La plupart des articles que l’on peut voir sur le net qui concernent l’utilisation du PC sous Linux restent limités à un point : souvent ils oublient le fait que plusieurs utilisateurs puissent être enregistrés sur le PC, et que tous ne soient pas forcément des administrateurs ( ceux qui peuvent avoir des droits root sur la machine ).
Pourquoi donc ? Est-ce que cela signifie que la plupart des linuxiens sont les seuls à utiliser le PC ? C’est possible, mais là n’est pas mon sujet. Je pense que le problème est que les utilisateurs sont pour l’instant invisible de la littérature sur Linux que l’on peut trouver sur le net. À la fois invisible du côté des distributions, et invisible du côté des communautés.

Le problème se retrouve présent dans deux aspects : d’une part dans la documentation s’adressant aux administrateurs, et d’autre part dans la documentaiton s’adressant aux utilisateurs.

Si l’on suit les manipulations que l’on peut trouver un peu partout sur le net, on trouve souvent des modifications qui ont pour conséquences de modifier la configuration générale du système, et l’on trouve plus souvent des modifications dans /etc/ que dans ~/.config/

Suivre les besoins des utilisateurs

Tous les utilisateurs n’utilisent pas forcément l’ordinateur de la même manière et il faut prévoir quels sont leurs besoin avant de se lancer dans une opération générale.
Par exemple, il n’y a pas longtemps était paru sur le planet-libre un article sur privoxy qui se terminait par une manière élégante d’utiliser privoxy sans configuration supplémentaire[1]. Or privoxy est lent pour traiter les sites puisant des ressources un peu partout — par exemple google news ou planet-libre (!) et se transformer en inconfort pour l’utilisateur.

Les mises à jour

Faire une mise à jour est toujours quelque chose de périlleux, et l’on ne sait pas forcément comment le système va réagir; entre le logiciel qui ne fonctionne plus car sa configuration a changé ou celui qui ne fonctionne plus car un bug a été introduit dans la nouvelle version, les risques sont possibles ( je n’ai par exemple pu plus lire de dvd lors de la mise à jour du noyau 2.6.30[2]… )
Je ne veux pas relancer le débat sur le packaging des distributions ( rolling release contre version fixes) mais le problème doit être posé : comment être sûr en faisant une mise à jour que l’on ne va pas casser tel composant ?

En plus des modifications générales sur la configuration que peuvent introduire les modifications, on peut se retrouver dans la situation inverse : l’utilisateur n’a pas le droit de visualiser les fichiers de logs, d’installer un paquet ou de modifier un fichier de configuration et ne pourra donc pas suivre la documentation qu’il peut trouver ici et là sur le net.

Pouvoir utiliser ses propres applications ?

Les distributions n’ont pour l’instant pas de solutions pour gérer l’installation de paquets par un utilisateur normal ( qui irait s’installer dans /opt// par exemple ), pouvant être installés sans droit root, et ne pouvant être exécutés que par l’utilisateur ayant fait son installation.

Utiliser des commandes non root

En fait, ce système que l’on nous décrit ouvert ne l’est réellement que si l’on est admin dessus. Pour les autres, la manipulation se limite à bash, python…
Dans la documentation, on trouve même des exemples demandant à l’utilisateur d’être root alors qu’une commande équivalente peut être lancée par un utilisateur normal ( par exemple $netstat -ie au lieu de #ifconfig )

Ce problème de l’utilisateur non root est pour l’instant contourné ( par exemple en configurant sudo dès l’installation ), mais il reste posé, et n’est jamais attaqué de front.

Le fait que cette situation ne soit jamais évoquée est pour moi significative de l’utilisation faite de linux aujourd’hui : bien loin du grand public. Nous sommes tous ici des utilisateurs bidouilleurs, et ne voyons pas forcément une utilisation quotidienne d’un utilisateur standard. Je ne veux pas en faire une généralisation sur l’avenir de Linux et une remise en cause nécessaire. Je pose juste ici un constat sur une situation qui est pour moi, encore trop souvent invisible.

[2] Artisan Numérique » Se prémunir des « SpyWebs » avec Privoxy
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557340

Pour répondre à tout cela, nous allons mettre en place un système de backup sur disque dur externe, qui se lancera à chaque fois que notre disque sera monté. À chaque fois que le disque dur sera allumé, la sauvegarde s’enclenchera. Cela ne garantie pas, bien sûr que les sauvegardes se feront à un intervalle régulier, mais cela garantie au moins que nous n’aurons pas à nous en soucier. Pour cela nous allons utiliser les outils qui sont disponibles sous un environnement Linux : rsync et hal. Cet article nous présente une base pour faire notre sauvegarde Une sauvegarde améliorée avec rsync. Nous allons juste devoir le modifier un petit peu pour répondre à un problème qui arrive souvent avec les périphériques USB : selon que d’autres périphériques sont déjà montés ou non, nous ne savons pas dans quel répertoire nous allons nous trouve. Il va donc falloir mettre en place une ligne pour récupérer le répertoire dans lequel nous sommes. Il ne nous reste plus qu’à trouver le moyen de l’éxécuter automatiquement pour cela nous allons utiliser halevt. Le script est disponible ici

Comme son nom l’indique, halevt est un gestionnaire d’évènements pour hal. Hal est un gestionnaire d’évènement matériel sous Linux; il envoie des informations à chaque fois que des informations sont envoyées depuis les composants. Cela permet de détecter le branchement d’un périphérique USB et de le monter sur le bureau ( et qui nous simplifie grandement la vie aujourd’hui !!!). Halevt est un démon à l’écoute des informations qui nous sont envoyées par hal, et d’activer des actions en conséquence : par exemple pour lancer l’antivirus sur la clef usb, reconfigurer le mappage du clavier en fonction de la marque que l’on branche etc. Pour notre part, nous allons nous contenter de lancer un script (celui du backup mentionné plus haut ).

Pour commencer nous allons devoir identifier le lecteur à mettre sous surveillance : inutile de se baser sur les noms de montage habituels ( /dev/sda par exemple ) en effet en fonction des périphériques déjà branchés nous n’allons pas obtenir la même configuration. Nous allons utiliser les point de montage défini dans /dev/disk/by-uuid qui permet d’obtenir l’identifiant de notre disque (et qui sera repris par la suite dans la configuration de hal ). Une fois que nous avons relevé quel est le disque concerné, il faut mettre en place une entrée pour notre évènement dans la configuration de halevt :

<halevt:Device match="hal.block.device &amp; hal.block.is_volume = true &amp; hal.volume.uuid = fd20536f-7b80-4a80-8c3d-b5bebe8fb484">
<halevt:Property name="hal.volume.is_mounted">
<halevt:Action value="true" exec="bash $hal.volume.mount_point$/chemin/script/backup-ssh.sh"/>
</halevt:Property>
</halevt:Device>

Cela si halevt est exécuté avec les droits de l’utilisateur lançant le backup. Si on le fait tourner en démon, il faut trouver une autre solution ( sur mon poste j’ai utilisé sudo, mais on peut très bien se baser sur le sticky bit pour donner les droits au script ). De même, dans la configuration mise en place, le script se trouve sur le disque de stockage ( de manière à pouvoir le lancer à la main si le démon n’est pas disponible ), cela peut être adapté en fonction de chacun…

Dans le cas d’une configuration multi-utilisateur, je pense qu’il est nécessaire de passer par un script qui lance les différentes sauvegardes sous le bon groupe de l’utilisateur à chaque fois. ( Ce qui en plus permet d’éviter le problème du sudo ) mais je n’ai pas eu besoin d’aller jusque là pour l’instant ! À vous d’adapter ce que je vous propose en fonction de votre configuration !

There are a lot of tutorials about how to configure cwiid. I let you follow them for getting a functionnal system for your wiimote. You can read the links at the end of this article. Be sure your system works well before continuing.

Thiis is a code that we’ll use as template for the creation of our driver. Used as main, it use pygame for displaying the infrared sources the wiimote can detect, but it is also compatible as plugin for wminput ( even if it does anything for now ).

You can get it here : wm_control.py ( This code is licenced under GPL 3+ )

About the code :

    import wmplugin

This import does not exist, but is created by wminput when executed. It provide the connexion with the wminput core. Just put ( or link ) the script in the wminput plugin path ( on my debian this is the /usr/lib/cwiid/plugins/ )

def wmplugin_init(id, wiimote_arg):
    wmplugin.set_rpt_mode(id, cwiid.RPT_IR | cwiid.RPT_BTN)
    return

def wmplugin_info():
    return [], \
      [("X", wmplugin.REL | wmplugin.ABS, 1024, 0, 0, 0), \
       ("Y", wmplugin.REL | wmplugin.ABS, 768, 0, 0, 0)], \
    []

We instanciate the wiimote object here and configure it in the IR mode. The name is choosen by wminput if we want to use it as plugin. We define that the plugin return the coordonates X and Y in a relative system ( you can get the signification of all the parameters here : actions list)

If we want to define new butons, we just have to name them in the first list, the’ll be accessible in the configuration file as plugin.[buton_name] = ACTION

def wmplugin_exec(messages):
    '''Wiimote callback managing method
    Recieves a message list, each element is different, see the libcwiid docs'''
    x = y = 0

    for msg in messages:
        if msg[0] == cwiid.MESG_IR:
            x, y = ir_sensor.get_movement(msg)
    return [], (x, y)

Here is the core of our driver. The name is choosen by wminput too, as the format value we return. We have in parameter the list of the messages the wiimote has sent.

If we have defined buton we need to return their state here. It is a boolean saying if the buton is pressed ( True ) or not ( False ).

This method doesn’t send any others parameters, and this is a problem when we need to store data between two calls ( ie for saving the cursor position ). One way for passing throught is to use global variables. But it is unelegant and can cause problems if we want to use our code in imports. So we’ill use a list as default parameter and let python save it as you can see here :

>>> def meth(a=[]):
...     a.append(1)
...     print a
...
>>> meth()
[1]
>>> meth()
[1, 1]
>>> meth()
[1, 1, 1]

So the ir_sensor.get_movement method is defined with each parameter we want to save as an optional list

def get_movement(msg, _old_points=[], _old_position = [0, 0]):
    return 0, 0

The get_movement method need to return the difference between the old position of the cursor and the new one in tuple : (0, 0) mean that the cursor didn’t move, (-10, 0) mean a deplacement to the left.

For now, the plugin doesn’t move the cursor, and doesn’t read what the wiimote has sent. But you know everything for creating your own plugin for controlling your wiimote.
You can use all the cwiid method for setting the led, activating the differents modes of your wiimote ( IR, Acc, rumble … ), and define here your own actions.
I’ll explain the core of the movement analysis in IR mode in the next article.

Links :
The cwiid project

Install Cwiid ( Ubuntu Documentation )

La quadrature du net lance un appel à la mobilisation contre le projet de loi Hadopi qui vise à réguler le « piratage » sur le net. non seulement en mettant en place la riposte graduée ( qui conduit à couper l’accès à internet ), mais en autorisant l’enregistrement et l’analyse des différentes communications qui transitent sur le réseau. A la base instaurée pour répondre à la demande des artistes pour lutter contre le piratage, cette loi va plus loin et permet des dérives qui font peur : à l’heure ou nos communication par téléphone, ou notre courrier ou nos sources d’informations passent par internet, il est important de protéger notre espace et de le défendre.

Malheureusement, j’ai l’impression que personne ne chercher à protéger sa liberté sur le net. Les campagnes d’information sur les données personnelles n’empêchent pas les individus de continuer à s’inscrire massivement sur facebook ou d’utiliser msn pour communiquer, par commodité et par pratique, mais en oubliant que derrière tout ces services, il y a un prix à payer : celui de notre anonymat et de notre liberté.

A l’heure il il devient anormal de chercher à protéger sa vie privée même « si l’on n’a rien à se reprocher », je pense qu’il faut rappeler à tous, que cet espace qui peut sembler si loin, si distant de notre vie, est en fait incrusté dans nos domicilies, nos consoles de jeux ou nos téléphones, et mettre en place des mesures de contrôles sur le net permettent de réduire très facilement les libertés de l’individu

Facilement car :

• Ce contrôle se fait en silence : il est fait de manière automatique sans que l’individu ne s’en rende compte. La dérive étant que l’on ne sait plus très bien quelle est la limite entre ce qui est contrôlé et ce qui ne l’est pas.
• Ce contrôle est global : avec la puissance des machines, il devient possible de surveiller l’ensemble des connexions des internautes, et de voir tout ce qui transite sur les réseaux.
• Ce contrôle est permanent : pour les même raisons.

Avant qu’il ne soit interdit d’utiliser un logiciel non conforme, essayons de préserver notre liberté et d’affirmer ce que nous défendons.

• Accéléromètres
• Caméra infrarouge
• Émetteur/Récepteur Bluetooth
• 11 boutons

( voir le détail sur la page de wikipédia )

En disposant d’un récepteur bluetooth, il est possible de se connecter à la télécommande et de récupérer ses informations, mieux, avec le projet cwiid, on peut transformer la wiimote en souris !

Ainsi selon le mode dans lequel se trouve la télécommande, on contrôle notre curseur en inclinant la télécommande, ou en la pointant vers une source infrarouge

La source infrarouge pouvant être la sensor bar fournie avec la console, ou une source externe, bougie lampe ou tout ce dont pouvez disposer diffusant de la chaleur à partir d’un point unique

Le pilote fourni avec cwiid fonctionne mais n’est pas optimisé. Il arrive que la souris parte dans une direction incontrôlée, ou de ne pas pouvoir accéder à certaines parties de l’écran.

La faute est due au pilote intégré qui se contente juste de placer le pointeur sur la source infrarouge, avec quelques petites optimisations.
En effet, le capteur de la wiimote nous indique quelle est la position de toutes les sources infrarouges perçues ( et nous fourni également des informations sur leur intensité ), mais la conversion en pointeur est laissée au pilote :
Quelle source choisir comme référence ?
Comment gérer les cas où une source est sortie du champ de vision ?
Comment réagir quand cette source revient dans le champ de vision ?

Tout ceci doit être pris en compte pour pouvoir offrir une ergonomie au curseur et faciliter le contrôle.

Heureusement pour nous le pilote nous donne la possibilité de réécrire nos propres moteurs, et donc de gérer nous même la manière dont on veut que la souris réagisse. Nous avons même le choix dans le langage ! En effet, nous pouvons choisir entre offrir un plugin compilé ( le pilote est écrit en C ), ou l’écrire en python. C’est cette deuxième option que je vais présenter dans les articles qui suivront.

Suite : mise en pace du plugin (EN)

La question des réceptions répond à une fonction sociale depuis longtemps, et marque un point structurant la socialité, étant associées à des moments de fête et de relations entres individus. Il n’est pas surprenant que ces fêtes soient organisées de manières différentes selon les catégories sociales qui y participent et qu’elles suivent des normes différentes. Ce dont je vais parler ici touche les fêtes organisées par des populations proches du milieu étudiant, jeunes et dans une situation qui n’est pas financièrement stable. Elles ont pour point commun de demander aux invités de se charger d’apporter ce qui concerne l’apéritif et les boissons, et de laisser l’hôte préparer le repas.

Le don

M. Mauss nous à présenté la logique du don et les règles qui y sont associées. Pour que cette logique fonctionne, il y a en effet des règles à respecter qui permettent d’en assurer la cohésion au fil du temps. Il est ainsi nécessaire de :

• Ne pas refuser le don qui nous est fait
• Rendre un objet de nature équivalente à celui qui nous à été donné
• Différer dans le temps ce contre-don
• etc.

Le don ne doit pas forcément être d’une grande valeur, mais doit entrer dans cette logique de l’échange. Dans notre cas des soirées organisées, on conçoit mal quelqu’un souhaitant repartir avec la bouteille qu’il a apporté pour le repas. De même, cela serait remarqué que l’on ramène à un ami les biscuits qu’il nous avait apporté lors de la soirée qu’il organise quelque temps après nous. Par contre la circulation n’interdit pas de les apporter à une autre personne lorsque l’on se fait inviter par des personnes qui ne participaient pas à l’échange qui avait précédemment eu lieu…

Cette circulation oblige le participant à jouer le jeu, selon le principe des règles sociales, ou il peut être mal vu qu’une personne répète trop souvent un manquement dans cette circulation; la règle est transgressée mais celle-ci ne reposant que sur la bonne fois des participants, rien ne peut être reproché à quiconque…

En fait pour moi, c’est plutôt boulot dans la journée et transport entre chien et loup, mais il n’empêche, ça me plaît. J’ai juste envie de dire que je suis bien. J’aimerai que le temps s’écoule plus lentement, avoir davantage le temps de me poser, profiter et ne rien faire.

Il n’empêche, c’est l’automne, le temps ralenti, tout tourne plus lentement, et j’ai envie d’en profiter.