PROJET AUTOBLOG


®om's blog

Site original : ®om's blog

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Authentification automatique à un réseau WiFi avec NetworkManager

dimanche 31 juillet 2011 à 11:43

Certains réseaux WiFi sont ouverts (sans clé de sécurité) mais nécessitent une authentification. C’est souvent le cas des points d’accès dans les gares, les hôtels, les campings… Cela concerne également les réseaux ouverts tels que FreeWifi.

Une fois connecté à un tel réseau, lorsqu’avec votre navigateur vous tentez d’accéder à n’importe quel site, vous êtes redirigé vers une page d’authentification demandant votre identifiant et votre mot de passe (parfois il ne s’agit que d’accepter des conditions d’utilisation). Après avoir renseigné ces informations, vous êtes authentifié et pouvez accéder à Internet normalement.

Mais il faut avouer que s’authentifier manuellement à chaque connexion est pénible. D’autant plus que la redirection HTTP vers la page d’authentification ne fonctionne… que pour HTTP. Ainsi, alors que vous êtes connecté au réseau Wifi, votre client mail ne parviendra à récupérer les mails, votre client XMPP n’arrivera pas à se connecter au serveur… mais sans message indiquant la cause du problème.

Le but de ce billet est de mettre en place une authentification automatique lors de la connexion au réseau.

Authentification en ligne de commande

La première étape est de pouvoir réaliser cette authentification en ligne de commande, à partir de l’identifiant et du mot de passe. C’est très simple, il suffit d’imiter ce que fait le navigateur lors du clic sur le bouton Valider.

Pour cela, deux choses sont nécessaires : l’URL de la page de validation d’authentification et les champs de formulaire qu’elle utilise.

Pour les connaître, il faut regarder le code source de la page sur laquelle vous êtes redirigés, en particulier la balise form. Voici un exemple de ce que vous pouvez obtenir (le HTML n’est pas toujours super propre sur ce genre de pages) :

<form method="post" action="http://10.9.0.1:8000/">
Login <input name="auth_user" type="text">
Password <input name="auth_pass" type="password">
<input type="checkbox" name="regagree" value="valeur"
onClick="ChangeStatut(this.form)"> J'accepte le règlement
<input name="redirurl" type="hidden"
value="http://www.google.com/search?ie=UTF-8">
<input type="submit" name="accept" value="Continuer" disabled>
</form>

Tout y est. La valeur de l’attribut action est l’URL de validation, et le nom des champs utilisés est dans l’attribut name de chaque balise input.

Dans cet exemple, seuls auth_user et auth_pass semblent utiles, mais parfois le serveur effectue des vérifications (étranges) supplémentaires. Ici, il vérifie qu’il y a bien un attribut accept qui vaut Continuer (allez savoir pourquoi).

À partir de ces champs, nous allons construire la chaîne des paramètres sous la forme :

champ1=valeur1&champ2=valeur2&champ3=valeur3

et l’envoyer au serveur en POST, par exemple grâce à la commande POST (en majuscules, ça surprend un peu pour une commande shell) :

POST http://10.9.0.1:8000/ <<<
'auth_user=IDENTIFIANT&auth_pass=MOT_DE_PASSE&accept=Continuer'

Si la page d’authentification est en HTTPS, il faudra installer le paquet libcrypt-ssleay-perl, ou alors utiliser wget :

wget -qO- https://10.9.0.1:8000/
--post-data='auth_user=IDENTIFIANT&auth_pass=MOT_DE_PASSE&accept=Continuer'

Voilà, nous avons reproduit en ligne de commande le comportement du navigateur pour l’authentification. Nous devons maintenant faire en sorte que cette commande soit exécutée dès la connexion au réseau WiFi.

Exécuter un script lors de la connexion

NetworkManager (le gestionnaire de connexion par défaut d’Ubuntu) permet d’exécuter des scripts lors de la connexion ou la déconnexion. Pour cela, il suffit de placer le script dans /etc/NetworkManager/dispatcher.d/ et de le rendre exécutable.

Le script est appelé avec deux paramètres :

Nous voulons exécuter la commande POST uniquement lors de la connexion de wlan0, et seulement pour le réseau concerné (par exemple celui ayant le nom MonLieuDeVacances).

Il est possible de récupérer le nom du réseau (l’ESSID) auquel nous sommes connectés grâce à iwconfig :

iwconfig wlan0 | grep -o 'ESSID:".*$' | sed 's/^ESSID:"\(.*\)".*$/\1/'

Il faut donc créer un script dans /etc/NetworkManager/dispatcher.d/10auth :

