Cet article fait suite à la réalisation de mon installation électrique solaire autonome. Je suis très content de celle-ci, seulement j’ai un grand besoin de maîtrise, et ne pas savoir tout ce qui se passait dans ces petites boîtes bleues me taraudait… Il fallait que je monitor. Coup de chance, les appareils Victron que j’ai installés peuvent se connecter à un ordinateur avec les câbles VE Direct USB.

En bon libriste que je suis, j’ai vite découvert OpenEnergyMonitor project. J’ai failli craquer pour un emonPi – Solar PV mais ça ne correspondait pas complètement à mes contraintes. J’ai donc pris mes petits doigts et j’ai pondu PvMonit.

PvMonit C’est quoi ?

PvMonit c’est donc un petit logiciel de monitoring photovoltaïque pour matériel Victron compatible Ve.direct (USB), particulièrement adapté pour les installations autonomes. Il permet une vue « en direct » et un export de l’historique vers emoncms (une branche d’OpenEnergyMonitor project).

Exemple d’usage de PvMonit (le mien) : je dispose d’un RaspberryPi (mini ordinateur qui ne consomme que ~3W), mes appareils Victron (MPTT, BMV) sont connectés avec des câbles VE.Direct USB. PvMonit est installé sur ce RaspberryPi et me permet :

• D’afficher les informations en temps réel sur une page web (local)
  • Une copie de cette page est faite toutes les heures (si la connexion internet est allumée) et est accessible ici : http://demo.zici.fr/PvMonit/
• De collecter les données toutes les X minutes et les expédier vers emoncms quand internet est là (le wifi n’étant pas toujours allumé)
  • Mon tableau de bord est visible ici : http://emoncms.mercereau.info/dashboard/view?id=1

Des images :

Installation de PvMonit

Le matériel

Il vous faudra pour suivre ce tuto :

• Un ordinateur faible consommation configuré sous Debian ou un dérivé type Ubuntu/Raspbian (j’ai fait un article sur l’installation de mon Raspberry PI)
• Les câbles Ve.Direct USB connectés à vos appareils
• En option :
  • Une sonde de température USB pour contrôler la température du local où vivent les batteries. J’utilise « thermomètre USB TEMPer » qui coûte entre 5 et 20€, (ils en parlent ici)
  • Une pince ampèremètre USB pour contrôler la consommation de l’habitat. J’utilise la Aviosys 8870 à 27€ quand même, mais il ne semble pas y avoir beaucoup de concurrence pour ce type de produit… (j’en parle ici)

Voici le schéma de mon installation avec le câblage pour PvMonit incorporé :

Et voilà dans la vraie vie :

Le logiciel : Installation de PvMonit

Requis

• Linux (le tutoriel ci-dessous est prévu pour Debian/Rasbian/Ubuntu like)
• PHP (5.5-5.6 recomended)
• Lighttpd/Apache (ou autre serveur web)
• Perl
• Python

Installation

PvMonit dispose de deux fonctions dissociées et indépendantes que je vais distinguer :

• Interface en temps réel
• Export vers emoncms

Il y a bien sûr une base commune :

La base / le socle

Installation de PvMonit via le dépôt git et de ses dépendances :

