Pour mes flux RSS, j’utilise l’outil tt-rss installé sur mon serveur, qui récupère régulièrement tous les flux auxquels je suis abonné.

Le but de ce billet est de mettre en place un mécanisme similaire qui s’applique aux sources de vidéo à la demande (pas forcément prévues pour être agrégées), et qui les convertit dans le format ouvert OGG/Theora (dans un répertoire rendu accessible par un serveur web tel qu’Apache), tout en parallélisant au maximum les différentes actions afin que le temps total de récupération soit minimal.

En particulier, il faut éviter de télécharger la première vidéo, puis de l’encoder, d’attendre que l’encodage soit terminé pour télécharger la seconde vidéo… Et si plusieurs CPU sont disponibles sur la machine, il faut donner un encodage à chaque processeur (l’encodeur theora ne sachant pas paralléliser l’encodage d’une seule vidéo).

Architecture

Pour cela, il y a donc 2 parties bien distinctes :

• un serveur d’encodage, qui s’occupe du démarrage et de la parallélisation des encodages ;
• des programmes de récupération brute pour chaque source de flux, qui demandent au serveur d’encodage de s’occuper de la conversion des fichiers récupérés.

Serveur d’encodage

Principe

Le serveur d’encodage gère plusieurs processus ouvriers (dans l’idéal, il faut configurer pour avoir autant de processus que de CPU sur la machine). Il attend de nouvelles tâches, et les transmets aux ouvriers disponibles, qui s’occupent de l’encodage. Si aucun ouvrier n’est disponible, il attend qu’un se libère.

Implémentation

Les demandes d’encodage se font grâce à un named pipe (aussi appelé FIFO), un fichier un peu spécial créé avec mkfifo. Chaque ligne représente une tâche. Concrètement, une tâche est décrite par les paramètres à passer à ffmpeg2theora (l’encodeur theora), séparés par un séparateur (j’ai choisi « | », qui a peu de chance d’être utilisé dans un nom de fichier). Pour les puristes, je vous mets au défi d’utiliser comme séparateur \0, tout en conservant le mécanisme de file d’attente dans un fichier.

Un démon récupère les nouvelles lignes ajoutées au fichier, et les transmet une à une aux ouvriers. Chaque ouvrier recrée le tableau des arguments en redécoupant la ligne suivant le séparateur choisi, et le passe en paramètre de ffmpeg2theora (en y ajoutant toujours --nice 19 pour n’utiliser que le CPU disponible, sans ralentir d’autres programmes en cours d’exécution).

Démon

Voici le programme démon (adapter le nombre de CPU) :
/usr/sbin/ffmpeg2theora-laterd

#!/bin/bash
CPU=2
TASKS=/tmp/ffmpeg2theora-tasks
[ -p "$TASKS" ] || mkfifo "$TASKS" -m 666
tail -f "$TASKS" | xargs -I{} -P "$CPU" ffmpeg2theora-later-job {}

Ce script fait donc exécuter par les ouvriers le programme ffmpeg2theora-later-job pour chacune des tâches, dont voici le code :
/usr/sbin/ffmpeg2theora-later-job

#!/bin/bash
IFS='|' read -a args <<< "$1"
echo "executing: ffmpeg2theora ${args[@]} --nice 19"
ffmpeg2theora "${args[@]}" --nice 19

Je vous conseille de prendre la dernière version de ffmpeg2theora, actuellement celle des dépôts est assez ancienne.

Le démon est à lancer une fois (et une seule !), au démarrage du système par exemple (une solution est de l’ajouter dans /etc/rc.local).

Client

Les clients (les programmes qui veulent demander un encodage) doivent appeler ffmpeg2theora-later, qui s’occupe d’écrire les paramètres séparés par « | » dans le FIFO :
/usr/bin/ffmpeg2theora-later

#!/bin/bash
printf '|%s' "$@" | cut -c2- > /tmp/ffmpeg2theora-tasks

Son utilisation est extrêmement proche de ffmpeg2theora (évidemment, puisqu’il se contente de lui transmettre ses paramètres), à ceci près que les chemins doivent être absolus (puisque le démon ne sait pas à partir de quel répertoire la demande d’encodage a été effectuée).

Ainsi, là où on aurait utilisé, à partir de /tmp :

ffmpeg2theora file.avi -o file.ogv -x 400 -y 300 -v 8 -a 3

on peut appeler :

ffmpeg2theora-later /tmp/file.avi -o /tmp/file.ogv -x 400 -y 300 -v 8 -a 3

Programmes de récupération

Principe

Les programmes de récupération font ce qui est nécessaire pour récupérer les vidéo à télécharger. Plusieurs outils sont bien utiles pour cela :

• wget si le fichier est disponible en HTTP (mais c’est rare) ;
• flvstreamer pour récupérer les vidéos diffusées en Flash avec des liens en rtmp:// (anciennement rtmpdump, je vous recommande le message adressé à Adobe de la part du développeur originel) ;
• mimms pour récupérer les vidéos diffusées en WMV avec des liens en mms://.

Pensez bien à ouvrir les ports nécessaires pour récupérer les vidéos (1935 par défaut pour les liens RTMP, 1755 pour MMS…).

Implémentation

Afin de rendre un peu indépendants les répertoires manipulés, j’ai décidé de créer un script vodget qui appelle les programmes de récupération avec 2 paramètres :

1. le répertoire de téléchargement ;
2. le répertoire destination.

/usr/bin/vodget

#!/bin/bash
scripts_dir=/var/lib/vodget
script="$scripts_dir/$1"
download_dir=/tmp/vodget
target_dir=/var/www/vod
$script "$download_dir" "$target_dir"

Les programmes de récupération sont stockés dans /var/lib/vodget.

Exemple

Voici un exemple qui récupère les guignols de l’info (Canal+) :
/var/lib/vodget/guignols

#!/bin/bash
category=guignols
download_dir="$1/$category"
target_dir="$2/$category"
mkdir -p "$download_dir"
mkdir -p "$target_dir"
wget -O- http://www.canalplus.fr/rest/bootstrap.php?/bigplayer/search/guignols | grep -o 'rtmp://[^<]\+.mp4' | while read url
do
    filename="$(echo "$url" | sed 's/.*\([0-9]\{2\}\)\([0-9]\{2\}\)\([0-9]\{2\}\).*/20\1-\2-\3/')"
    if [ ! -f "$target_dir/$filename.ogv" ]
    then
        flvstreamer -r "$url" -o "$download_dir/$filename.mp4"
        touch "$target_dir/$filename.ogv"
        ffmpeg2theora-later "$download_dir/$filename.mp4" -o "$target_dir/$filename.ogv" -v8 -a3
    fi
done

Cet exemple est une implémentation qui a l’avantage d’être très courte, vous pouvez aussi adapter des versions plus évoluées pour qu’elles utilisent ffmpeg2theora-later.

Un simple appel à :

vodget guignols

récupèrera les nouveaux épisodes et les encodera en OGG/Theora.