sudo vi /etc/NetworkManager/dispatcher.d/10auth

ayant cette structure :

#!/bin/bash
if [ "$1 $2" = 'wlan0 up' ]
then
    essid=$(iwconfig wlan0 | grep -o 'ESSID:".*$' | sed
's/^ESSID:"\(.*\)".*$/\1/')
    case "$essid" in
        'MonLieuDeVacances')
            POST http://10.9.0.1:8000/ <<< 'auth_user=IDENTIFIANT&auth_pass=MOT_DE_PASSE&accept=Continuer' ;;
        'MaGare')
            POST http://192.168.0.1 <<< 'accept_cgu=1' ;;
    esac
fi

Et le rendre exécutable :

sudo chmod +x /etc/NetworkManager/dispatcher.d/10auth

Script pour FreeWifi

Les pages d’authentification varient d’un réseau à l’autre, il faut donc adapter les paramètres de connexion selon le service utilisé.

Voici le script à utiliser (en adaptant votre identifiant et votre mot de passe) pour le réseau FreeWifi (très connu) :

#!/bin/bash
if [ "$1 $2" = 'wlan0 up' ]
then
    essid=$(iwconfig wlan0 | grep -o 'ESSID:".*$' | sed 's/^ESSID:"\(.*\)".*$/\1/')
    case "$essid" in
        'FreeWifi')
            wget -qO- https://wifi.free.fr/Auth --post-data='login=IDENTIFIANT&password=MOT_DE_PASSE' ;;
    esac
fi

Tunnel SSH

Ces réseaux ouverts, gérant éventuellement une authentification HTTP, ne sont pas chiffrés : n’importe qui écoutant ce qui transite dans les airs pourra récupérer tout le contenu de votre trafic. Si vous avez un ordinateur allumé chez vous (sur un réseau “sûr”) accessible en SSH, je vous conseille de faire passer toutes les connexions dans un tunnel chiffré.

Le principe est simple : dès que vous accédez à un serveur (par exemple en tapant l’URL dans un navigateur web), l’ordinateur ne va pas s’y connecter directement, il va transmettre les informations en passant par un tunnel chiffré à votre serveur SSH, qui lui va s’y connecter, et vous renvoyer la page à travers le tunnel. Techniquement, le tunnel est un proxy SOCKS écoutant sur un port local (par exemple localhost:3128).

Pour démarrer le tunnel :

ssh monserveur -CND3128

Pour configurer le système afin qu’il utilise le tunnel SSH, Système → Préférences → Serveur mandataire (gnome-network-properties), puis configurer comme sur la capture d’écran :

proxy

Dans l’onglet Hôtes à ignorer, rajouter l’adresse de la page d’authentification.

Ainsi, toutes les connexions des logiciels utilisant les paramètres proxy du système passeront par le tunnel. Il est également possible de configurer ceci dans chaque logiciel individuellement (s’ils le proposent).

Pour Firefox, il est également recommandé dans about:config de passer la variable network.proxy.socks_remote_dns à true, afin que les DNS soient résolus également de l’autre côté du tunnel (sur le réseau “sûr”).

Vous trouverez plus d’infos sur mon billet concernant SSH.

Conclusion

La connexion à des points d’accès WiFi publics demandant à chaque fois une authentification ou une acceptation des conditions d’utilisation devient rapidement insupportable. Il est donc appréciable de l’automatiser.

De plus, ces réseaux ne sont pas “sûrs”, n’importe qui peut écouter le trafic. Il est donc nécessaire de le chiffrer en passant par un réseau de confiance, par exemple avec un tunnel SSH.

Extraire les recherches Google des logs Apache

vendredi 24 juin 2011 à 13:10

Aujourd’hui, c’est un billet de distraction pour geeks.

Lister les recherches

Si vous utilisez Apache, voici une commande qui liste dans l’ordre alphabétique les recherches Google ayant permis aux internautes d’arriver sur vos sites :

php -r "echo urldecode(\"$(zgrep 'http://www\.google\.\w*/' /var/log/apache2/*|grep -o '[?&]q=[^&"]*'|cut -c4-)\");"|sort|uniq -c

EDIT 25/06/2011 : cette commande semble échouer lorsque la liste des recherches est trop longue, celle donnée à la fin du billet est donc à préférer.

(pour les autres moteurs de recherche, il faudrait s’inspirer de ce qu’ont fait les développeurs de Piwik)