aptitude install php5-cli git python-serial sudo
cd /opt
git clone https://github.com/kepon85/PvMonit.git
cp config-default.php config.php```

Vous pouvez maintenant éditer le fichier config.php à votre guise !

Test du script vedirect.py : branchez un appareil Victron avec un Câble Ve.Direct USB et voici un exemple de ce que vous devriez obtenir (Ici un MPTT BlueSolare branché sur le ttyUS0)

$ /opt/PvMonit/bin/vedirect.py /dev/ttyUSB0 
PID:0xA04A
FW:119
SER#:HQ********
V:25660
I:500
VPV:53270
PPV:14
CS:3
ERR:0
LOAD:ON
H19:3348
H20:1
H21:17
H22:33
H23:167
HSDS:52

Pour comprendre chaque valeur, téléchargez la documentation Victron VE Direct Protocol documentation : https://www.victronenergy.fr/support-and-downloads/whitepapers

Interface web en temps réel

Installation des dépendances :

aptitude lighttpd php5-cgi 
lighttpd-enable-mod fastcgi
lighttpd-enable-mod fastcgi-php

Configuration du serveur http, avec le fichier /etc/lighttpd/lighttpd.conf :

server .document-root        = "/opt/PvMonit/www"
server.pid-file             = "/var/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80
index-file.names            = ( "index.html", "index.php")
url.access-deny             = ( "~", ".inc" )
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

On applique la configuration :

service lighttpd restart

On ajoute ensuite la possibilité à l’utilisateur exécutant lighttpd de lancer les script avec sudo sans mot de passe :

Lancer la commande :

visudo

Ajouter la ligne suivante :

+ www-data ALL=(ALL) NOPASSWD: /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl, /opt/temperv14/temperv14 -c, /usr/bin/python /opt/PvMonit/bin/vedirect.py /dev/tty*

C’est terminé, vous pouvez vous connecter sur votre IP local pour joindre votre serveur web :

Export vers emoncms

Connectez-vous à votre interface emoncms hébergée ou créez un compte sur emoncms.org et rendez-vous sur la page « Input api » https://emoncms.org/input/api :

Récupérez la valeur « Accès en écriture » et ajoutez-la dans le fichier de configuration Pvmonit /opt/PvMonit/config.php :

- $EMONCMS_URL_INPUT_JSON_POST='https://emoncms.chezvous.org/input/post.json';
- $EMONCMS_API_KEY='XXXXXXXXXXXXXXXXXXXXXXXX';
+ $EMONCMS_URL_INPUT_JSON_POST='https://emoncms.org/input/post.json';
+ $EMONCMS_API_KEY='????VOTRE API KEY?????';

Création d’un utilisateur dédié avec pouvoir restreint

adduser --shell /bin/bash pvmonit

Installation des dépendances :

aptitude install lynx

On ajoute ensuite la possibilité à l’utilisateur exécutant l’export de lancer les scripts avec sudo sans mot de passe :

Lancer la commande :

visudo

Ajouter la ligne suivante :

+ pvmonit ALL=(ALL) NOPASSWD: /opt/temperv14/temperv14 -c, /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl, /usr/bin/python /opt/PvMonit/bin/vedirect.py /dev/tty*Ajout de celle-ci dans le fichier  */opt/PvMonit/config.php* :

Test de collecte :

$ su - pvmonit -c /opt/PvMonit/getForEmoncms.php
2016-11-02T10:55:30+01:00 - C'est un MPTT, modèle "BlueSolar MPPT 100/30 rev2" du nom de MpttBleu
2016-11-02T10:55:30+01:00 - Les données sont formatées comme ceci : V:26180,I:800,VPV:56360,PPV:21,CS:3,ERR:0,H19:3352,H20:5,H21:51,H22:33,H23:167
2016-11-02T10:55:31+01:00 - C'est un MPTT, modèle "BlueSolar MPPT 100/30 rev2" du nom de MpttBlanc
2016-11-02T10:55:31+01:00 - Les données sont formatées comme ceci : V:26200,I:600,VPV:53630,PPV:18,CS:3,ERR:0,H19:1267,H20:4,H21:46,H22:17,H23:201
2016-11-02T10:55:31+01:00 - Après correction, la température est de 11.88°C
2016-11-02T10:55:31+01:00 - Tentative 1 de récupération de consommation
2016-11-02T10:55:32+01:00 - Trouvé à la tentative 1 : la La consommation trouvé est 00.1A
2016-11-02T10:55:32+01:00 - La consommation est de 00.1A soit 23W

Test d’envoi des données :

$ su - pvmonit -c /opt/PvMonit/sendToEmoncms.php 
2016-11-02T10:56:44+01:00 - Données correctements envoyées : 1, données en erreurs : 0

Mettre les scripts en tâche planifiée

crontab -e -u pvmonit

Ajouter :

+# Script de récupération des données, toutes les 5 minutes
+/5 * * * * /usr/bin/php /opt/PvMonit/getForEmoncms.php >> /tmp/PvMonit.getForEmoncms.log
+# Script d'envoi des données, ici toutes les 1/2 heures
+3,33 * * * * /usr/bin/php /opt/PvMonit/sendToEmoncms.php >> /tmp/PvMonit.sendToEmoncms.log

Je n’explique pas ici comment configurer emoncms, les flux pour obtenir de beaux dashboard, je vous laisse lire la documentation…

Voici, pour exemple, mon dashboard : http://emoncms.mercereau.info/dashboard/view?id=1

Sonde température (option)

J’utilise la sonde thermomètre USB TEMPer, cette sonde fonctionne avec le logiciel temperv14 qui est plutôt simple à installer

apt-get install libusb-dev libusb-1.0-0-dev unzip
cd /opt
wget http://dev-random.net/wp-content/uploads/2013/08/temperv14.zip
#ou un miroir
#wget http://www.generation-linux.fr/public/juin14/temperv14.zip
unzip temperv14.zip
cd temperv14/
make

Test de la sonde :

$ /opt/temperv14/temperv14 -c
18.50

Ajout de celle-ci dans le fichier /opt/PvMonit/config.php :

- $TEMPERV14_BIN='';
+ $TEMPERV14_BIN='/usr/bin/sudo /opt/temperv14/temperv14';

Autres documentations à propos de cette sonde :

• http://www.generation-linux.fr/index.php?post/2014/06/21/Relever-et-grapher-la-temp%C3%A9rature-de-sa-maison-sur-Debian
• http://dev-random.net/temperature-measuring-using-linux-and-raspberry-pi/

Pince ampèremétrique (option)

J’utilise la pince ampèremétrique USB Aviosys 8870 pour mesurer ma consommation électrique.

Le petit script perl (/opt/PvMonit/bin/ampermetre.pl) est très simple pour lire la pince ampèremétrique, qui sera branchée en USB et apparaîtra dans votre système sur le port /dev/ttyACM0

Celui-ci dépend de la librairie serialport :

aptitde install libdevice-serialport-perl

Test : :

$ /opt/PvMonit/bin/ampermetre.pl 
00.1A

Ajout de celle-ci dans le fichier /opt/PvMonit/config.php :

- $AMPEREMETRE_BIN = '';
+ $AMPEREMETRE_BIN = '/usr/bin/sudo /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl';

Documentation

• Victron VE Direct Protocol documentation : https://www.victronenergy.fr/support-and-downloads/whitepapers

Voilà voilà, bon courage !

Original post of David Mercereau.Votez pour ce billet sur Planet Libre.

J'ai récupéré un vieux Dell sur lequel j'ai installé ma distribution et mon environnement graphique habituels (Archlinux / Openbox). L'idée est d'en faire un PC à emmener partout. Hum... et à oublier partout ! Donc il faut pour le moins protéger ses données, pour que son éventuelle perte ne permette à quiconque d'explorer nos documents et/ou mots de passe Internet. La solution est évidement le chiffrement, et tout est expliqué sur cette page du wiki d'Archlinux. Mais comme c'est en anglais et que tout ne m'était pas aussi évident que je l'espérais voici un compte rendu de cette opération.

État des lieux :

Archlinux à jour, utilisateur(s) créé(s), mots de passes définis (et solides, il serviront au chiffrement), répertoires personnels créés (et non vides, pour pouvoir tester), suffisamment de place dans la partition dans laquelle est monté /home (environ 2,5 fois plus que la taille du plus gros répertoire à chiffrer). Une bonne sauvegarde ne peut pas nuire. Même si une copie du répertoire sera faite par l'outil de migration (sous la forme /home/USERNAME.xxxxxxx) avant chiffrement, pourquoi ne pas essayer clonezilla ?

Programmes à installer :

# pacman -S ecryptfs-utils rsync lsof pam_mount

Programmes à installer :

# pacman -S ecryptfs-utils rsync lsof pam_mount

Préalable pour pouvoir se relogger facilement :

l'idée est évidement que le répertoire personnel soit monté en clair dès le login. Pour cela nous allons utiliser pam_mount :

1) éditer le fichier /etc/security/pam_mount.conf.xml

2) éditer le fichier etc/pam.d/system-auth

Chiffrement proprement dit :

Démarrer le système sans se logger en tant qu'utilisateur. Depuis le gestionnaire de connexion (lightdm chez moi) passer en console (Alt Ctrl F2) et ouvrir une session root. On peut aussi se logger sur le compte d'un autre utilisateur et passer root dans une console, ce qui permet de profiter de l'environnement graphique et du copier/coller.

Monter le module ecryptfs puis lancer la commande de chiffrement

# modprobe encryptfs
# ecryptfs-migrate-home -u username
INFO:  Checking disk space, this may take a few moments.  Please be patient.
INFO:  Checking for open files in /home/USERNAME
Enter your login passphrase [USERNAME]:

../.. (défilé des fichiers en cours de chiffrement)

Some Important Notes!
1. The file encryption appears to have completed successfully, however,
USERNAME MUST LOGIN IMMEDIATELY, _BEFORE_THE_NEXT_REBOOT_ TO COMPLETE THE MIGRATION!!!

2. If USERNAME can log in and read and write their files, then the migration is complete,
and you should remove /home/USERNAME.5ZJvW3ds.
Otherwise, restore /home/USERNAME.5ZJvW3ds back to /home/USERNAME.

3. USERNAME should also run 'ecryptfs-unwrap-passphrase' and record their randomly generated 
mount passphrase as soon as possible.
4. To ensure the integrity of all encrypted data on this system, you should also encrypt swap space
with 'ecryptfs-setup-swap'.

Attention :

$ ecryptfs-unwrap-passphrase

Considérations sur l'ordre de la procédure

En cas de problème

rm -rf /home/USERNAME 
rm -rf /home/.ecryptfs 
mv /home/USERNAME.xxxxxxxx /home/USERNAME

Si tout va bien

Changement de mot de passe

#changer le mot de passe du login
passwd
#changer le mot de passe de chiffrement
ecryptfs-rewrap-passphrase ~/.ecryptfs/wrapped-passphrase

Autres documentations

Original post of Vincent Gay.Votez pour ce billet sur Planet Libre.

D’un côté on nous présente les développeurs comme les maîtres du monde, ceux qui tiennent les rênes des sacro-saints algorithmes tous puissants qui régissent l’univers, de l’autre, dans le monde de l’informatique la même personne est un pisseur de code placé en mission par un marchand de viande. Plus qu’un avis tranché sur la vérité qui doit se trouver quelque part entre les deux, je voulais partager cette constatation afin que chacun puisse se faire sa propre idée.

Tous ceux qui connaissent un peu l’informatique que ce soit à titre de loisir ou professionnel savent à quel point on peut passer pour des extra-terrestres pour ceux qui n’y comprennent rien. On ne cesse de rabâcher dans les médias que le numérique est partout et gère toute notre vie, si les non-utilisateurs se résument à une frange de plus en plus faible de la population, la proportion de ceux qui comprennent comment cela fonctionne ne semble pas augmenter même (et surtout) parmi les jeunes qui n’ont jamais eu à taper une ligne de commande pour faire démarrer un jeu ou un logiciel (et comprendre pourquoi ça ne marchait pas).

Alors forcément, quand on ne comprend pas, on remet (littéralement) sa vie entre les mains de ceux qui comprennent et font tourner. On en serait presque arrivé au point où "l’informaticien" serait le guérisseur, le prêtre ou le chaman des civilisations anciennes. Celui qui sait et peut faire quelque chose pour notre sort. Mais je m’égare du sujet principal, le code. Pour avoir exercé dans le métier quelques années, j’ai un peu vu l’envers du décor. On nous parle de génies qui créent des révolutions ou des empires (tous les systèmes d’exploitation et services ont le leur) mais cela vient souvent uniquement de l’idée géniale de départ et de la façon de la mettre en place.

Si certains développeurs se font plaisir à monter de nouveaux projets et d’autant plus dans le monde du logiciel libre où cela peut être à leurs heures perdues et mis à disposition de tous, le boulot en lui-même n’est pas toujours palpitant : trouver des bugs, apporter des modifications ou des améliorations, essayer de tout faire tenir ensemble jusqu’au moment où il faut tout réécrire parce que les nouvelles fonctionnalités ou les nouveaux outils nécessitent une refonte complète.

Lorsque je suis entré dans ce métier (au début des années 2000), c’était après quelques mois de formation afin d’aller faire les modif nécessaires dans les systèmes obsolètes mais toujours utilisés par les grandes entreprises (et pas des moindres puisqu’elles étaient les premières à avoir informatisé leur production dans les années 70-80 comme les industries ou les banques) afin de pouvoir passer à l’Euro. Est-ce que cela a changé ? Pas sûr puisque maintenant des écoles comme Simplon.co transforment en quelques mois un chômeur en développeur d’appli mobiles. Les objectifs ont changé mais il y a toujours des besoins à pourvoir pour pisser du code.

Hormis quelques développeurs plus géniaux que d’autres qui trouvent des algorithmes bien chiadés, le code se résume à utiliser des morceaux qui font déjà ce qu’on souhaite, à accéder à des bases de données, à faire des tests pour garder celles que l’on souhaite, à faire des tris, à calculer, à afficher, à enregistrer dans les bases... reste ensuite à tester pour voir si ça fait bien ce qu’on veut.

Car il ne faut pas se leurrer, ce genre de boulot, s’il requiert de reconvertir en quelques mois des gens qui cherchent du boulot, c’est qu’il n’est pas intéressant (techniquement et/ou financièrement) pour les développeurs fraîchement émoulus des écoles spécialisées et qui ne jurent que par d’autres technologies (dont l’espérance de vie ne dépassera peut-être pas la décennie). Et lorsque l’on commence à bien se débrouiller pour faire de la maintenance et un peu de développement, on passe vite au niveau architecture : écrire ce que d’autres devront coder. Si on le fait correctement, ça prend autant de temps que de le faire en code, sauf qu’on n’a pas à le tester et voir qu’on avait oublié un ou deux détails qui compliquent les choses, nécessitent des contournements, voire ne marchent pas (à non, cette donnée-là n’est plus renseignée, on fait autrement).

Finalement, les développeurs (ainsi que les administrateurs systèmes) sont comme les artisans : plombiers, électriciens, mécaniciens... Ils ouvrent le capot pour voir ce qu’il y a dessous et pour brancher ou réparer des tuyaux, des fils ou des moteurs. Ils ont un savoir-faire et une compréhension pour savoir comment ça doit marcher et trouver où il faut intervenir. Cette capacité, tout le monde ne l’a pas et n’en a pas besoin au quotidien, il faut juste que ça marche et que chacun fasse son boulot. Mais elle n’est pas plus ésotérique ou plus compliquée (sauf qu’elle est dématérialisée puisque numérique). Et quand l’artisan monte en expérience, il fait les devis (parce qu’il sait ce qu’il faut faire et la complexité de la chose) et il supervise et/ou fait faire par ses ouvriers. Il est bon car il sait comment ça marche et a une vision d’ensemble ; il saura détecter là où il y aura des problèmes et comment corriger un problème.

Alors, certes, le codeur fait des choses dont dépendent la plupart de nos activités quotidiennes mais au même titre que les artisans. Ils n’ont ni à être loués ni à être dénigrés, on a besoin d’eux si on ne sait pas faire. La question ensuite est de savoir à quel point on dépend d’eux et les technologies que l’on utilise pour savoir si elles sont ouvertes ou pas. Changer un phare sur une voiture devient parfois une véritable épreuve tout comme modifier un paramètre de son environnement de bureau. Peut-être que ça mérite réflexion ?

Original post of alterlibriste.Votez pour ce billet sur Planet Libre.

Original post of genma.Votez pour ce billet sur Planet Libre.

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Debian LTS

J’ai commencé à travailler le mois dernier sur le paquet tiff3, mais je n’ai pas eu suffisamment de temps pour compléter la mise à jour. Il s’est avéré que les problèmes étaient suffisamment épineux pour que personne ne prenne le relai. En conséquence, j’ai recommencé à travailler sur tiff3 et tiff ce mois-ci, passant l’intégralité des 13 heures allouées sur ces deux paquets.

J’ai soumis des rapports de bogue pour des problèmes non encore remontés sur le suiveur de bogues (n°842361 pour la CVE-2016-5652, n°842046 pour les CVE-2016-5319/CVE-2016-3633/CVE-2015-8668). J’ai marqué plusieurs CVE comme n’affectant pas tiff3, dans la mesure où ce paquet n’embarque pas d’outils, a contrario du paquet source « tiff ».

Dans la mesure où l’amont a décidé d’abandonner plusieurs outils plutôt que de corriger leurs failles de sécurité, j’ai également opté pour leur retrait. Avant de faire cela, j’ai recherché les dépendances inverses de libtiff-tools, afin de m’assurer qu’aucun des outils supprimés n’était utilisé par d’autres paquets (ce que le mainteneur semble confirmer).

J’ai rétroporté les patchs amont pour les CVE-2016-6223 et CVE-2016-5652.

Mais le plus clair du temps a été passé sur les CVE-2014-8128, CVE-2015-7554 et CVE-2016-5318. Je pense qu’il s’agit là de plusieurs variantes d’un même problème, ce que l’amont semble penser également, puisqu’il a créé une sorte de meta-bogue pour les suivre. Je me suis inspiré d’un patch suggéré dans le ticket n°2499, que j’ai un peu généralisé en essayant d’ajouter les données du tag pour tous les tags manipulés par les divers outils. Ce fut un processus laborieux, car il y a de nombreux tags qui sont utilisés à de nombreux endroits. Ceci étant, cela a marché comme prévu. Je ne parviens plus à reproduire les erreurs de segmentation avec les fichiers qui posaient problème.

J’ai demandé de l’aide sur la liste de diffusion pour passer en revue/tester le résultat, mais n’ai pas eu beaucoup de retour. Je vais bientôt pousser les paquets mis à jour.

Distro Tracker

J’ai noté une augmentation soudaine du nombre d’adresses email automatiquement désinscrites du suiveur de paquets Debian, et j’ai reçu quelques requêtes de rejet (« bounces »). Il s’avère que le suiveur de bogues a relayé beaucoup de spams, auxquels étaient attachés des fichiers exécutables. Spams qui ont donc été rejetés par Google (et non pas simplement mis de côté). Ce qui est regrettable… il y a peu de chance que le flux de spams se tarisse, et il n’y a pas non plus de raison d’attendre de Google qu’il change de comportement. Je n’ai donc eu d’autre choix que d’essayer de rendre le gestionnaire de rejet plus intelligent, ce que j’ai fait : j’ai mis en place une liste d’expressions régulières qui vont annuler un rejet. En d’autres termes, une fois que le rejet correspond à l’une de ces expressions, celui-ci n’est plus pris en compte dans le déclenchement de la désinscription automatique.

Travaux Debian divers

Rapports de bogue créés Dans le ticket n°839403, j’ai suggéré la possibilité de définir directement l’indice de priorité d’une source dans le fichier sources.list. Dans le n°840436, j’ai demandé au mainteneur du paquet selenium-firefoxdriver de faire le nécessaire afin que son paquet non-libre soit compilé automatiquement.

Empaquetage J’ai parrainé la version 2.0.2-0.1 de puppet-lint, et passé en revue le paquet rozofs (que je viens juste de parrainer dans experimental, pour commencer).

Publicité Je maintiens le compte Debian sur Twitter et Facebook. J’ai utilisé twitterfeed.com jusqu’à présent, mais ce dernier est en train de fermer. J’ai suivi leurs recommandations et basculé vers dlvr.it, de sorte à ce que les entrées soient automatiquement reprises depuis le fil micronews.debian.org. Dans le rapport de bogue n°841165, j’ai remonté le fait qu’il manque aux chroots créés par sbuild-createchroot les entrées IPv6 habituelles créées par netbase. Dans le ticket n°841503, j’ai consigné un problème que j’ai constaté de nombreuses fois (dans Debian et Kali) lors de mises à jour d’une installation cryptsetup typique.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in October 2016 contribuée par Weierstrass01.

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

Original post of Raphaël Hertzog.Votez pour ce billet sur Planet Libre.