Il ne restera plus qu’à se rendre sur la page HTTP pointant sur le répertoire des vidéos avec un navigateur qui supporte le HTML5 et le codec OGG/Theora, pour pouvoir regarder les vidéos ainsi récupérées :

Bien sûr, les vidéos récupérées qui ne sont pas sous licence libre sont à usage personnel. Cela permet de regarder en VOD les épisodes dans un format ouvert, qui ne nécessite pas de programme propriétaire, ces vidéos ne doivent pas être placées sur un serveur public.

Démarrage programmé

Pour automatiser tout cela, il est possible de programmer périodiquement la récupération des nouvelles vidéos grâce à cron. Pour cela :

crontab -e

et ajouter la ligne qui-va-bien. Par exemple, pour récupérer les nouveaux épisodes des guignols tous les jours à 23 heures :

00 23 * * * vodget guignols

Améliorations

Techniquement, il faudrait gérer le démon par un script init.d, mais ça n’est pas si simple (si on arrête le service alors qu’une vidéo est en cours d’encodage et qu’on le redémarre, le nombre de CPU à utiliser ne sera plus respecté…).

Si vous êtes motivés, il est également possible de faire un beau site qui permette de regarder les vidéos en VOD, plutôt qu’une page qui liste simplement les fichiers récupérés.

Conclusion

Les différentes vidéos que je suis susceptible de regarder en VOD (que je ne regardais pas avant) sont maintenant disponibles sur mon serveur, lisible directement par mon navigateur.

On peut imaginer de nombreuses sources à agréger :

• les sites de VOD des chaînes de télévision (Canal+, France5, M6…) ;
• des bandes-annonces cinéma ;
• des chaînes enregistrées en direct avec la TV sur ADSL ;
• le flux de l’Assemblée Nationale ou du Sénat ;
• …

Bien sûr, on aimerait mieux que les différentes sources fournissent des flux RSS pointant vers leurs vidéos, qu’ils diffuseraient eux-même en OGG/Theora. Mais on peut toujours attendre…

Pour mon serveur mail (et plus généralement pour les outils que j’utilise), j’essaie de mettre en place uniquement ce dont j’ai besoin. Et jusqu’ici, je n’avais pas l’utilité d’un anti-spams, ne recevant aucun courrier indésirable. Mais depuis peu, j’en reçois un de temps en temps… C’est donc l’occasion de m’y mettre.

Installation et configuration

Il existe plusieurs méthodes, j’ai choisi la plus simple : c’est procmail qui fournit les mails à SpamAssassin.

Tout d’abord, installer le paquet :

sudo apt-get install spamassassin

Ensuite, rajouter dans ~/.procmailrc la règle suivante (copiée de la doc) :

# Pipe the mail through spamassassin (replace 'spamassassin' with 'spamc'
# if you use the spamc/spamd combination)
#
# The condition line ensures that only messages smaller than 250 kB
# (250 * 1024 = 256000 bytes) are processed by SpamAssassin. Most spam
# isn't bigger than a few k and working with big messages can bring
# SpamAssassin to its knees.
#
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| spamassassin

Enfin, éditer /etc/spamassassin/local.cf.

Pour uniquement ajouter les en-têtes de spam (ce qui est suffisant pour filtrer), il faut changer la valeur de report_safe :

report_safe 0

Pour ajouter un tag dans le sujet d’un mail considéré comme un spam :

rewrite_header Subject *****SPAM*****

Il est également possible de configurer le score requis pour qu’un mail soit considéré comme un spam. Plus cette valeur est faible, plus le filtre est agressif.
La valeur par défaut (5.0) est un peu faible, je vous conseille d’augmenter un peu si vous voulez limiter les faux-positifs :

required_score 6.0

Rajouter éventuellement les lignes suivantes :

# Langues attendues (les autres auront un score plus élevé)
ok_languages fr

# Rapports en français
lang fr

Test

Pour tester, le plus simple est de mettre un filtre très sévère, par exemple avec un score négatif :

required_score -2

En m’envoyant un mail à moi-même qui contient comme sujet test, je constate à la réception que les en-têtes ont été modifiés :

Subject: *****SPAM***** test
Date: Thu, 25 Mar 2010 21:19:52 +0100
Message-Id: <1269548392.9798.9.camel@rom-laptop>
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rom-eeebox
X-Spam-Level: ***
X-Spam-Status: Yes, score=3.9 required=-2.0 tests=ALL_TRUSTED,

Le mail a bien été détecté comme un spam. Ça fonctionne.

Filtrage

Maintenant que les spams sont détectés, il faut les traiter (les déplacer dans un dossier prévu à cet effet).

Il suffit pour cela de créer un dossier sur le serveur :

maildirmake.dovecot ~/Maildir/.Spams

et d’ajouter la règle suivante dans ~/.procmailrc (plus d’infos) :

:0
* ^X-Spam-Status: Yes
.Spams/

Conclusion

Les spams auront maintenant un peu plus de mal à se glisser dans ma boîte mail.

La configuration présentée ici est vraiment minimale. Selon son efficacité il faudra peut-être l’affiner.

Voir aussi

Mes précédents billets sur l’auto-hébergement des mails :
Hébergez vos mails sur Ubuntu Server (et libérez-vous)
Installer un webmail (RoundCube) sur Ubuntu Server
Ajouter l’authentification SMTP sur un serveur mail
Trier ses mails directement sur le serveur (procmail)

Dans la continuité des articles consacrés à l’auto-hébergement des mails, je vais présenter quelque chose que je voulais mettre en place depuis un moment : le tri du courrier directement sur le serveur.

Introduction

Lorsqu’on est abonné à des mailing-lists ou qu’on reçoit des notifications de forums ou de blogs, il est inconcevable de garder tous ses mails dans un seul et même dossier, et impensable de les déplacer manuellement (à moins de passer 30 minutes par jour à les trier). Un tri doit être mis en place automatiquement, en se basant sur les en-têtes des mails reçus.

J’utilisais jusqu’à maintenant les filtres de messages de mon client mail, Evolution, mais ça n’était pas forcément approprié :

• d’une part c’est très long avec un compte IMAP (les dossiers étant gérés côté serveur), car le client doit récupérer localement les nouveaux messages du serveur et les analyser ; s’il faut en déplacer un, il doit demander au serveur de le copier de la boîte de réception vers le dossier destination adéquat, puis demander de le supprimer de la boîte de réception, et enfin récupérer le messages déplacé… Rien que ça !
• d’autre part, lorsqu’on accède à ses mails à partir de plusieurs endroits (par exemple le client mail, le webmail et le téléphone portable), il devient évident que ce ne peut pas être le rôle des clients de trier les messages…

C’est donc au serveur de placer les mails dans le bon dossier dès la réception. C’est ce que procmail permet de faire.

Les dossiers IMAP

Les dossiers IMAP sont des dossiers physiques contenus dans ~/Maildir (le répertoire des mails) qui respectent une structure particulière :

• leur nom commence par « . » (ce sont des dossiers cachés) et les sous-dossiers « logiques » sont séparés par des « . » (par exemple, si je veux un dossier a contenant un sous-dossier b, le répertoire physique sera ~/Maildir/.a.b) ;
• ils contiennent 3 sous-dossiers physiques : cur, new et tmp.