Voici à quoi ressemble le résultat de la commande :

      1 ubtunu tiny tiny rss
      5 ubuntu
      1 ubuntu 10.04 change startup screen
      1 ubuntu 10.04 configurer compte messagerie hotmail dans couriel
      3 ubuntu 10.04 cryptage
      1 ubuntu 10.04 écran grub invisible au démarrage
      2 ubuntu 10.04 ecran noir nvidia 
      1 ubuntu 10.04 et video nvidia
      1 ubuntu 10.04 grub nvidia
      1 ubuntu 10.04 grub-pc couleur
      4 ubuntu 10.04 installation partition home chiffrée

Le texte correspond aux recherches, le numéro devant indique le nombre de fois où elles ont été effectuées.

Analyse

Billets les plus recherchés

Sans conteste, les deux billets qui amènent le plus d’internautes par Google concernent pluzz et apk.

Et parfois ça ne doit pas les aider beaucoup : certains recherchent par exemple “pluzz plus belle la vie” dans Google à partir d’Internet Explorer, je ne suis pas sûr que mon script shell pour pluzz réponde à leurs attentes.

Recherches insolites

Dans la liste, il y a forcément des recherches drôles ou étranges. En voici quelques unes que j’ai trouvées dans mes logs :

Il y a certains sites qui s’amusent à référencer ce genre de recherches, par exemple Comment devenir un ninja gratuitement ?

N’hésitez pas à poster les vôtres…

Challenge

J’ai essayé d’écrire la commande la plus courte possible. Je n’ai pas réussi à faire moins de 129 caractères sans perdre d’information ou prendre plus de risque (par exemple on pourrait remplacer apache2 par a*2, mais c’est plus risqué).

Par contre, cette commande ne fonctionne pas correctement si l’on rajoute |less (on ne peut pas se déplacer avec haut et bas), je ne sais pas trop pourquoi ni comment le résoudre (si certains ont une idée).

Une autre commande, sans php (en 141 caractères), ne pose pas ce problème :

