GuiGui's show

Avant de traiter le sujet principal de ce billet, je voudrais vous dire que les articles suivants ont été mis à jour plus ou moins récemment :

Pourquoi mettre à jour des vieux billets plutôt que d'en poster un tout nouveau ? Il est plus facile, lorsque je veux retrouver une commande GNU/Linux ou un paramètre de SSH, de savoir dans quel billet chercher plutôt que de chercher dans tous les billets de mon blog.

Ceci étant dit, venons-en au sujet principale, qui commencera par un coup de gueule.

Table des matières

Film, où puis-je te trouver ?

Un ami m'a présenté un film. Ayant bien aimé ce film, j'ai décidé de me le procurer dans une meilleure qualité (vive les rips pourris circulant sur le net). Je cherche donc sur les principaux sites de VOD (Canalplay, Tf1vision, vod.fnac.com, totalvod.com, ...). Rien. Ça commence déjà à m'énerver (et j'expliquerai pourquoi ci-dessous).

Bon, je me résigne à acheter le DVD . Je vais sur le site de la Fnac, sur Cultura, rien. Sur Amazon.fr je trouve enfin ce que je cherche ! Le seul problème est qu'il s'agit d'un import anglais. Rien n'est précisé concernant les langues et les sous-titres disponibles sur le DVD. Dans un tel flou, vous comprenez bien que je n'allais pas effectuer l'achat.

Je finis par trouver un DVD en occasion.