Pour les créer, il suffit d’utiliser maildirmake ou maildirmake.dovecot, à partir du répertoire ~/Maildir :

maildirmake.dovecot .forums.ubuntu-fr
maildirmake.dovecot .forums.developpez

pour obtenir l’arborescence suivante :

|-- .forums.developpez
|   |-- cur
|   |-- new
|   `-- tmp
`-- .forums.ubuntu-fr
    |-- cur
    |-- new
    `-- tmp

Il est également possible de les créer graphiquement grâce à un client mail.

Configuration de postfix

Il faut indiquer à postfix que procmail va s’occuper de trier les mails, en lui précisant dans /etc/postfix/main.cf :

mailbox_command = /usr/bin/procmail

Il faudra ensuite recharger la configuration :

sudo /etc/init.d/postfix reload

Définir les règles de tri

Tout se passe dans le fichier (à créer) ~/.procmailrc, qui contient deux parties : la définition des variables et la définition des « recettes » (les règles de tri).

Les variables

Pour les variables, copiez simplement ceci (en décommentant les 2 premières lignes si vous voulez des logs).

#VERBOSE=yes
#LOGFILE=.procmail.log
SHELL=/bin/sh
PATH=/bin:/usr/bin:/usr/local/bin
MAILDIR=Maildir/
DEFAULT=./

Les recettes

Les recettes sont écrites sous la forme suivante :

:0 [drapeaux] [ : [verrou_local] ]
<zéro ou plusieurs conditions (une par ligne)>
<exactement une ligne d'action>

Les conditions commencent toutes par « * », suivie d’une expression régulière. Pour qu’une recette exécute l’action définie, il faut que le mail en question valide toutes les conditions.

Pour faire simple, nous allons simplement créer des règles qui déplacent des mails dans des dossiers. Pour définir une telle action, il suffit d’écrire le nom du dossier, en terminant la ligne par / (très important, cette convention indique à procmail que le dossier est au format maildir).

Un exemple étant plus parlant, voici une règle qui déplace toutes mes notifications de blog dans un dossier blog :

:0
* ^From: .*<wordpress@blog\.rom1v\.com>$
.blog/

Résultat

Au final, voici un extrait de mon fichier ~/.procmailrc (je n’ai pas mis toutes les règles, c’est juste pour donner quelques exemples) :

#VERBOSE=yes
#LOGFILE=.procmail.log
SHELL=/bin/sh
PATH=/bin:/usr/bin:/usr/local/bin
MAILDIR=Maildir/
DEFAULT=./

:0
* ^From: .*<wordpress@blog\.rom1v\.com>$
.blog/

:0
* ^Reply-To: .*<[0-9]+@bugs\.launchpad\.net>$
.bugs.launchpad/

:0
* ^From: .*<dev\.null@ubuntu-fr\.org>$
.forums.ubuntu-fr/

:0
* ^List-Id: <april\.april\.org>$
.ml.april/

Voici mes premières impressions de libriste. Comme vous allez le voir, il y a du positif… et du négatif. Je vais commencer par l’achat et l’accès Internet, pour ensuite entrer dans le vif du sujet : le matériel et le logiciel.

L’achat

Exclusivité rueducommerce, ce téléphone n’était pas trouvable autre part à sa sortie : c’est insupportable ces exclusivités, impossible de le voir « en vrai » avant l’achat. Par contre, il était possible de choisir son opérateur (encore heureux me direz-vous, mais ça n’est pas toujours le cas).

L’accès Internet

Comme prévu, un internet mobile (avec un petit i) loin d’être neutre, comme on peut le voir dans les conditions générales d’abonnement SFR :

4.1 : L’abonné est informé et accepte que les Offres lui soient proposées sur la base de la configuration du terminal compatible opérée par l’opérateur. Dès lors, l’abonné qui procèderait à la modification de paramétrage de son terminal compatible ne pourra plus bénéficier des Offres et tarifs en l’état.

Les offres et les tarifs dépendent du matériel qu’on utilise pour aller sur internet ou téléphoner ! Imaginez que votre accès ADSL soit plus cher si vous achetez un ordinateur Acer plutôt qu’un Asus… ou que vous changiez le système d’exploitation ou les logiciels pré-installés…

4.2 : Le peer to peer, les newsgroups, la Voix sur IP et les usages Modem sont interdits, ce que l’abonné reconnaît et accepte, SFR se réservant le droit, pour les clients Forfaits Bloqués SFR, de résilier la ligne en cas de manquement.

Bon, bah là on est carrément dans le filtrage protocolaire pure et simple. Sans parler des usages « modem » qui sont interdits, comme si les fournisseurs d’accès ADSL interdisaient d’installer un routeur perso sur sa connexion…

4.3 : Pour permettre à tous les clients SFR d’accéder au réseau SFR dans des conditions optimales, le débit maximum de connexion sera réduit au-delà de 1Go d’échanges de données par mois jusqu’à la prochaine date de facturation.

Quand une phrase commence comme ça, en général, c’est mauvais signe… Le soi-disant « Internet » est donc limité à 1Go par mois sans réduction de débit…

Les cas particuliers pour les iPhones sont également assez hallucinants.

Vivement que Free sorte ses offres mobiles…

Le matériel

Rien à redire à ce niveau-là, l’écran 3,7′ avec une définition de 854×480 est vraiment très confortable, la navigation sur internet est agréable. L’écran tactile fonctionne très bien, il a l’air solide et ne se raye pas. Le clavier physique est très sympa pour écrire tout en gardant l’intégralité de l’écran visible.

Le téléphone est peut-être un peu lourd, mais on s’y fait.

Le logiciel

Mes attentes

Avant de détailler ce que je pense de toute la partie logicielle, je voudrais détailler ce que j’attends du téléphone.

Tout d’abord, je veux accéder à mes mails, à la messagerie instantanée et aux salons de discussion IRC. Je veux également pouvoir me connecter en SSH (sur mon serveur à la maison par exemple) et rediriger des ports (pour faire passer les connexions dans un tunnel, vers un réseau internet plus neutre, celui que j’ai à la maison en l’occurrence) ; les logiciels que j’utilise doivent donc supporter la configuration d’un proxy.

Ensuite, je ne veux pas utiliser tous les services Google, en particulier je ne veux pas de Gmail, de l’agenda, de Google Talk… Plus généralement, je ne veux pas d’applications qui nécessitent un compte Google (mes données personnelles n’ont rien à faire chez Google ou chez n’importe qui d’autre).

Enfin, je ne veux pas passer par « Android Market » pour installer des applications. Je veux installer et désinstaller des applications à ma guise, même celles qui sont fournies avec le téléphone. D’ailleurs, je ne suis pas d’accord avec les conditions d’utilisation, entre autres :

Si tel était le cas, Google se réserve le droit de supprimer à distance et à sa seule discrétion les Produits concernés de votre Mobile, sans vous en informer au préalable.

D’une part, je considère que c’est abusif sur le principe, d’autre part ça signifie que techniquement le Market est une sorte de trojan à partir duquel une entité extérieure peut exécuter du code à son bon vouloir. Tout simplement inacceptable. Google m’a beaucoup déçu sur ce point, en général j’aime bien leur politique d’ouverture, mais j’avoue avoir été désagréablement surpris par leurs conditions, qui font malheureusement penser à celles d’Apple (en moins pire, certes, mais quand même)…

Certains me demanderont alors « mais pourquoi donc as-tu choisi un Android ? ». Pour moi, Android a beaucoup d’attraits : le système d’exploitation est sympa, on peut rajouter des applications sous licence libre sans forcément passer par le Market, on peut se connecter directement en USB à l’ordinateur, j’aime bien l’interface, etc. Avoir accès facilement à mes données personnelles offertes gracieusement à Google est loin d’être ma priorité… Et je rajouterais que faute de mieux, Android est le moins pire au niveau ouverture…

Que de déceptions !

Tout d’abord, lorsqu’on allume le téléphone, on se rend compte qu’il y a quelques applications installées dont on n’a pas besoin (« Agenda », « Agenda d’entreprise », « Annuaire d’entreprise », « Gmail », « Motonav », « Phone Portal », sans compter « Market » puisque j’ai dit que je ne comptais pas m’en servir). Après tout, ce n’est pas gênant, sur Ubuntu Empathy est pré-installé, moi j’utilise Gajim, il me suffit de désinstaller Empathy et d’installer Gajim.

Mais là, non ! Il est tout simplement impossible de désinstaller les applications pré-installées, certaines ressemblant plus à des crapwares qu’à des applications utiles (ça me fait penser aux pauvres utilisateurs de Windows qui achètent un ordinateur avec Norton pré-installé et difficile à retirer)…

En fait, il faut attendre que le téléphone soit rooté pour pouvoir faire ce que l’on veut sur sa machine. Et là vient encore une nouvelle déception vis-à-vis de Google (à moins que ça ne soit la faute de Motorola ?) : pourquoi n’est-il pas proposé par défaut la fonctionnalité de passer root sur la machine ? Pourquoi est-ce considéré comme du « piratage » de rooter son téléphone, comme pour le jailbreak de l’iPhone ? Imaginez-vous acheter un ordinateur et qu’on vous empêche d’être root dessus ? Pourquoi serait-ce différent pour un téléphone ?

Ça commence mal, mais ce n’est pas très grave, je me dis que je vais ignorer ces applications, elles prennent juste un peu de place en mémoire et surtout dans le menu principal… Après tout, je peux installer les logiciels libres que je veux en les téléchargeant sur le site en .apk et en les copiant sur la carte mémoire, non ? Pas tout-à-fait, car par défaut, le téléphone ne sait pas installer les .apk… Ça aurait été plus utile que les bidules pré-installés, non ?

Parce que du coup, il faut installer un logiciel qui s’appelle appsInstaller (non libre) (EDIT: je vous conseille plutôt le gestionnaire de fichiers libre OI File Manager). Comment? En passant par le Market. Ce qui implique d’accepter les conditions disant « ce programme est un trojan, voulez-vous accepter ? » (je caricature à peine). Et qui implique de renseigner un compte Gmail dans le téléphone, qui sera utilisé par toutes les autres applications.

J’accepte donc les conditions et crée un compte bidon (jeneveuxpasdecompte at gmail.com). Une fois appsInstaller installé, je tente de supprimer ce compte de mon téléphone, « Impossible de supprimer ce compte ». sudo supprimer ce compte, non ça n’est pas possible ? Décidément, on n’est pas maître de la machine tant qu’on n’est pas root !

EDIT 10/01/2009 : C’est en fait possible d’installer une application .apk sans jamais configurer un comte gmail ni passer par le market : Installer une application .apk sur Android à partir d’un PC.

Du positif quand même

Malgré tout cela, il y a des choses qui fonctionnent bien.

Par exemple la connexion USB qui permet d’accéder directement au contenu la carte SD, quelque soit le système d’exploitation. Ou la musique Ogg Vorbis qui se lit très bien avec le lecteur par défaut… La gestion des notifications est également sympa (un peu à la manière d’indicator-applet dans Ubuntu).

Le GPS fonctionne bien en extérieur (par contre en intérieur, il fait n’importe quoi chez moi).

Voici quelques retours d’expérience sur les programmes « de base » (mails, messagerie, ssh, jabber).

Si vous connaissez d’autres logiciels libres sympa, n’hésitez pas à partager.

Mail

Le client mail par défaut se connecte sans problème à mon serveur perso en utilisant IMAP/TLS et SMTP/TLS. Il n’offre par contre pas un super affichage pour les dossiers IMAP (une liste de noms « bruts » comme « INBOX.forums.ubuntu-fr », « INBOX.mailing-list.april »…). il ne gère pas le PUSH (pour recevoir son mail aussitôt) et a un peu de mal avec les pièces jointes.

J’ai installé k9mail (Apache License 2.0), qui est un peu plus complet, et qui gère le PUSH et les pièces jointes. Par contre, il n’est qu’en anglais.

Messagerie instantanée

Pour utiliser la messagerie instantanée Jabber, j’ai trouvé le client Jabiru qui fonctionne très bien :

Par contre, il n’a pas évolué depuis avril 2009… et il n’y a pas d’icônes dans les menus (pas très grave).

EDIT 12/01/2009 : Beem, quant à lui, est en plein développement et ne plante pas lamentablement comme le fait parfois Jabiru… C’est maintenant celui que j’utilise.

Identi.ca

Pour tweeter sur identi.ca, j’ai installé mustard. Très sympa (sauf qu’il rafraîchit les flux à chaque fois qu’on le lance, même si le dernier chargement a eu lieu il y a 15 secondes).

SSH

L’application connectbot (GNU/GPLv3), permet de se connecter en SSH à un serveur. Elle gère les paires de clés publique/privée et la redirection de ports.

En particulier, je l’utilise pour lancer irssi (un client IRC en ligne de commande) dans un screen sur un serveur. Cela permet de pouvoir déconnecter et reconnecter le client sans se déconnecter des salons et ni perdre le fil de discussion…

Malheureusement, le navigateur internet par défaut ne permet pas de configurer de proxy (pour utiliser un tunnel SSH). Si vous en connaissez un bien en attendant Fennec, je suis preneur. D’autant que le navigateur intégré ne fonctionne pas correctement sur tt-rss (quand je clique sur un flux, il considère que je clique sur toute la colonne de gauche).

Conclusion

Le téléphone et le système sont de jolis jouets technologiques.

Mais je m’attendais, de la part de Google, à ce que ça soit quand même plus ouvert que ça… Là on est obligé d’accepter des conditions inacceptables, d’utiliser un compte Google alors qu’on n’a rien demandé, on ne peut pas désinstaller les crapwares… On se sent un peu limité, on n’a pas la maîtrise totale de la machine tant qu’elle n’aura pas été rootée, je trouve que c’est vraiment dommage.

Attendons donc qu’elle soit rootée…

PS: Quelques trolls se sont malencontreusement glissés dans ce billet, saurez-vous les retrouver ?

Objectif

La configuration de postfix présentée dans mon premier billet limitait (dans un but de sécurité) l’envoi d’un mail à une personne distante qu’à partir du réseau local (ou une liste de réseaux prédéfinis). Cela est parfait lorsqu’on envoie toujours les mails de chez soi, avec au besoin la possibilité d’envoyer un mail de n’importe où grâce au webmail.

Mais l’utilisation du SMTP à distance devient utile lorsqu’on veut envoyer un mail à partir de chez un ami avec son client mail (plus pratique pour les pièces jointes par exemple), et cela devient carrément indispensable lorsqu’on veut écrire des mails à partir de son téléphone de n’importe où (sans IP fixe).

Ne plus restreindre l’utilisation du SMTP au réseau local implique évidemment de rajouter une couche d’authentification…

Je vais donc décrire comment mettre en place une authentification SMTP-AUTH « en clair » (bien sûr encapsulée dans une connexion chiffrée TLS, déjà configurée si vous avez suivi le premier tuto) qui correspond au login et mot de passe de l’utilisateur système. Il a été écrit pour une installation sur Ubuntu Server 9.10, il faudra donc peut-être l’adapter légèrement si vous utilisez autre chose.

Configuration de SASL

Il faut installer le paquet sasl2-bin :

sudo apt-get install sasl2-bin

et ajouter l’utilisateur postfix au groupe sasl :

sudo adduser postfix sasl

Ouvrez ensuite /etc/default/saslauthd, remplacez :

START=no

par :

START=yes

et remplacez la dernière ligne par :

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Démarrez le service :

sudo /etc/init.d/saslauthd start

Configuration de postfix

À la fin de /etc/postfix/main.cf, rajoutez :

# SASL
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

Dans ce même fichier, vous pouvez également supprimer le réseau 192.168.0.0/24 de la variable mynetworks (si vous l’aviez rajouté).

Créez le fichier /etc/postfix/sasl/smtpd.conf contenant :

pwcheck_method: saslauthd
mech_list: plain login

Rechargez la configuration de postfix :

sudo /etc/init.d/postfix reload

Voilà, tout est prêt.

Configuration du client mail

Dans votre client mail, indiquez que le serveur SMTP requiert une authentification, de type CLAIR (ou PLAIN), et précisez votre compte utilisateur à utiliser.

Il peut-être pratique, en plus de cela, d’accéder à ses mails par un webmail de n’importe où (notamment au travail, où il ne sera pas filtré comme celui de gmail ou de yahoo, puisque c’est un webmail perso).

Je profite de la réinstallation à neuf de mon serveur pour présenter l’installation de RoundCube, un webmail assez moderne, à installer sur LAMP (avec accès HTTPS) sur Ubuntu Server.

Voici ce que ça donne une fois installé :

Je partirai du principe que le webmail est sur la même machine que le serveur SMTP et que le répertoire ~/Maildir (contenant les mails), et qu’il sera le seul site hébergé en HTTPS sur le serveur.

Téléchargement

Tout d’abord, il faut télécharger l’archive sur le site de RoundCube (la version complète), et l’extraire dans un répertoire :

tar xzf roundcubemail-0.3.1.tar.gz

Il est plus pratique de le renommer :

mv roundcubemail-0.3.1 mail

Ensuite, il faut donner les droits au serveur d’écrire dans les répertoires temp et logs :

sudo chmod -R 777 mail/temp mail/logs

Enfin, faire un lien du répertoire d’installation de RoundCube (par exemple ~/mail) dans /var/www.

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

Préparation de la base de données

Il faut créer une base de données qui sera utilisée par RoundCube, avec son propre utilisateur. Pour cela, démarrer mysql en tant qu’administrateur (le login et le mot de passe choisi lors de la configuration de mysql) :

$ mysql -uroot -p
Enter password:

Ensuite, créer une base de données :

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

Puis un utilisateur mysql (par exemple mailuser/unmotdepasse) :

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

Voilà, la base de données est prête à accueillir RoundCube.

Configuration d’Apache

Tout d’abord, il faut activer le mod ssl d’apache :

sudo a2enmod ssl

Et renseigner le champ date.timezone de php.ini :

sudo nano /etc/php5/apache2/php.ini

Remplacer la ligne :

;date.timezone =

par :

date.timezone = 'Europe/Paris'

Ensuite, il faut créer un VirtualHost qui décrit à Apache le site qu’il doit héberger (le nom du site sur lequel il répond en http, quels répertoires doivent être accessibles, etc.).

Voici un modèle (qui correspond à mon VirtualHost), qui permet :

• d’afficher le site contenu dans /var/www/mail lorsqu’une requête arrive sur le port 443 (https), c’est-à-dire quand je tape https://mail.rom1v.com dans un navigateur ;
• d’interdire l’accès aux répertoires config, temp et logs ;
• de rediriger automatiquement http://mail.rom1v.com vers https://mail.rom1v.com.

NameVirtualHost *:443

<VirtualHost *:80>
	ServerName	mail.rom1v.com
	Redirect	/ https://mail.rom1v.com/
</VirtualHost>

<VirtualHost *:443>
	DocumentRoot	/var/www/mail
	ServerName	mail.rom1v.com
	SSLEngine on
	SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
	SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

	<Directory /var/www/mail/>
		Options FollowSymLinks MultiViews
		AllowOverride All
		Order allow,deny
		allow from all
	</Directory>

	<Directory /var/www/mail/config>
		Options -FollowSymLinks
		AllowOverride None
	</Directory>

	<Directory /var/www/mail/temp>
		Options -FollowSymLinks
		AllowOverride None
	</Directory>

	<Directory /var/www/mail/logs>
		Options -FollowSymLinks
		AllowOverride None
		Order allow,deny
		Deny from all
	</Directory>

	ErrorLog	/var/log/apache2/mail_error.log
	CustomLog	/var/log/apache2/mail_access.log combined

</VirtualHost>

Ce fichier, une fois adapté à votre serveur, est à écrire dans /etc/apache2/sites-available/ (dans un fichier nommé comme votre site par exemple, mail.rom1v.com pour moi).

Il faut ensuite l’activer :

sudo a2ensite mail.rom1v.com

Et recharger Apache :

sudo /etc/init.d/apache2 reload

Configuration de RoundCube

Il ne reste plus qu’à aller sur http://votreserveur/installer avec un navigateur pour configurer RoundCube.

Bien sûr, lors de la première connexion, Firefox vous alerte car il ne connaît pas votre certificat SSL (qui est auto-signé), il suffit de lui indiquer que vous faites confiance à ce site (puisque c’est le vôtre) en ajoutant une exception.

L’étape 1 (Check environment) doit bien se passer (à part quelques modules optionnels que vous n’avez pas, ce n’est pas grave).

Pour l’étape 2 (Create config) :

• Choisir un product_name : le titre des pages souhaité ;
• Activer ip_check ;
• Désactiver enable_spellcheck (sinon tous vos mails seront envoyés à Google) ;
• Renseigner les données pour l’accès à la base de données (que nous avons créée tout à l’heure) ;
• Dans la partie IMAP, renseigner uniquement default_host à la valeur localhost ;
• Laissez par défaut le reste de la partie IMAP et la partie SMTP (vu que les mails sont sur la même machine).

Lors de la validation, deux fichiers sont générés. Il faut les télécharger et les placer dans le répertoire config/ (ce n’est pas très pratique d’ailleurs, lorsqu’on accède au serveur par ssh, devoir télécharger les fichiers localement pour les renvoyer au serveur est un peu tordu).

L’étape 3 (Test config) permet de tester que tout est OK. Il faut cliquer sur Initialize database.

Une fois ces étapes effectuées, rendez-vous sur l’adresse du webmail, vérifiez que ça fonctionne (avec votre login système et votre mot de passe). Si tout est ok, supprimez le répertoire installer/ :

rm -rf /var/www/mail/installer

Modifier les préférences

Une fois connecté, il est possible de changer les préférences utilisateur. Je vous laisse découvrir les options par vous-même, mais certaines sont importantes.

Tout d’abord, dans l’onglet identités, renseignez votre adresse mail (par défaut c’est login@localhost, ce qui posera des problèmes à ceux qui voudront vous répondre).

Ensuite, activez les options qui concernent la suppression d’un message sur un compte IMAP dans Préférences du serveur de l’onglet Préférences :

• Mettre le drapeau de suppression au lieu de supprimer (sinon vous ne pourrez pas supprimer de messages) ;
• Ne pas montrer les messages supprimés (sinon vous les verrez encore en barré)

Conclusion

Bravo. Vous avez maintenant un serveur mail perso avec un accès webmail sur HTTPS en plus de votre accès IMAP/TLS. Vous gagnez 1 point de liberté et 1 point de confort.

Après avoir acheté un petit serveur pour y héberger ce dont j’avais besoin, mon objectif est d’héberger TOUT ce qui n’a rien à faire ailleurs. Et comme l’explique Benjamin Bayart dans sa désormais célèbre conférence Internet libre ou Minitel 2.0, toutes nos données personnelles entrent dans cette catégorie.

Mon blog est un bon exemple d’un contenu qui ne doit pas être hébergé ailleurs. La liste des flux RSS que je consulte aussi (c’est pourquoi j’ai installé tt-rss). Mon album photos à partager avec la famille également (j’ai installé gallery). Mais il restait le plus important : les mails.

Et c’est bien moins compliqué à installer que je ne l’imaginais !

Je vais donc présenter comment installer son propre serveur de mails sur Ubuntu Server (si vous utilisez autre chose, ça ne devrait pas être bien dur à adapter). Ainsi, vous pourrez avoir une jolie adresse login@mondomaine.

Prérequis

Je supposerai que vous avez déjà un nom de domaine et que vous savez ajouter des enregistrements A et MX (généralement dans l’interface fournie par votre registrar).

Présentation

Pour mettre en place un serveur mail complet, nous avons besoin de deux choses : un serveur SMTP (qui gère le transport du courrier) et un serveur IMAP ou POP3 (permettant de se connecter à sa boîte aux lettres).

J’ai choisi respectivement postfix et dovecot (ceux par défaut dans Ubuntu Server).

Il est possible de faire tout un tas de choses compliquées, ici je vais aller au plus simple. Au final on obtiendra donc un compte mail par utilisateur système (avec son mot de passe système), un serveur SMTP et un accès IMAP, le tout sécurisé sur TLS. Le serveur SMTP ne pourra relayer les mails envoyés qu’à partir du réseau local.

Configuration DNS

Rajoutez deux records de type A à votre fichier de zones DNS (smtp et imap – histoire de faire comme tout le monde, mais vous mettez ce que vous voulez –), et ajoutez un record de type MX qui pointe vers votre enregistrement smtp (smtp.rom1v.com. – n’oubliez pas le . à la fin –).

Il faut bien sûr ouvrir les ports sur le routeur et dans le pare-feu…
Pour rappel :

• SMTP = 25
• POP = 110
• POP3S = 995
• IMAP = 143
• IMAPS = 993

Serveur

postfix

Si vous n’avez pas déjà les paquets installés :

sudo apt-get install postfix dovecot-imapd

Si vous aviez déjà postfix :

sudo dpkg-reconfigure postfix

Vous obtenez un écran de configuration debconf qui va vous prendre par la main pour la configuration :

1. Configuration type du serveur de messagerie : Site Internet
2. Nom de courrier : votre nom de domaine (rom1v.com pour moi)
3. Destinataire des courriels de « root » et de « postmaster » : votre login sur le serveur (rom pour moi)
4. Autres destinations pour lesquelles le courrier sera accepté : rajoutez votre nom de domaine dans la liste (rom1v.com)
5. Forcer des mises à jour synchronisées de la file d’attente des courriels : non (laisser par défaut)
6. Réseaux internes : 127.0.0.0/8, 192.168.0.0/24 si votre réseau local est 192.168.0.x
7. Utiliser procmail pour la distribution locale : non (allons au plus simple)
8. Taille maximale des boîtes aux lettres (en octets) : à vous de choisir, moi j’ai mis 5Gio (5368709120) (les créateurs de logiciels qui proposent 50Mio ne doivent pas recevoir des mails de gens n’y connaissant rien qui envoient en triple des photos en 10 mégapixels)
9. Caractère d’extension pour les adresse locales : + (laisser par défaut)
10. Protocoles internet à utiliser : ipv4 (au plus simple on a dit !)

Vous avez alors un fichier /etc/postfix/main.cf qui ressemble à ceci (sauf la dernière ligne) :

myhostname = rom1v.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = rom1v.com, rom-eeebox, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8, 192.168.0.0/24
mailbox_size_limit = 5368709120
recipient_delimiter = +
inet_interfaces = all
myorigin = /etc/mailname
inet_protocols = ipv4
home_mailbox = Maildir/

Ajoutez donc la dernière ligne (c’est très important pour faire fonctionner IMAP).

Voilà, le serveur SMTP est prêt :

sudo /etc/init.d/postfix restart

Il ne sera possible d’envoyer un mail qu’à partir des réseaux définis dans mynetworks (c’est pour cela qu’il n’y a pas d’authentification par défaut).

EDIT 02/01/2010 : Pour mettre en place une authentification plutôt que de limiter l’accès à une liste de réseaux, lisez ce billet.

dovecot

Il y a deux choses à changer dans le fichier /etc/dovecot/dovecot.conf, tout d’abord pour activer le protocole IMAP :

protocols = imap

Ensuite pour choisir le répertoire de stockage des mails pour les utilisateurs (forcément ~/Maildir) :

mail_location = maildir:~/Maildir

Enfin, il faut préparer ce répertoire en exécutant la commande :

maildirmake ~/Maildir

Voilà, c’est fini :

sudo /etc/init.d/dovecot restart

Client

Le serveur est configuré, nous pouvons maintenant l’utiliser.

mailtutils

Commençons par le tester grâce au paquet mailutils qui permet d’envoyer des mails en ligne de commande :

sudo apt-get install mailutils

Directement sur le serveur :

$ mail login@mondomaine
Cc:
Subject: Mon premier serveur
Ça y'est, j'ai configuré mon premier serveur !

(terminer avec une nouvelle ligne suivi de Ctrl+D)
Le mail a dû arriver dans ~/Maildir/new.

Un vrai client

Comme pour n’importe quelle adresse e-mail, il suffit de configurer le client (Evolution par exemple) en renseignant les champs demandés.

Réception

Type de serveur : IMAP
Serveur : imap.rom1v.com (à adapter avec votre nom de domaine)
Nom d’utilisateur : votre login sur le serveur
Sécurité : Chiffrement TLS
Type d’authentification : Mot de passe

Envoi

Type de serveur : SMTP
Serveur : smtp.rom1v.com (à adapter avec votre nom de domaine)
Nom d’utilisateur : votre login sur le serveur
Sécurité : Chiffrement TLS
Pas d’authentification.

Sauvegardes

Bien entendu, maintenant que vous hébergez vos mails, vous êtes responsables de leur stockage, et donc des backups. Mais j’imagine que cela ne vous posera pas de problèmes, car vous avez bien évidemment déjà mis en place un système (au moins rsync) qui sauvegarde vos données sur une autre machine : il suffira donc de rajouter le répertoire ~/Mailbox à la liste des répertoires sauvegardés.

Disponibilité

Si le serveur est déconnecté moins de 48 heures, ce n’est pas catastrophique, les mails ne seront probablement pas perdus, la majorité des serveurs SMTP tentent de renvoyer le courrier après un échec. Évidemment, si le serveur est éteint durant un mois, il n’y a pas de magie : pas de serveur, pas de mails…

Conclusion

Cette étape est pour moi un pas de plus vers un internet libre…

J’ai présenté le minimum vital, mais vous pouvez trouver des fonctionnalités à mettre en place (un webmail tel que RoundCube, un anti-spam, le tri des mails sur le serveur, une authentification SMTP…).

Amusez-vous bien !

Il y a un serveur et n clients. C’est le serveur qui possède le clavier et la souris.

Tout d’abord, sur chacun des postes, il faut installer le paquet synergy.

Ensuite, sur le serveur, il faut créer un fichier de configuration ~/.synergy.conf, extrêmement simple :

section: screens
   rom-laptop:
   rom-desktop:
end
section: links
   rom-desktop:
       left = rom-laptop
   rom-laptop:
       right = rom-desktop
end

Ici, rom-laptop est mon portable (le serveur) et rom-desktop est mon fixe (le client). C’est le nom de la machine, que l’on peut connaître avec :

echo $HOSTNAME

La section screen définit la liste des machines, et la section links définit leur position relative.

Ensuite, côté serveur, on tape :

synergys

Et sur chaque client :

synergyc ip_du_serveur

Les clients peuvent être lancés avant le serveur, ils vont tenter de se reconnecter 1 seconde après, puis 3 secondes après, puis 5, puis 15, puis 30 et enfin toutes les minutes. Ils survivent à la déconnexion du serveur, et tentent de se reconnecter en suivant la même règle.

Pour arrêter la connexion, sur le serveur :

killall synergys

et sur les clients :

killall synergyc

Pour aller plus loin :

Éviter le changement d’écran involontaire
Après quelques minutes d’utilisation, on se rend compte que lorsqu’on est sur le PC de gauche, et qu’on va à la droite de l’écran (pour déplacer la scrollbar de Firefox en plein écran par exemple), on se retrouve involontairement sur l’écran de droite, c’est très embêtant.
Mais c’est très facile d’y remédier, il suffit d’ajouter l’option :

section: options
   switchDoubleTap = 400
end

Cela permet de ne changer d’écran qu’en cas de double-contact en moins de 400ms avec le bord de l’écran.

Démarrer automatiquement
Sous GNOME (à adapter pour les autres environnements), il suffit de rajouter au fichier ~/.gnomerc la commande du serveur ou du client selon le cas.
Pour le serveur :

echo 'synergys' >> ~/.gnomerc

Pour le client :

echo 'synergyc ip_du_serveur' >> ~/.gnomerc

Décaler les écrans
Deux écrans côte à côte ne sont pas forcément alignés et ils n’ont pas forcément la même hauteur.
Par exemple l’écran de mon fixe est un 5:4 et il est un peu surélevé, celui de mon portable est un 16:10 et il est plus bas.
Pourtant, quand je déplace la souris d’un écran à l’autre, je voudrais que la souris reste à la même hauteur. Aucun problème, on peut passer des arguments (start,end), exprimés en pourcentage de l’écran, entre 0 et 100 inclus :

section: screens
    rom-laptop:
    rom-desktop:
end
section: links
    rom-desktop:
        left(35,100) = rom-laptop(0,85)
    rom-laptop:
        right(0,85) = rom-desktop(35,100)
end
section: options
    switchDoubleTap = 400
end

Ici, la partie supérieure de mon portable ([0%;85%]) est en face de la partie basse de mon fixe ([35%;100%]).
Remarque : la relation n’a pas besoin d’être symétrique, mais c’est plus logique qu’elle le soit

Démarrer chacun des clients à distance
Si l’on ne veut pas démarrer synergy au démarrage, on souhaiterais pouvoir le faire rapidement sans passer sur chacun des PC pour exécuter une commande. Avec une connexion SSH correctement configurée (par clés de préférence), on peut automatiser le lancement de tous les clients :

synergys
ssh rom-desktop synergyc rom-laptop
ssh un-autre-pc synergyc rom-laptop

(rom-laptop est défini dans /etc/hosts)

Sécuriser la connexion
Synergy ne crypte pas les communications, donc tout passe en clair sur le réseau (enfin, du moins pour ceux qui connaissent la clé WPA de votre réseau, si vous êtes en wifi).
Pour crypter, il suffit de faire passer la connexion dans un tunnel SSH. Pour cela, sur chacun des clients :

ssh rom-laptop -fCNL24800:localhost:24800 synergyc localhost

Ce qui est embêtant, c’est qu’il faut décrypter sur chacun des postes la clé privée, et donc c’est problématique pour démarrer synergy au démarrage du système.

Un grand merci à Génération Linux qui m’a fait découvrir cet outil maintenant indispensable.

Il y a plein de méthodes, mais parfois la plus rudimentaire fonctionne très bien : écrire directement en TCP !

Pour cela, sur un pc (192.168.0.1 par exemple), faites :

nc -l -p 1234

-l veut dire listen (ça veut dire qu’on lance un serveur)
-p 1234 précise le port, choisissez ce que vous voulez

Sur un autre pc :

nc 192.168.0.1 1234

Et ça y’est, vous avez un tuyau de communication bidirectionnel, pratique pour faire des copiers-collers d’un ordinateur à l’autre. Si vous ouvrez le port correspondant sur votre routeur, ça marche aussi sur internet, bien évidemment.

L’avantage c’est que nc (ou netcat) est installé par défaut.

On peut aussi transférer des fichiers :

nc -l -p 1234 > monfichier

cat unfichier | nc 192.168.0.1 1234

(terminer par Ctrl+C)

En voici une très simple, grâce à Rhythmbox (le lecteur par défaut d’Ubuntu).

Pour activer le partage, dans Édition → Greffons, il suffit d’activer Partage de musique DAAP (cette case est déjà activée par défaut dans Ubuntu 8.10), de cliquer sur Configurer, et d’activer Partager ma musique.

Vous obtiendrez une nouvelle entrée dans le menu de gauche de Rhythmbox, et vous pourrez lire directement toute la musique se trouvant sur un autre ordinateur :

Rhythmbox doit resté ouvert sur l’ordinateur « serveur ».

J’ai ensuite présenté comment rediriger le son vers un autre PC (grâce à PulseAudio).

Le problème, c’est qu’avec PulseAudio, l’exécution d’un lecteur audio à distance avec l’affichage en local ne fonctionne plus : le son ne sort nulle part, même si à l’écran tout a l’air de fonctionner :

ssh monserveur -XC rhythmbox

En effet, la variable d’environnement PULSE_SERVER n’étant pas affectée lors d’un ssh -X, le lecteur ne trouve pas de serveur audio.

La solution propre serait de rajouter une ligne dans ~/.pulse/client.conf :

echo "default-server={$HOSTNAME}unix:/tmp/pulse-$USER/native" >> ~/.pulse/client.conf

Mais un bug de pulse audio, corrigé dans la version 0.9.12, fait que cette solution ne fonctionne pas. Et malheureusement, cette version de pulse audio ne devrait pas apparaître dans Ubuntu avant la version 9.04.

Une solution consiste donc à l’initialiser lors du lancement du lecteur audio :

ssh monserveur -XC 'PULSE_SERVER="{$HOSTNAME}unix:/tmp/pulse-$USER/native" rhythmbox'

Si vraiment l’on veut éviter d’affecter cette variable à chaque fois manuellement, on peut rajouter à la fin du fichier /etc/ssh/sshd_config la ligne suivante :

PermitUserEnvironment yes

puis, toujours sur le serveur, définir la variable d’environment dans le fichier ~/.ssh/environment :

echo "PULSE_SERVER={$HOSTNAME}unix:/tmp/pulse-$USER/native" >> ~/.ssh/environment

Après avoir redémarré le serveur :

sudo /etc/init.d/ssh restart

il est possible de lancer sur le client :

ssh monserveur -XC rhythmbox

Le son ne sera plus perdu dans une faille de l’espace-temps

Maintenant, prenons un autre cas de figure : je veux que les sons qui sortent actuellement sur le PC portable soient finalement redirigés vers l’ampli (par exemple le son d’une vidéo lue dans un navigateur).

Ceci est possible grâce au serveur de son PulseAudio intégré à Ubuntu 8.04. Et en plus, c’est très simple à mettre en œuvre.

Tout d’abord, installez le paquet padevchooser à la fois sur le PC serveur et sur le PC client, puis lancez padevchooser en console (ou allez dans le menu Applications → Son et vidéo → PulseAudio Device Chooser) : une icône apparaît alors dans le systray.

Sur le serveur, cliquez sur cette icône, puis « Configure Local Sound Server… », et dans l’onglet « Multicast/RTP », activez « Enable Multicast/RTP receiver« .
Sur le client, faites de même, sauf que c’est « Enable Multicast/RTP sender » qu’il faut activer.
Les deux machines peuvent avoir simultanément le rôle de client et de serveur.

Ensuite, sur le client, cliquez sur l’icône de PulseAudio dans le systray, puis « Volume Control ». Pour chaque flux sortant (ici VLC et Rhythmbox), vous pouvez choisir si le son doit sortir en local ou à distance :

Le réglage est appliqué « à chaud » (le son change aussitôt de sortie audio).

Il est possible de configurer de manière plus précise, pour choisir sur quelle carte son de quel PC le son doit sortir, ainsi que de définir une sortie son par défaut. Je vous laisse fouiller les préférences

Merci à Compte0 qui m’a fait découvrir cette fonctionnalité.

Note : pour que cela fonctionne avec les vidéos Flash, il faut le paquet libflashsupport, en attendant que Flash supporte nativement PulseAudio.
Attention cependant, il est possible avec ce paquet que des plantages de Firefox surviennent aléatoirement sur des pages contenant du Flash ; si cela vous arrive, désinstallez simplement le paquet.
Vous pouvez également tester la version RC de Flash Player 10, qui supporte PulseAudio en natif, ou attendre la version 8.10 d’Ubuntu, prévue pour le 30 octobre 2008.

EDIT: Tout fonctionne correctement depuis la version 8.10.

Eh bien moi non, pas encore (trop chanceux!). Et pour éviter que ça se produise, j’ai mis en place une petite politique de backup, très simple.

Alors évidemment, j’avais déjà fait des « backups » : quand un répertoire est important, je le copie autre part. Et quand il est modifié, je supprime l’ancien backup et je le recopie de nouveau (ou j’écrase l’ancien par le nouveau).
Mais par exemple pour le répertoire de photos ou autre, quand ça prend 5Gio, c’est beaucoup trop long.

Voici donc comment faire un backup « incrémental » : seuls les fichiers modifiés, ajoutés ou supprimés seront modifiés côté « backup ».
Et en plus, ça marche aussi à distance (on peut backuper un répertoire dans un autre sur la même machine, mais également sur une machine différente, par ssh).

Voici par exemple le script que j’utilise pour faire un backup de mon portable dans un répertoire de mon fixe :

#!/bin/sh
cmd='rsync -rpltv --del'

backup_dir='rom-desktop:/media/gnu/backup/rom-laptop'
$cmd
/home/rom/work
/home/rom/java
/home/rom/docs
/home/rom/.thunderbird
/home/rom/.mozilla
/home/rom/sh
$backup_dir

(.mozilla et .thunderbird, c’est la configuration de firefox et thunderbird, ainsi que tous les favoris, mails, comptes…)

Et du fixe vers le fixe (d’un disque dur vers un autre) :

#!/bin/sh
cmd='rsync -rpltv --del'

backup_dir='/media/gnu/backup/rom-desktop'
$cmd
/media/tux/photos
$backup_dir

Plus d’infos sur les paramètres de rsync :
-r parcours le dossier indiqué et tous ses sous-dossiers (récursivement)
-p préserve les droits
-l copie les liens symboliques comme liens symboliques
-t préserve les dates (important pour les photos)
-v plus verbeux
--del permet de supprimer les fichiers sur destination qui n’existent plus sur source

$cmd c’est la commande rsync avec ses paramètres
$backup_dir c’est la destination :

• machine:/répertoire si distant
• /répertoire si local

Ensuite, vous pouvez lancer le script de temps en temps, manuellement (ce que je fais) ou programmé (la nuit ?).

Les slides
La documentation détaillée

Les sources tex