zgrep 'http://www\.google\.\w*/' /var/log/apache2/*|grep -o '[?&]q=[^&"]*'|cut -c4-|echo -e $(sed 's/$/\\n/;s/+/ /g;s/%/\\x/g')|sort|uniq -c

Si vous avez des astuces pour faire mieux que 129 (ou 141), ne vous gênez pas ;-)

Scripts

D’autres ont fait des scripts plus complets, qui permettent de récupérer des informations supplémentaires, par exemple la page sur laquelle l’internaute est arrivé en effectuant cette recherche…

Tiny Tiny RSS : auto-hébergement des flux RSS

mardi 14 juin 2011 à 12:11

Je vais expliquer dans ce billet pourquoi et comment installer Tiny Tiny RSS, un gestionnaire de flux RSS) sur son serveur.

Motivations

Pourquoi un serveur ?

Il existe de nombreux clients d’agrégateurs de flux, tels que Liferea sous Gnome ou NewsFox dans Firefox.

Cependant, un tel client pose principalement deux problèmes.

Un gestionnaire de flux doit donc, d’après moi, forcément être hébergé sur un serveur.

Pourquoi son serveur ?

De nombreux services en ligne proposent la gestion de flux RSS (Google Reader, NetVibes, etc.).

Pourquoi donc héberger un tel service sur son propre serveur ?

Installation

Je vais expliquer l’installation de Tiny Tiny RSS pour ma configuration, à savoir Ubuntu Server 11.04, avec Apache et MySQL. Je vais l’installer dans ~/flux (le répertoire flux de mon home), avec un lien symbolique /var/www/flux. L’application sera accessible à partir de flux.rom1v.com. Adaptez ces valeurs selon vos besoins.

Dépendances

Tiny Tiny RSS a besoin de php5-curl :

sudo apt-get install php5-curl

Téléchargement

Télécharger la dernière version en bas de la page officielle (actuellement la 1.5.4).

Extraire l’archive dans ~/ :

tar xzf tt-rss-1.5.4.tar.gz

Et renommer le répertoire :

mv tt-rss-1.5.4 flux

Base de données

Il faut ensuite initialiser la base de données, grâce aux scripts fournis. Pour cela, aller dans le répertoire des scripts :

cd flux/schema

Puis se connecter à MySQL :

$ mysql -uroot -p
Enter password:

Une fois connecté, créer la base de données flux :

mysql> CREATE DATABASE flux;
Query OK, 1 row affected (0,00 sec)

Puis créer un utilisateur flux avec les droits sur cette base (on pourra générer son mot de passe grâce à pwgen) :

mysql> GRANT ALL PRIVILEGES ON flux.* TO flux@localhost IDENTIFIED BY 'unmotdepasse';
Query OK, 0 rows affected (0.04 sec)

Initialiser la base de données :

mysql> USE flux
Database changed

mysql> \. ttrss_schema_mysql.sql

La base de données est prête.

Configuration

Retourner dans le répertoire ~/flux :

cd ..

Copier le modèle du fichier de configuration :

cp config.php-dist config.php

Puis l’éditer, par exemple :

vim config.php

Modifier les informations de connexion à la base de données :

        define('DB_TYPE', "mysql");
        define('DB_HOST', "localhost");
        define('DB_USER', "flux");
        define('DB_NAME', "flux");
        define('DB_PASS', "unmotdepasse");

Modifier l’URL d’accès à l’application, pour moi :

        define('SELF_URL_PATH', 'http://flux.rom1v.com');

Désactiver le mode utilisateur unique (sans quoi l’accès à l’application sera public sans authentification) :

        define('SINGLE_USER_MODE', false);

Si Tiny Tiny RSS est installé à la racine du site (c’est mon cas : flux.rom1v.com/), il faut modifier le répertoire d’icônes, car /icons est réservé par Apache :

        define('ICONS_DIR', "tt-icons");
        define('ICONS_URL', "tt-icons");

Je conseille de désactiver la vérification des nouvelles versions, car lorsque le site de Tiny Tiny RSS ne répond plus, l’application rencontre des difficultés :

        define('CHECK_FOR_NEW_VERSION', false);

Pour les performances, activer la compression :

        define('ENABLE_GZIP_OUTPUT', true);

Enfin, une fois que la configuration est terminée, modifier la ligne :

        define('ISCONFIGURED', true);

Les modifications du fichier de configuration sont terminées.

Maintenant, renommer le répetoire icons (comme dans le fichier de configuration) :

mv icons tt-icons

Serveur web

Il faut maintenant héberger l’application sur Apache.

Tout d’abord, donner les droits à www-data sur les répertoires où il a besoin d’écrire :

sudo chown -R www-data: cache tt-icons lock

Puis faire un lien symbolique vers le répertoire /var/www/ :

sudo ln -s ~/flux /var/www/

Créer (au besoin) un nouveau VirtualHost pour le site, dans le répertoire /etc/apache2/sites-available (pour moi dans un fichier nommé flux.rom1v.com) :

<VirtualHost *:80>
  DocumentRoot  /var/www/flux
  ServerName  flux.rom1v.com
  
  <Directory /var/www/flux/>
    Options FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    allow from all
  </Directory>
  
  ErrorLog  /var/log/apache2/flux_error.log
  CustomLog /var/log/apache2/flux_access.log combined

</VirtualHost>

Activer le site :

sudo a2ensite flux.rom1v.com

Redémarrer Apache (un simple reload aurait suffit si nous n’avions pas installé php5-curl tout à l’heure) :

sudo service apache2 restart

Configuration utilisateur

Compte utilisateur

L’application doit maintenant fonctionner. S’y connecter, avec l’utilisateur admin et le mot de passe password (l’utilisateur par défaut), puis aller dans la configuration et changer le mot de passe.

Importation et exportation

Tiny Tiny RSS permet l’importation et l’exportation d’un fichier OPML. Il est ainsi possible de migrer facilement d’un gestionnaire de flux à un autre.

Intégration à Firefox

Il est possible d’associer son instance de Tiny Tiny RSS à Firefox : toujours dans la configuration, dans l’onglet Flux, Intégration à Firefox, cliquer sur le bouton.

Pour tester, se rendre sur un site, et afficher la liste des flux disponibles. Pour cela, cliquer sur le petit icône à gauche de l’adresse, puis sur Plus d’informations…, sur l’onglet Flux (s’il y en a un), et enfin sur le flux désiré. Par exemple, pour ce blog :

blog-rss

En cliquant sur S’abonner maintenant, Firefox devrait proposer d’utiliser Tiny Tiny RSS.

Programmation de la mise à jour des flux

Il reste encore une étape importante : le serveur doit régulièrement mettre à jour le contenu de chacun des flux auxquels nous sommes abonnés.

Plusieurs méthodes sont décrites sur cette page. Certaines chargent les flux séquentiellement (par cron notamment), ce qui peut poser problème : supposons que nous soyons abonnés à 300 flux, avec une mise à jour toutes les 30 minutes, ça donne une moyenne de 6 secondes par flux. Si certains sites sont long à répondre, la mise à jour risque de dépasser le temps imparti, et cron va lancer une nouvelle tâche avant que la précédente soit terminée (heureusement Tiny Tiny RSS pose un verrou, donc il ne fera rien la seconde fois, mais du coup nous perdons une mise à jour). Ceci est d’autant plus dommage que l’essentiel de la durée nécessaire est le temps de connexion à chacun des sites : mieux vaut donc paralléliser le chargement.

C’est la raison pour laquelle je préfère la dernière méthode : lancer un démon multi-processus au démarrage du serveur. Par contre, étant donné le fonctionnement du démon proposé, il ne semble pas possible d’en faire un script init.d propre. Le plus simple est donc de rajouter dans /etc/rc.local :

start-stop-daemon -c www-data -Sbx /var/www/flux/update_daemon2.php

Vous pouvez exécuter cette commande maintenant pour charger les flux la première fois.

Ce démon utilise plusieurs processus (par défaut 2), qui mettent à jour les flux par blocs (par défaut, de 100). Pour changer ces variables (par exemple pour avoir 5 processus qui chargent des blocs de 50), dans config.php :

        define('DAEMON_FEED_LIMIT', 50);

et dans update_daemon2.php :

        define('MAX_JOBS', 5);

Autres interfaces

Une interface mobile en HTML est intégrée. Pour y accéder, il suffit d’ajouter à l’URL /mobile.

Pour Android, il existe également une application : ttrss-reader-fork (à tester, mais je la trouve assez buggée). Pour lui permettre l’accès, il est nécessaire de sélectionner “Activer les API externes” dans la page de configuration de Tiny Tiny RSS.

Conclusion

Vous n’avez plus de raison de laisser traîner vos flux RSS n’importe où ;-)

L'abondance contre l'économie

mercredi 8 juin 2011 à 08:42

copying is not theft

Le droit d’auteur sur Internet

Les lois répressives pour défendre le droit d’auteur sont justifiées par une règle que certains jugent incontestable : un auteur a le droit de décider la manière dont son œuvre sera diffusée. S’il ne souhaite pas rendre son œuvre disponible autrement que par les canaux de diffusion qu’il aura choisis, c’est son choix.

Pourtant, un auteur ne peut pas avoir tous les droits, certains droits sont nécessaires pour le public. Par exemple, ce n’est pas parce que c’est son œuvre (laissons ici de côté la part dont il redevable aux créateurs précédents) qu’il peut interdire à la population d’y penser, d’en parler, de la critiquer, etc. Pour quelle raison devrait-il pouvoir interdire son utilisation non-commerciale ?

La réponse qui vient à l’esprit est évidente, c’est le raisonnement de ceux qui sont favorables à l’interdiction du partage : un artiste, comme toute autre personne, a le droit de vivre de son travail. Si tout le monde peut accéder aux œuvres de manière illimitée et gratuite, alors, disent-ils, l’artiste ne pourra plus vendre son travail.

Ceux qui sont favorables à la légalisation du partage de fichiers leur répondront que ceux qui téléchargent le plus sont ceux qui achètent le plus, que de nouveaux modèles économiques sont nécessaires, qu’une meilleure diffusion augmente la notoriété de l’artiste, qui pourra ainsi attirer plus de monde à ses concerts, etc. Mais surtout, bien avant les arguments économiques, ils défendent ce qu’ils jugent meilleur pour la société.

En effet, pour la société, la culture a tout à gagner à être abondante et accessible à tous. Le problème est que sa “valeur marchande” diminue lorsque son abondance augmente. La dématérialisation permet la surabondance : tout le monde peut partager et copier indéfiniment et gratuitement. Nous ne pouvons pas rêver mieux si nous défendons l’abondance.

Par contre, si nous nous concentrons sur la valeur marchande, nous en concluons que l’abondance ruine la culture, car alors il n’est pas possible de la faire payer. Ainsi nous nous lançons dans une guerre contre le partage pour restaurer une rareté propice à satisfaire une demande solvable, au nom des intérêts supposés des auteurs (et surtout des ayant-droits).

Il semble donc y avoir une opposition directe entre l’intérêt des auteurs et celui de la société. Si nous devions choisir entre les deux, nous pourrions nous inspirer de la pensée de Victor Hugo :

Le livre, comme livre, appartient à l’auteur, mais comme pensée, il appartient – le mot n’est pas trop vaste – au genre humain. Toutes les intelligences y ont droit. Si l’un des deux droits, le droit de l’écrivain et le droit de l’esprit humain, devait être sacrifié, ce serait, certes, le droit de l’écrivain, car l’intérêt public est notre préoccupation unique, et tous, je le déclare, doivent passer avant nous.

Mais ces intérêts sont-ils réellement en conflit ? Et pourquoi ?

Une restriction étrange

La diffusion sans restriction de la culture et de la connaissance est sans conteste bénéfique pour la société. Mais est-elle bénéfique pour les auteurs ? Sans aucun doute : rendre accessible à davantage de personnes leurs œuvres sans aucun coût ni travail supplémentaire leur est profitable. La seule condition pour eux est d’obtenir les moyens de leur subsistance (ce que de toute façon, pour la plupart, les droits d’auteur ne leur permettent pas dans le système actuel).

Nous sommes donc dans une situation très étonnante : le partage et la diffusion illimitée sont dans l’intérêt à la fois des auteurs et du public, mais les échanges sont volontairement restreints (par la loi) à cause d’un problème économique. C’est donc l’économie qui empêche des échanges, que rien ne limiterait par ailleurs. N’y voyez-vous pas un paradoxe ?

L’économie

L’économie a pour objectif de résoudre les problèmes de rareté auxquels la société doit faire face. Pour cela, elle valorise ce qui est rare – c’est-à-dire un produit ou un service dont la demande est supérieure à l’offre – pour inciter les entreprises à mettre en œuvre des moyens de production répondant à ce besoin. A priori, c’est un mécanisme pertinent : les besoins de la population sont ainsi satisfaits au mieux, en privilégiant la production de ce qui est insuffisant.

Mais que se passe-t-il lorsque les problèmes de rareté sont résolus dans un domaine ? Tant mieux, pensons-nous, le but de l’économie est atteint, nous avons réussi. Nous pouvons alors augmenter la liberté de la population en réduisant leur dépendance vis-à-vis d’intermédiaires devenus inutiles, en rendant les moyens de production et de reproduction accessibles à tous. Mais paradoxalement, comme l’objectif est atteint, nous ne pouvons plus gagner d’argent. C’est simple : une demande limitée, une offre illimitée et un coût marginal nul impliquent un prix nul.

Comment faire fonctionner l’économie dans ce cas ? La demande est limitée, nous pouvons tenter de l’augmenter (éventuellement grâce à l’obsolescence programmée). Mais surtout nous devons empêcher que l’offre soit illimitée, en enlevant (par la loi ou par la technique) les moyens de (re)production des mains de la population, pour rendre le coût marginal non nul (obliger à faire payer chaque instance du produit en passant par un intermédiaire forcé). Il faut alors restreindre pour faire du bénéfice (cette règle est aussi valable pour le réseau Internet lui-même).

Pour gagner de l’argent, il nous faut donc lutter contre notre objectif : l’abondance. Et vu qu’il faut gagner de l’argent pour vivre, il est vital d’aller à l’encontre de ce qui est bénéfique pour la société. N’est-ce pas absurde ?

C’est la raison pour laquelle je suis convaincu qu’une partie des échanges doit être hors-marché. Je pense que nous devrions réserver l’économie aux domaines où elle fonctionne, lorsqu’elle améliore la société, c’est-à-dire quand nous devons gérer la rareté. Le reste des échanges – lorsqu’il y a abondance – doit être hors-marché, car sinon l’économie tenterait d’y restaurer une rareté artificielle. Certains réfléchissent aussi à des monnaies d’abondance.

Les domaines d’abondance

L’arrivée du numérique a de facto rendu tout ce qui est immatériel abondant. La musique est le premier domaine à avoir massivement profité de cette amélioration technologique, suivie par les films, les jeux vidéos, les livres, l’information, etc. Les industries travaillant dans ces domaines d’activité ont toutes un point commun : leurs modèles économiques sont en train de s’effondrer.

Mais ce progrès ne devrait pas s’arrêter à l’immatériel : une seconde vague d’abondance pourrait bien accélérer le processus d’évolution de la société : l’autofabrication à portée de tous (par exemple l’impression 3D) permettra potentiellement à chaque foyer de posséder sa propre usine miniature à faible coût. Beaucoup d’entreprises pourront mettre la clé sous la porte : pourquoi j’irai acheter une chaise dans un magasin si je peux la télécharger et “l’imprimer” chez moi ?

Dans une génération, on sera bien en peine d’expliquer à nos petits-enfants comment on a pu vivre sans son autofabricateur, et qu’on devait commander des biens préfabriqués en ligne et attendre qu’ils nous arrivent dans notre boîte aux lettres livrés par la Poste.

Cette prospérité est inéluctable. Mais surtout, et je voudrais insister là-dessus, elle est souhaitable. Comment en sommes-nous arrivé à croire le contraire ? La question ne devrait pas être de savoir si oui ou non il faut tolérer le partage de fichiers, mais au contraire comment faire pour l’encourager.

Corriger le problème économique

L’équilibre entre l’abondance et la rareté évolue. Dans un monde de rareté, l’économie peut fonctionner. Dans un monde d’abondance absolue, l’économie telle que nous la connaissons serait contre-productive, et à la limite il n’y aurait pas besoin d’argent (aurions-nous inventé l’argent si rien n’était rare ?). Mais le problème se pose lorsque le monde est composé à la fois de domaines d’abondance et de rareté : pourquoi les personnes travaillant dans un domaine d’abondance ne pourraient-elles pas gagner d’argent, alors que celles travaillant dans un domaine de rareté le pourraient ?

Quelles sont les solutions envisagées pour le résoudre ? En voici cinq (peut-être y en a-t-il d’autres).

La rareté imposée

La première, c’est d’imposer par la loi ou par la technique la rareté, pour lutter au maximum contre l’abondance des choses. C’est la solution envisagée par beaucoup de lois actuelles (Hadopi en France), souvent écrites par les lobbies des entreprises qui bénéficient de cette rareté. Sans commentaire.

Les profits indirects

La deuxième consiste à bénéficier de l’abondance pour atteindre un public plus important. Typiquement, un chanteur rend sa musique accessible à tous, cela contribuera à le faire connaître et lui permettra d’attirer plus de monde à ses concerts. L’idée est séduisante, mais elle ne s’applique pas à tous les domaines (il serait par exemple difficile pour un écrivain d’obtenir des profits indirects). Néanmoins, même si elle est insuffisante, cette solution est naturellement plébiscitée lorsque c’est possible.

La contribution créative

La troisième est une contribution forfaitaire, appelée contribution créative (plus connue sous le nom de licence globale), versée mensuellement par chaque internaute. Philippe Aigrain détaille cette proposition dans son livre Internet & Création. Elle possède un atout majeur : autoriser et favoriser les échanges hors-marché.

Néanmoins, j’émets quelques doutes : je la considère comme une solution temporaire. En effet, si le calcul prend en compte les médias (musique, films, livres…), toute forme de création (présente et future) n’est pas concernée, comme par exemple les logiciels libres. Sans parler de la future duplication des objets matériels évoquée plus haut.

De plus, elle ne prend pas en compte l’augmentation de la diversité : plus il y a d’auteurs, moins chaque auteur sera rémunéré.

Enfin, ce mécanisme induit nécessairement une centralisation : chaque auteur devrait adhérer à une gestion collective, et nous devrions mesurer la proportion des échanges pour redistribuer la cagnotte à chacun. Je suis a priori réticent face à une telle centralisation (mais pourquoi pas ?).

Le don

Une autre solution est la rémunération par le don. Le principe est simple : chaque œuvre est accessible à tous, ceux qui ont apprécié peuvent rémunérer l’auteur. Ce mécanisme peut sembler bien limité : le montant récolté sera probablement insuffisant, et utilisé seul, l’incertitude de revenu ne favoriserait pas la pratique d’activités non marchandes.

Cependant, ce système de rémunération est intéressant, car il favorise les échanges hors-marché tout en permettant une rétribution de l’auteur, sans centralisation.

Le revenu de base

Enfin, la solution que je trouve la plus séduisante est le revenu de base, un revenu versé inconditionnellement à chacun et suffisant pour vivre.

Une fois ce revenu garanti, certains ne s’épanouiraient-ils pas dans des domaines moins rémunérateurs, mais davantage bénéfiques pour tout le monde ? D’autant que ce n’est pas l’argent qui nous motive vraiment dans le travail (encore faut-il en avoir suffisamment pour vivre).

Ne croyez-vous pas qu’un frein majeur au développement des logiciels libres (par définition copiables, donc abondants) soit justement la nécessité de gagner de l’argent sur la rareté ? Bien sûr, il est possible d’être rémunéré indirectement, par les services, le support… Mais est-ce suffisant ? Les entreprises sont même parfois contraintes de financer le logiciel libre par le logiciel propriétaire

Par ailleurs, dans le domaine de l’information où l’indépendance est capitale, ce revenu de base s’ajoutant aux autres sources de financement pourrait contribuer à réduire la dépendance économique des journalistes.

Ce ne sont que quelques arguments en faveur du revenu de base. J’en développe d’autres dans mon billet consacré au dividende universel, et je détaille l’injustice monétaire, un argument central justifiant sa mise en place.

À propos de la monnaie justement, le don est actuellement découragé à cause de la structure centralisée du système monétaire. Je pense qu’une monnaie à dividende universel permettrait de faciliter cette forme de rémunération supplémentaire…

Je suis persuadé que cette proposition est au moins une partie de la solution au problème économique de l’abondance. Je regrette qu’elle soit si peu évoquée dans les débats sur le droit d’auteur.

Conclusion

Je souhaite que le libre partage de la culture, de la connaissance, et plus généralement de tous les biens non-rivaux soit légalisé. Non pas pour quémander un droit qui serait illégitime, mais au contraire parce que je pense que c’est une évolution nécessaire et positive pour la société. En particulier, l’utilisation non-commerciale d’une œuvre devrait être un droit du public non contestable par l’auteur.

Nous ne pouvons accepter le seul argument économique pour justifier de lutter contre l’abondance, alors même que l’économie a pour objectif de résoudre des problèmes de rareté. Nous devons au contraire mettre en place un système qui assure la subsistance de chacun et qui favorise le partage et l’abondance.

Installer Ubuntu Server sur un Shuttle XS35

lundi 6 juin 2011 à 22:21

XS35

Je viens de migrer mon auto-hébergement vers cette nouvelle machine. Elle est très silencieuse (il n’y a pas de ventilateur) et consomme peu.

Je n’envisageais pas d’écrire un billet, mais l’installation d’Ubuntu Server 11.04 ne se déroule pas sans incidents :

Aucune interface réseau n'a été détectée

C’est le genre de problèmes qu’on espère un jour ne plus connaître lorsqu’on installe une distribution… Surtout lorsque ce problème en provoque d’autres… Ceci est donc un aide-mémoire qui me sera utile pour une future installation.

Installation

Tout d’abord, il faut ignorer le message d’erreur, tant pis, l’installation sera effectuée sans réseau.

Ensuite la section Choisir et installer des logiciels, il ne faut surtout pas activer Mail (postfix et dovecot) dans la liste : cela ferait planter le processus d’installation car il ne trouve pas d’interface réseau. En effet, dans /var/log/syslog, on trouve une erreur du genre :

postfix/sendmail: fatal: could not find any active network interfaces

On installera donc le serveur mail plus tard.

En suivant ces conseils, l’installation doit se dérouler correctement.

Récupération des pilotes

À partir d’un autre ordinateur, récupérer la dernière version des sources du pilote (j’en fait une copie chez moi, au cas où).

Ensuite, on est un peu embêté, car on devrait extraire les sources sur le serveur et exécuter sudo make install. Sauf que make n’est pas installé par défaut sur Ubuntu Server (merci Ubuntu !), et pour l’installer, il faut le réseau… qu’on aura une fois qu’on aura installé les pilotes…

Heureusement, on peut s’en sortir manuellement. Pour cela, sur un ordinateur qui possède make (avec le même noyau pour la même architecture), extraire les sources de l’archive dans un répertoire et exécuter :

tar xvjf jme-1.0.7.1.tbz2
cd jmebp-1.0.7.1
make

Cela crée un fichier jme.ko (je suis gentil, je vous donne le fichier déjà compilé pour le noyau 2.6.38-8-server en amd64). Le copier sur une clé USB.

Installation des pilotes

Ensuite, brancher la clé USB sur le serveur, et déterminer son emplacement (sous la forme /dev/sdX1). Pour cela, (une technique parmi d’autres) juste après l’avoir branchée, exécuter :

tail /var/log/syslog

La commande doit afficher plusieurs lignes ressemblant à ceci :

Jun  6 22:33:19 rom-server kernel: [1046971.365046] sd 12:0:0:0: [sdb] Attached SCSI removable disk

Ici, l’emplacement est donc /dev/sdb1.

Monter la clé :

sudo mount /dev/sdb1 /mnt

Puis installer le pilote compilé au bon endroit et l’activer :

sudo install -m 644 /mnt/jme.ko /lib/modules/$(uname -r)/kernel/drivers/net
sudo modprobe jme

Finaliser l’installation

Ajouter à la fin de /etc/network/interfaces :

auto eth0
iface eth0 inet dhcp

Et rebooter :

sudo reboot

Normalement, la carte devrait être détectée (on peut tester avec ifconfig).

Si tout est OK, on peut maintenant installer le serveur mail.

Error happened! 0 - Call to undefined function simplexml_load_string() In: /var/www/Projet-Autoblog/autoblogs/autoblog.php:364 http://www.couturat.fr/Projet-Autoblog/autoblogs/blogrom1vcom_4af8d17d34d978843ff2ff40339aa5760e6458bc/?14 #0 /var/www/Projet-Autoblog/autoblogs/autoblog.php(932): VroumVroum_Blog->update() #1 /var/www/Projet-Autoblog/autoblogs/blogrom1vcom_4af8d17d34d978843ff2ff40339aa5760e6458bc/index.php(1): require_once('/var/www/Projet...') #2 {main}