Moralité ?
D'une part, elle confirme que l'offre légale française est bien trop pauvre. Avant de sanctionner le téléchargement illégal, il faudrait peut-être proposer une alternative légale. Quand je vois la pauvreté des plates formes de VOD, et pas seulement à travers cet exemple, je me dis que les majors n'ont pas compris, comme si je ne m'en doutais pas auparavant, les nouvelles volontés de consommation : non je ne veux pas commander un support physique, fragile qui plus est, que je vais devoir attendre (cas d'une livraison postale) ou que je vais devoir aller chercher en magasin. Je ne veux pas attendre, je veux consommer maintenant.

D'autre part, elle montre que, sans parler de téléchargement illégal, de l'argent échappe aujourd'hui aux mains des majors à cause de leur refus de s'adapter. Mon achat d'occasion n'a rien rapporté aux majors. Ça encore, cela ne me pèsera pas sur la conscience. Par contre, savoir que les personnes qui ont exercées une forme d'art à travers ce film, à savoir les vrais acteurs de la création (acteurs, scénaristes, etc.), ne seront pas rémunérées, cela me dérange un peu plus. Le pire, c'est que la faute incombe à leurs distributeurs adorés (sauf exceptions), pourtant censés les aider.

Le moment de la lecture

Évidemment, le DVD que j'ai acquis est protégé par la technologie CSS. Sa lecture est donc impossible, par défaut, sous Ubuntu.

Mais sommes-nous en droit de contourner la protection CSS ? Pour avoir une réponse claire et nette, lisez : rappels législatifs - Documentation Ubuntu Francophone.

Nous sommes typiquement dans le cas de l'interopérabilité. Vous pouvez donc ajouter le sous dépot non-free du dépot Medibuntu. Pour cela, voir : médibuntu - Documentation Ubuntu Francophone.

Vous pouvez ensuite installer la libdvdcss2, qui permet de déchiffrer la protection CSS des DVD avec n'importe quel lecteur :

sudo apt-get update && sudo apt-get install libdvdcss2

Vous pouvez maintenant lire votre DVD avec VLC, Kafféine, etc ...

Et si je veux conserver une copie ?

Vu la fragilité des DVD et les aléas de la vie vous voulez faire une copie de votre DVD sur votre disque dur ? Vous allez rire si vous ne le savez pas : vous n'en avez pas le droit. Voir le lien concernant les rappels juridiques donné plus haut. Vous êtes typiquement dans le cas d'une copie à usage privé pour laquelle vous avez rémunéré les majors (je refuse de dire que la taxe copie privée rémunère la création, les vrais créateurs et l'art) mais pour laquelle vous devez contourner une protection.

Néanmoins, je tiens à affirmer que j'ai acheté une œuvre de l'esprit, pas un bête support, pas un bête DVD. Je tiens donc à affirmer mon droit à garder cette œuvre, pour un usage privé, via une copie.

Attention : je considère ici que vous avez déjà installé la libdvdcss2. Si ce n'est pas le cas, lisez, ci-dessus, le bloc traitant de la lecture d'un DVD sous Ubuntu.

J'ai voulu utiliser la classique commande dd. Sans la libdvdcss2, il copie presque 1 mo et s'arrête. Avec la libdvdcss2, dd copie bien le DVD mais la protection CSS demeure sur l'image ISO, ce qui est logique. Cette solution n'est donc pas satisfaisante.

On se doute alors qu'il existe sous GNU/Linux un équivalent aux logiciels DVD Shrink, DVD Fab et autres de WIndows. Personnellement, j'ai utilisé k9copy et je n'ai rien a lui reprocher.

Dans un premier temps : il faut ajouter le dépôt multiverse : dépots - Documentation Ubuntu Francophone.

Installer k9copy :

sudo apt-get install k9copy vamps dvdauthor

Vous n'avez plus qu'a utiliser k9copy. Je ne vous en expliquerai pas le fonctionnement : il est intuitif. Néanmoins, pour une copie complète et identique de votre DVD, cochez toutes les pistes vidéos, audio, sous-titres que k9copy n'a pas coché pour vous (les pistes étrangères notamment). Vérifiez que le facteur est de 1.0 et lancez la copie dans une image ISO, un DVD ou un dossier sur votre disque dur.

Astuce : si vous comptez réutiliser k9copy pour d'autres DVDs et que vous ne voulez pas cocher à la main les pistes étrangères à chaque fois, allez dans le menu "Configuration", puis dans "Configurer k9copy". Dans la partie "DVD" (à gauche), remarquez la partie "Langues préférées". Pour l'audio et les sous-titres, choisissez "Non spécifié". Sauvegardez les paramètres. Re-ouvrez votre DVD : k9copy a coché toutes les pistes (mêmes étrangères) automatiquement.

A l'insu de la copie, vous récupèrerez un contenu sans protection.

L'heure de faire le ménage

Si vous ne supportez pas de voir tous ces paquets non libres installés sur votre ordinateur et si vous avez finis de copier vos DVDs :

Désinstallez la libdvdcss2 :

sudo apt-get autoremove --purge libdvdcss2

Désinstallez k9copy et ses dépendances :

sudo apt-get autoremove --purge k9copy dvdauthor vamps

Supprimez le dépôt multiverse : il vous suffit d'enlever les lignes que vous avez rajoutées à votre fichier /etc/apt/sources.list.

Supprimez le dépôt medibuntu :

sudo rm /etc/apt/sources.list.d/medibuntu.list /etc/apt/sources.list.d/medibuntu.list.save
sudo apt-get autoremove --purge medibuntu-keyring

J'arrive à peine à y croire mais pourtant c'est vrai : c'est une multinationale qui a réussit à me faire poster le premier billet d'humeur positif et ainsi à me faire changer le titre de ma catégorie "Coups de gueule" pour "Humeur".

Explication : je possède un sac à dos, de marque Eastpak, depuis de nombreuses années et il m'arrive encore de l'utiliser de temps en temps. Sa toile et ses fermetures à glissière ont résistées à la torture pendant toutes ces années. Mais, la fermeture principale a lâchée mi-janvier 2011 : certaines dents étaient complètement cassées et rendaient la fermeture et/ou l'ouverture du sac totalement impossible.

Je me souviens alors qu'Eastpak garantit la quasi totalité de ses produits durant 30 ans et que c'est d'ailleurs un des points forts de l'image de la marque. Toujours septique devant de telles promesses commerciales, je me mets à la lecture des termes de la garantie Eastpak. Je tique plusieurs fois sur l'expression "conditions normales". Que considère-t-on comme un usage normal du produit ?

De plus, je n'ai plus aucune preuve d'achat de ce sac. La garantie va-t-elle fonctionner dans ce cas-là ? Devant ces interrogations, je cherche les avis d'autres personnes sur le grand Web.

Je trouve des avis, même récents, de personnes ayant des sacs dans un état similaire au mien et pour qui la garantie a fonctionnée.

Je fais un rapide calcul : ce sac coûte environ 40€ selon les boutiques. Si Eastpak ne prend pas mon sac en charge, cela me fais donc un coût total de renouvellement de 40 (nouveau sac) + 9,50 (prix d'un Colissimo Emballage France M envoyé pour rien) soit 49,50€. Par contre, si Eastpak prend en charge le sac, cela me fais un renouvellement de sac à 9,50€, soit 30,50€ "d'économie".

Note pour les personnes intéressées : le Colissimo France ou le Colissimo Emballage France souple (7.90€) coûtent moins cher et semblent aptes à transporter un sac mais je m'en suis aperçu trop tard.

Je décide donc d'envoyer mon sac en garantie. J'imprime le formulaire de garantie tout bête d'Eastpak (encore un bon point pour eux) et j'envoie le sac le 19 janvier 2011 en m'attendant à le recevoir dans 3 semaines (délai communément admis sur les forums du grand Web).

ÉDIT du 03/07/2012 à 20h55 : Je suis désolé mais le lien exact vers le formulaire de réparation change assez régulièrement. Si le lien ci-dessus n'est plus en usage, une recherche sur un moteur de recherche avec les mots-clés "formulaire de reparation site:eastpak.com filetype:pdf" devrait vous permettre de le trouver facilement. Fin de l'édit.

J'ai finalement reçu mon sac, réparé, le 31 janvier 2011 soit 11 jours (dont 7 jours ouvrés) après l'envoi. Bien joué Eastpak :).

Que demander de plus ? Que dire de plus ?

Table des matières

Nous allons voir, rapidement, comment configurer le noyau, avec iptables, lors de l'utilisation d'un réseau insecure. L'objectif premier est d'éviter la fuite de trafic réseau en dehors de notre tunnel SSH.

Savoir quels flux doivent circuler

En entrée

• Tous les paquets appartenant à une connexion que nous avons ouverte doivent pouvoir entrer.
• Tous les paquets relatifs à une connexion que nous avons ouverte doivent pouvoir entrer (c'est notamment le cas de certains messages d'erreur ICMP).
• Facultatif : les paquets DHCP doivent pouvoir passer si vous utilisez ce protocole.
• Tous les paquets en provenance de la boucle locale (127.0.0.1) doivent pouvoir passer (le port forwarding via SSH fait partit de cette catégorie dans le sens où SSH doit être autorisé à recevoir des paquets sur un port précis (6666 dans mon cas)).

En sortie

• Tous les paquets à destination de la boucle locale (127.0.0.1) doivent pouvoir passer (là aussi, le port forwarding via SSH fait partit de cette catégorie dans le sens où les programmes doivent être autorisés à émettre en direction de ce port et SSH doit être autorisé à émettre depuis ce port vers les programmes).
• Tous les paquets à destination du port tcp/443 (https) du serveur web hébergeant le portail captif doivent passer à condition que le programme soit cURL (afin de faire de la connexion automatique, nous y reviendrons dans un prochain billet).
• Tous les paquets à destination du port 53 (tcp ou udp, voir billet précédent) du résolveur DNS du réseau insecure doivent passer à condition que le programme émetteur soit ssh ou scp (afin de résoudre le nom de domaine de votre serveur SSH).
• Facultatif : les paquets DHCP doivent pouvoir passer si vous utilisez ce protocole.
• Tous les paquets à destination du port tcp/22 sont autorisés si ils sont émis par ssh.

Comment savoir quel est le programme émetteur ?

Je suis certain que d'autres outils sont plus adaptés néanmoins je souhaite utiliser uniquement iptables dans le cas suivant.

La théorie

Iptables possède un module "owner" qui permet de réaliser un traitement sur un paquet selon l'uid ou le gid du programme qui a créé la socket. Sur les noyaux non SMP destinés aux systèmes n'ayant qu'un seul processeur avec un seul core, iptables propose d'autres options : traiter un paquet selon le pid du programme qui a ouvert la socket, le sid ou encore selon le chemin du programme sur le disque (cmd-owner).

Cette dernière option est celle qu'il nous faut. Mais comme je suis sur un noyau SMP, elle n'est pas présente. Il va donc falloir ruser.

Il faudrait que nos programmes aient un uid ou un gid unique qui permettrait de les reconnaitre ... bingo ! On va utiliser le setgid bit ! On aurait pu utiliser le setuid bit mais je pense que le gid bit aurai moins d'effets collatéraux.

Nous allons créer un groupe que nous appellerons "net". Nous allons ensuite modifier le groupe auquel appartient l'exécutable pour qu'il corresponde a "net". Puis nous activerons le setgid bit. Comme ça, le programme ne sera plus lancé avec le groupe de l'utilisateur qui le lancera mais bien avec le groupe "net". Iptables pourra donc reconnaitre ses sockets et laisser passer ses paquets.

Limites de cette méthode :

• Elle est fastidieuse : pour chaque programme dont nous voulons qu'il accède à un service réseau, il faut changer son groupe d'appartenance et activer le setgid bit.
• À chaque fois qu'un programme autorisé est mis à jour, le chown/chmod est perdu et le programme se retrouve donc bloqué par iptables. Il faut donc regarder attentivement son apt-get upgrade et s'en souvenir le jour où le programme ne marche plus.
• Dans le cas où il y a plusieurs utilisateurs sur la machine, des utilisateurs peuvent laisser fuiter des informations en compilant un programme et en changeant le groupe d'appartenance et en leur activant le setgid bit. Pour ceux qui en doute, rappelons qu'il y a deux personnes autorisées à utiliser chmod et chown sur un fichier donné : root et le propriétaire du fichier. Il faut quand même relativiser ce point là.

La pratique

On créer le groupe :

sudo groupadd net

Pour chaque programme que vous voulez autoriser :
Il faut d'abord trouver le chemin vers l'exécutable de ce programme (ici scp) :

whereis -b scp

Ensuite, il faut changer le groupe du fichier :

sudo chown root:net /usr/bin/scp

Puis, il faut activer le setgid bit :

sudo chmod g+s /usr/bin/scp

Écrire les règles iptables correspondantes

En entrée

Tous les paquets appartenant à une connexion que nous avons ouverte doivent pouvoir entrer.
Tous les paquets relatifs à une connexion que nous avons ouverte doivent pouvoir entrer.

sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Facultatif : les paquets DHCP doivent pouvoir passer si vous utilisez ce protocole.

sudo iptables -A INPUT -p udp -m state --state NEW -m udp --sport 67 --dport 68 -j ACCEPT

Tous les paquets en provenance de la boucle locale (127.0.0.1) doivent pouvoir passer

sudo iptables -A INPUT -i lo -j ACCEPT

Tout le reste est ignoré :

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP

En sortie

Tous les paquets à destination de la boucle locale (127.0.0.1) doivent pouvoir passer.

sudo iptables -A OUTPUT -d 127.0.0.1/32 -j ACCEPT

Tous les paquets à destination du port 443 (https) du serveur web (10.2.2.1) hébergeant le portail captif doivent passer à condition que le programme soit cURL.

sudo iptables -A OUTPUT -d 10.2.2.1/32 -p tcp -m tcp --dport 443 -m owner --gid-owner net -j ACCEPT

Tous les paquets à destination du port 53 du résolveur DNS (10.2.2.4) du réseau insecure doivent passer à condition que le programme émetteur soit ssh ou scp.

sudo iptables -A OUTPUT -d 10.2.2.4/32 -p udp -m udp --dport 53 -m owner --gid-owner net -j ACCEPT
sudo iptables -A OUTPUT -d 10.2.2.4/32 -p tcp -m tcp --dport 53 -m owner --gid-owner net -j ACCEPT

Tous les paquets à destination du port 22 sont autorisés si ils sont émis par ssh.

sudo iptables -A OUTPUT -p tcp -m tcp --dport 22 -m owner --gid-owner net -j ACCEPT

Facultatif : les paquets DHCP doivent pouvoir passer si vous utilisez ce protocole.

sudo iptables -A OUTPUT -p udp -m state --state NEW -m udp --sport 68 --dport 67 -j ACCEPT

Tout le reste est ignoré :

sudo iptables -P OUTPUT DROP

Conserver les règles

Pour sauvegarder les règles :

sudo iptables-save > reglesiptables

Voici ce que l'on obtient pour ce billet :

# Generated by iptables-save v1.4.12.2 on Tue Apr  3 16:52:20 2012
*filter
:INPUT DROP [36146:2386529]
:FORWARD DROP [0:0]
:OUTPUT DROP [224:17520]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --sport 67 --dport 68 -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -j ACCEPT
-A OUTPUT -d 10.2.2.1/32 -p tcp -m tcp --dport 443 -m owner --gid-owner 1001 -j ACCEPT
-A OUTPUT -d 10.2.2.4/32 -p udp -m udp --dport 53 -m owner --gid-owner 1001 -j ACCEPT
-A OUTPUT -d 10.2.2.5/32 -p udp -m udp --dport 53 -m owner --gid-owner 1001 -j ACCEPT
-A OUTPUT -d 10.2.2.4/32 -p tcp -m tcp --dport 53 -m owner --gid-owner 1001 -j ACCEPT
-A OUTPUT -d 10.2.2.5/32 -p tcp -m tcp --dport 53 -m owner --gid-owner 1001 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 22 -m owner --gid-owner 1001 -j ACCEPT
-A OUTPUT -p udp -m state --state NEW -m udp --sport 68 --dport 67 -j ACCEPT
COMMIT
# Completed on Tue Apr  3 16:52:20 2012

Pour les restaurer avant de vous connecter physiquement au réseau insecure, il faudra taper :

sudo iptables-restore < reglesiptables

Charger les règles au boot

ÉDIT du 30/12/2013 à 12h30 : Cette partie est inutile : iptables-persistent est disponible dans les dépôts Debian et fait le job. Fin de l'édit

Cela peut être utile si vous passez plus de temps sur un réseau insecure que sur un réseau secure.

Copions les règles sauvegardées par iptables-save dans /etc/init.d :

sudo cp reglesiptables /etc/init.d/reglesiptables

Créons un script /etc/init.d/loadIptables :

sudo vi /etc/init.d/loadIptables

Donnons-lui le contenu suivant :

#!/bin/bash

### BEGIN INIT INFO
# Provides:          loadIptables
# Required-Start:    
# Required-Stop:     
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# X-Interactive:     false
# Short-Description: Start/stop iptables rules
### END INIT INFO

 
iptables-restore < /etc/init.d/reglesiptables

Donnons les droits d'exécution à ce script :

sudo chmod +x /etc/init.d/loadIptables

Demander l'exécution de ce script au boot :

sudo update-rc.d loadIptables defaults

Une autre manière de faire serait d'utiliser le fichier /etc/network/interfaces et l'option "pre-up". Exemple :

allow-hotplug eth0
iface eth0 inet dhcp
pre-up iptables-restore < /etc/network/reglesiptables

Lisez le man interfaces pour plus d'informations.

A propos d'IPv6

Si vous voulez être sûr qu'aucune fuite n'aura lieu, vous pouvez configurer le noyau dans ce sens. Le principe est le même que celui exposé ci-dessus à l'exceptions des commandes (iptables => ip6tables, iptables-save => ip6tables-save, etc.) et des IP, évidemment 😉 .

Exemple de fichiers ip6tables :

# Generated by ip6tables-save v1.4.12.2 on Tue Apr  3 16:56:30 2012
*filter
:INPUT DROP [16:1280]
:FORWARD DROP [0:0]
:OUTPUT DROP [18:1152]
COMMIT
# Completed on Tue Apr  3 16:56:30 2012

Notes

• Certaines parties de ce billet sont inspirées (voir plus) de la documentation Ubuntu francophone : Iptables.
• La configuration proposée ci-dessus n'est pas très agressive puisqu'en définitive tous les programmes qui feront partit du groupe "net" et qui auront le setgid bit d'activé, auront accès aux ports tcp/443, tcp/22, udp/53, tcp/53 même si ils n'en ont pas besoin. On aurait pu être plus agressif et créer un groupe pour cURL et un groupe pour ssh/scp afin que cURL n'ai accès qu'aux ports tcp/443, udp/53 et tcp/53 et ssh/scp uniquement aux ports tcp/22, udp/53 et tcp/53. Néanmoins cela complexifie les règles iptables pour un gain en sécurité pas franchement évident.
• Certains d'entre vous remarquerons que les règles iptables sont incomplètes : il manque par exemple la gestion des messages d'erreur ICMP. Je sais que ce n'est pas l'idéal d'ignorer les paquets ICMP mais néanmoins je suis pas le seul puisqu'après vérification, la passerelle de mon réseau insecure bloque les paquets ICMP. Donc, sur le réseau, il ne reste plus que les paquets ICMP des machines faisant parties du réseau insecure, mais comme je ne communique jamais avec ces machines, j'ai peu de chance qu'elles m'envoient un message ICMP utile.

Table des matières

Dans un de mes billets sur proxychains, j'indiquais n'avoir jamais eu de soucis avec ce logiciel. Il a fallu que j'écrive ça pour en avoir. Je vais apporter une solution aux deux problèmes que j'ai rencontré. Je vous conseille de lire le billet précédent afin de comprendre ce dont je parle ici.

ERROR: ld.so: object 'libproxychains.so.3' from LD_PRELOAD cannot be preloaded: ignored.

Voici à quelle erreur je suis maintenant confronté. La solution exposée sur nombre de forums, a savoir créer un lien symbolique ne fonctionne pas chez moi.

En observant un peu, en lançant un programme proxychainé depuis un shell par exemple, on remarque que cette erreur apparaît lors de la résolution des noms de domaine. On se demande alors si l'erreur ne viendrait pas du script chargé de la résolution des noms de domaine, /usr/lib/proxychains3/proxyresolv. On l'ouvre et on remarque cette ligne :

export LD_PRELOAD=libproxychains.so.3

Si on en croit les forums qui conseillent de créer un lien symbolique, il faut créer le-dit lien car le chemin vers la libproxychains.so.3 serait codé en dur dans le code de proxychains et dans proxyresolv. C'est le déclic : et si nous mettons le chemin absolu vers la libproxychains.so.3 dans le script proxyresolv, cela corrige-t-il le problème ?

On cherche l'emplacement de la libproxychains.so.3 :

sudo find / -name "libproxychains.so.3"

On la trouve dans le répertoire /usr/lib, quelle surprise.

On modifie donc proxyresolv en remplaçant :

export LD_PRELOAD=libproxychains.so.3

par

export LD_PRELOAD=/usr/lib/libproxychains.so.3

Nous venons de résoudre le premier problème. Je ne sais pas expliquer pourquoi cela ne fonctionne plus subitement du jour au lendemain.

Les requêtes DNS ne sont plus proxychainées

En effet, je me suis aperçu que proxyresolv s'adresse bien au serveur définit dans sa variable "DNS_SERVER" mais sans passer par le tunnel SSH. Merci à mon netfilter bien configuré qui a évité les fuites vers le réseau local.

J'ai donc pensé à faire une redirection du port local tcp/53 vers le port tcp/53 de mon résolveur DNS. Cette redirection s'ajoute à ma redirection dynamique. Concrètement cela donne :

sudo ssh -ND6666 -L53:resolveurDNSDNS:53 login@server

Ensuite, il suffit de définir 127.0.0.1 comme "DNS_SERVER" dans le script proxyresolv et le problème sera résolu.

Pour ceux qui ne veulent pas lancer ssh avec les droits root, il y a un moyen de déporter les droits root sur un autre programme :

sudo apt-get install socat
ssh -ND6666 -L5300:resolveurDNS:53 login@server
sudo socat TCP4-LISTEN:53,reuseaddr,fork TCP4:127.0.0.1:5300

Explication : proxyresolv va envoyer sa requête sur le port tcp/53. socat va la relayer sur le port 5300. SSH va récupérer la requête, la faire transiter dans le tunnel et l'envoyer sur le port tcp/53 de la machine resolveurDNS.

Au lieu d'utiliser socat, on peut se la jouer netfilter ce qui évite de devoir créer des scripts pour lancer socat automatiquement et de donner des droits inutiles a ssh/socat :

ssh -ND6666 -L5300:serveurDNS:53 login@server
sudo iptables -t nat -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -p tcp --dport 53 -j REDIRECT --to-port 5300

Pour ceux qui se demande pourquoi définir 127.0.0.1 comme résolveur DNS dans proxyresolv et non pas dans /etc/resolv.conf : d'une part car cela empêcherait ssh de résoudre le nom de la machine avec laquelle il doit communiquer, dans le cas où votre serveur ssh a une ip dynamique. D'autre part, les autres applications fonctionnent très bien donc pourquoi les sanctionner ?

Pour ceux qui s'étonne de voir le protocole DNS agir sur le protocole TCP, sachez que cela avait été prévu par les RFC. Les administrateurs de réseaux qui bloquent le port tcp/53 ne sont donc pas consciencieux/informés. Néanmoins, une requête de résolution doit être effectuée sur TCP uniquement dans le cas où la réponse excède 512 octets (mais la taille autorisé via UDP a été augmentée dans le RFC 2671 afin de prendre en charge DNSSEC).

Nous faisons donc une entorse aux règles en faisant passer toutes nos requêtes, même celles qui n'excèdent pas la taille maximale, par le port tcp/53. Relativisons en disant que d'une part, comme SSH permet le port forwarding uniquement sur le protocole TCP, nous sommes obligé de passer via TCP à un moment donné. D'autre part, dés que l'on tente de masquer son trafic et/ou de contourner un firewall, on transgresse forcement les standards (on se souviens du TCP over TCP du billet précédent).

Pour ceux qui veulent étudier une solution alternative : Tunnelling UDP packets through SSH. Vous constaterez que cette méthode impose aussi un passage via TCP et qu'elle est plus complexe à mettre en place et à automatiser.

Table des matières

J'ai décidé de m'équiper afin de recevoir les chaînes de la TNT sur mon ordinateur portable (dans un premier temps), puis sur un ordinateur de bureau (un peu plus tard).

Expression des besoins

• Je veux recevoir la télévision sur un ordinateur portable et sur un ordinateur de bureau. Cela exclu donc les cartes pci/pcmcia. Il reste donc les tuners USB ou les tuners firewire à ma disposition. Ne disposant pas de prise firewire sur les deux ordinateurs, il ne me reste plus que l'USB.
• Je veux un périphérique compatible GNU/Linux.
• Je veux recevoir la TNT.
• Je veux deux tuners.
• Je veux aussi recevoir les chaines en haute définition. Cela n'est pas un problème en soit : même les cartes qui ne sont pas estampillées "TNT HD ready" sont compatibles. Je vous laisse comprendre pourquoi : Quid de la réception TNT HD sur PC ?

Trouver un tuner TNT USB

Pour cela, il faut :

1. Consulter les sites des distributeurs de ce genre de matériel : Hauppauge, Terratec, Leadtek, etc. et trouver un modèle qui répond aux critères ci-dessus.
2. Consulter la section consacrée aux tuners USB compatible DVB-T sur le wiki du projet LinuxTV et vérifier que le tuner choisit en 1 dispose d'un pilote sous GNU/Linux.
3. Vérifier sur des sites marchands que le produit est toujours commercialisé.

Personnellement, j'ai choisis la Terratec T5.

S'équiper du matériel supplémentaire

Généralement, les tuners USB sont fournis avec une/des antenne(s) d'intérieur. Comme au temps de l'analogique, ces antennes sont clairement insuffisantes, même si vous comptez vous en servir dans une ville où il y a un émetteur TNT. Après essais, je peux confirmer que la T5 n'échappe pas à cette règle. Il vaut mieux la brancher sur une antenne extérieure (de toit).

Comme la T5 est équipée de deux tuners, et à moins que vous n'ayez deux prises TV murales, il vous faut un té de répartition coaxial que vous brancherez à votre prise murale.

Attention : regardez bien le format de votre prise murale avant d'acheter votre té car celui-ci a changé il y a quelques années pour passer à un connecteur mâle. Dans mon cas, mes prises murales sont récentes et ont un connecteur mâle dans les deux endroits où je souhaite regarder la TV donc j'ai pris un té avec une entrée femelle et deux sorties mâles.

Ensuite, il vous faut deux câbles coaxial qui serviront à relier le té aux deux tuners de la T5. Du côté de la T5, il faut que le câble dispose d'un connecteur mâle. De l'autre côté, cela dépend de votre té. Le mien a deux sorties mâles, donc mes câbles doivent avoir un connecteur femelle de ce coté là. Après, il faut savoir que des adaptateurs sont généralement fournis avec le câble et donc qu'il y a moins de chance que vous ne puissiez pas brancher le câble. Concernant le diamètre des connecteurs : du côté de la T5, nous avons des connecteurs d'un diamètre de 9.5mm.

C'est tout ce dont vous aurez besoin.

S'équiper des logiciels nécessaires

Terratec ne fournit ni pilote ni logiciel pour GNU/Linux pour sa T5. Nous n'avons pas besoin de pilote sous GNU/Linux car il est déjà intégré au noyau depuis la version 2.6.29 (voir le wiki LinuxTV), mais, en revanche, il nous faut un logiciel. J'avoue que je n'ai pas été très original sur ce coup : j'utilise KDE et j'ai souvent entendu parler de Kaffeine en bien donc j'ai décidé d'essayer ce logiciel. L'essai a été convaincant : il fait ce que je veux. Je vous le recommande.

Si il vous intéresse :

sudo apt-get install kaffeine

Ouvrez Kaffeine, ouvrez le module dédié à la télévision. Un message de notification vous informera si des paquets supplémentaires sont à installer. Si c'est le cas, installez-les puis fermez Kaffeine.

C'est finit pour la partie logicielle.

Installation

Je vous laisse réaliser les branchements physiques car je ne pense pas que vous ayez besoin d'aide.

Au préalable

Connectez ensuite la T5 à votre ordinateur. Ouvrez Kaffeine et son module télévision numérique. Cliquez sur l'icône "Configurer la télévision". Vous remarquez qu'il y a deux onglets : "Périphérique 1" et "Périphérique 2" qui correspondent aux deux tuners de la clé. Je vous conseille de leur donner un nom différent comme par exemple "Tuner 1" et "Tuner 2" afin de les différencier par la suite. Valider les modifications.

Recherche automatique des chaînes

Cliquez sur le bouton "Canaux" qui se situe à coté de celui de la configuration. Choisissez le premier tuner et lancez la recherche automatique des chaînes. A la fin de celui-ci, sélectionnez les chaines que vous voulez dans la liste de droite et cliquez sur le bouton "Ajouter les sélectionnés". Cliquez sur le bouton "OK" sinon les chaines ne seront pas mémorisées.

Pour profiter du double tuner

Dans la liste des chaines, et pour chaque chaine, changez son nom pour indiquer le tuner de provenance. Par exemple : "TF1" devient "TF1 T1" si vous avez obtenu la liste des chaînes via le premier tuner. Vous savez ainsi que cette chaîne est TF1 et qu'elle est reçue via le tuner 1 de la carte. Ce renommage des chaines peut être effectué plus facilement depuis la fenêtre "Canaux" (celle où vous lancez la recherche des chaînes).

Refaites une recherche des chaines mais en utilisant cette fois-ci le deuxième tuner. Renommez les chaînes de la même façon pour indiquer que celle-ci viennent du deuxième tuner. Vous obtenez une liste dans laquelle chaque chaîne apparaît en double : une via le tuner 1, une via le tuner 2.

Cette méthode n'est peut-être pas la meilleure mais elle me convient parfaitement. Libre à vous d'en trouver une meilleure.

Classer les chaînes

Retournez dans la fenêtre "Canaux". Dans la liste de gauche, vous pouvez glisser-déplacer une chaine. Un message vous informera qu'un tri sera effectué : approuvez. Continuez votre classement en faisant glisser-déplacer les chaînes. N'oubliez pas de cliquer sur le bouton "OK" sinon le classement est perdu.

Enregistrement et double tuner

Pour réaliser un enregistrement immédiat et continuer à regarder la même chaîne : cliquez simplement sur le bouton représentant une disquette.

Pour réaliser un enregistrement immédiat puis regarder une autre chaîne : cliquez sur l'icône représentant une disquette puis changez de chaîne en prenant le tuner inutilisé (d'où l'intérêt d'avoir nommé les chaînes en fonction du tuner qui la reçoit).

Pour réaliser un enregistrement immédiat de deux chaînes : enregistrez la première chaîne en cliquant sur le bouton en forme de disquette. Cliquez ensuite sur le bouton "Programmation d'un enregistrement" (le calendrier) et ajoutez un nouvel enregistrement en choisissant une chaîne du tuner inutilisé. Vous pouvez bien entendu regarder l'une ou l'autre des chaîne que vous enregistrez.

Pour programmer un ou plusieurs enregistrements : vous savez faire : utilisez le bouton "Programmation d'un enregistrement".

Cas de la haute définition

Sur les chaînes du multiplex R5 (TF1 HD, France 2 HD, M6 HD), le codage du son est réalisé grâce au codec E-AC3 et son extension spectrale. Cela pose un soucis dans un certain nombre de logiciels qui ne proposent donc pas le son sur ces chaînes.

Arte HD, diffusé sur le R4, n'a pas ses pistes audio encodées en E-AC3 et fonctionne sans aucun problème.

Personnellement, j'utilise la T5 principalement dans une région dans laquelle le R5 n'est pas encore en service et avec un ordinateur portable dont la puissance est insuffisante pour décoder un flux haute définition donc je n'ai pas encore cherché comment faire.

Malgré tout je vous donne des tuyaux : MythTV semble être capable de décoder l'E-AC3. FFmpeg aussi. La propagation aux logiciels se basant sur ffmpeg ne devrait plus être longue.

Forcer le 16/9 sur les chaînes qui n'y sont pas encore passé

Il suffit de cliquer droit sur la vidéo, d'aller dans "Vidéo" puis "Rapport hauteur/largeur" puis de mettre "16:9".

Et si je voyage dans plusieurs régions ?

Hé oui, les fréquences ne sont pas les mêmes. Il vous suffit d'appliquer la méthode que nous avons vu pour le double tuner : faire une recherche et nommer les chaînes en fonction de la région.

EDIT 14/02/2011 à 22h30 : La solution ci-dessus n'est pas bonne car Kaffeine supprime automatiquement les chaines identiques d'un même tuner. Je ne sais toujours pas sur quoi il se base pour faire la comparaison vu que les fréquences ne sont pas identiques entre les régions. Néanmoins, si la méthode ci-dessus fonctionnait, elle supposerait d'avoir une liste des chaînes contenant le nombre de chaînes*le nombre de tuners*le nombre de régions. Autrement dit : cela ne serait pas pratique pour zapper.

Le mieux est de procéder ainsi :

1. Chercher les chaines de la première région.
2. Sauvegarder le fichier /home/votrelogin/.kde/share/apps/kaffeine/sqlite.db
3. Chercher les chaines de la deuxième région.
4. Sauvegarder le fichier /home/votrelogin/.kde/share/apps/kaffeine/sqlite.db avec un nom différent du premier, évidemment.

Ensuite, quand vous changez de région, vous n'avez plus qu'à copier le bon fichier et à lancer Kaffeine.

Et la télécommande de la T5, elle fonctionne sous GNU/Linux ?

Aucune idée, cela ne m'intéresse pas.

Fin

Mon seul regret à propos de la T5, c'est son packaging. Une boite en ferraille entourée d'un emballage en plastique rigide, cela a un coût qui hausse inutilement le prix de vente. De plus, ce n'est pas très "planète attitude" ;).

Mon seul regret concernant Kaffeine est le fait qu'il se définit comme application par défaut pour tous les fichiers multimédia et ce, sans me demander mon accord.

Pour conclure : si vous êtes le possesseur d'une Terratec 2400i DT, sachez qu'elle fonctionne sous GNU/Linux depuis environ 1 an : TerraTec Cinergy 2400i DVB-T sur LinuxTVWiki. Je vous ferai un petit billet lorsque j'aurais sortit l'ordinateur qui la contient des cartons.