Whatever apero 23-03-2012 - compte rendu

Compte rendu du Whatever_apero_23/24_mars_2012

Photos de l'évènement

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

Atelier Quadropter

Tableau-Shémas: http://wiki.breizh-entropy.org/wiki/File:Whatever-apero-P1110561-resize.jpg

specs: https://megauplol.fr/index.php?title=Copter

Suite prochain Whatever.

Atelier VPN

Un peu de docs ici: http://wiki.breizh-entropy.org/wiki/Documentation/OpenVPN

Atelier ChaosPrinter

état des lieux

Une imprimante (P) est connecté à une machine A (ip : 192.168.0.23) en USB. un serveur CUPS est installé sur cette machine et possède une configuration pour l'imprimante P. Via l'interface web d'administration, nous avons partagé l'imprimante afin que n'importe qu'elle machine du réseau local puisse imprimer une page avec la commande suivante :

 lp -h 192.168.0.23 -d elabo file.pdf

• Objectif : Mettre l'imprimante à disposition des nazis de l'Internet :)
• Problème : l'imprimante est connecté à un ordinateur Naté derrière une freebox
• Problème 2 : nous n'avons pas la main sur le routeur freebox

First Try (spoiler : fail)

Lorsqu'on effectue une impression avec la commande lp, une connexion est d'abord faite en TCP et les données sont ensuite envoyées en UDP. Pour rendre disponible l'imprimante sur internet sans modifier la freebox, on va monter un tunnel OpenVPN entre la machine connecté à l'imprimante (A) et la machine tierce sur l'internet (B) puis forwarder les ports 631 (TCP & UDP) de B -> A. On va utiliser SSH pour le port forwarding TCP et socat pour le port fowarding UDP. On pourrait également utiliser socat pour le TCP mais bon on fait du quick'n dirty :

sur la machine tierce B :

 root@B# /sbin/iptables -A INPUT -i eth0 --dport 631 -p tcp -j ACCEPT
 root@B# ssh -L 631:localhost:631 user@A

puis pour l'UDP toujours sur B :

 root@B# /sbin/iptables -A INPUT -i eth0 --dport 631 -p udp -j ACCEPT
 root@B# socat UDP4-LISTEN:631,reuseaddr,fork UDP4-SENDTO:10.0.0.2:631

on essaye d'imprimer quelque chose depuis une machine random R sur l'internet :

 R$ lp -h B -d elabo file.pdf
 lp: bad request

hmmm, on regarde ce qui se passe dans le errorlog de notre serveur cups sur A :

 root@A$ tail -f /var/log/cups/error_log
 E [24/Mar/2012:13:27:04 +0100] Request from "localhost" using invalid Host: field "B"

Apparemment une requête d'impression contient le nom de l'hote auquel on effectue cette requête. On ne fait que relayer la requête sans modifier les données, du coup A reçoit une requête d'impression qui était destiné à B. hmm échec on va essayer autre chose

Second Try Success

On arrête le quick'n dirty, manifestement ça ne fonctionne pas :) on laisse le VPN entre A et B mais on va installer un serveur cups sur B qui fera proxy. En principe on va configurer une nouvelle imprimante sur B qui sera une imprimante ipp, dans l'interface web d'administration on ajoute une imprimante à l'adresse suivante :

 ipp://10.0.0.2/printers/elabo

on spécifie le modèle (ici une Epson Stylux DX5050 mais il faut utiliser les drivers de Epson Stylus DX4850), le serveur cups se relance automatiquement et...

 R$ lp -h B -d elabo file.pdf
 l’identifiant de la requête est elabo-31 (1 fichier(s))

on limite un peu les quotas d'impression à 3 pages par requête et un maximum de 4096ko de fichiers à imprimer :

 root@B$ lpadmin -p elabo -o job-k-limit=4096
 root@B$ lpadmin -p elabo -o job-page-limit=3

ça fonctionne !! on tweet l'accès à l'imprimante et.. voici le résultat :

[1] [2] [3]

merci à tous :)

Atelier Streaming Vidéo

Contexte et objectif

• Objectif : streamer vers l'Internet un flux vidéo depuis le réseau local ;
• Contexte : un flux vidéo reçu depuis un Quadcopter par une machine connectée à Internet, en Syrie, doit être émis vers Internet pour être ensuite vu partout dans le monde ;
• Hypothèses
  • débit montant fortement limité (simulation d'un réseau de mauvaise qualité, comme ce qu'on peut trouver en Syrie), à 300kbits/s ;
  • flux vidéo lisible par pilote Video 4 Linux 2 sur la machine connectée à Internet ;
  • flux réseaux espionnés par le gouvernement impliquant qu'un flux vidéo passant en clair vers l'extérieur met en danger la personne émetrice.

Résumé

VLC est utilisé pour lire le flux vidéo depuis la webcam et l'envoyer vers un serveur IceCast, qui se charge de lire le flux et d'accueillir des clients voulant consulter le flux.

VLC transcode le flux avant de l'envoyer, et les codecs et la qualité de l'image sont réglés de façon à ne pas dépasser une certaine consommation de bande passante. Le serveur IceCast, lui, par contre, est installé sur une machine possédant une bonne bande passante (connexion 100Mbits/seconde symétrique).

Le flux vidéo est envoyé au serveur à travers un VPN pour éviter l'espionnage indésirable (et dangereux) du flux vidéo émis par l'utilisateur. Les détails du VPN ne sont pas présentés ici. La présence du VPN rajoute un overhead au flux émis, augmentant en conséquence l'utilisation de la bande passante.

Nous avons une webcam USB connectée à l'ordinateur, reconnue par le pilote Video 4 Linux 2. La webcam sans fil est l'étape suivante.

Configuration

Logiciels pour streaming

IceCast

IceCast est un serveur libre et gratuit conçu pour le streaming audio et vidéo. Installé sur un serveur physique, des clients sources peuvent s'y connecter afin d'y envoyer des flux multimédia (tous les formats ne sont pas supportés). Le serveur enregistre ces flux et peut accueillir des auditeurs qui peuvent les consulter. IceCast utilise le protocole HTTP pour la communication avec les sources et les auditeurs, ce qui permet notamment d'ouvrir les adresses des flux dans un navigateur Web standard.

Par exemple, si le serveur IceCast écoute sur le port 4242 sur la machine icecast.telecomix.org (IP : 91.191.136.153), un navigateur Web accèdera à une page de présentation du serveur à l'adresse http://icecast.telecomix.org:4242/.

Un client source (émetteur de flux) spécifie un point de montage pour le flux émis, qui doit avoir l'extension correspondant au format du flux. Ce point de montage, concaténé à l'URL du serveur IceCast, spécifie l'adresse permettant aux auditeurs de consulter le flux. Si une source spécifie mystream.ogg, le flux sera accessible à l'adresse http://icecast.telecomix.org:4242/mystream.ogg.

Notre serveur IceCast sera accessible à la fois publiquement depuis Internet et depuis l'intérieur du VPN auquel appartient la machine. C'est par ce second biais que devra passer toute personne dont l'émission ou la réception des flux vidéo peut être dangereuse. Supposons que l'adresse IP du serveur à l'intérieur du VPN est 10.0.13.37.

Alors que le client utilisant VLC pour émettre le flux a une bande passante limitée, il est important que le serveur IceCast ait une bande passante correcte montante comme descendante pour permettre de recevoir plusieurs flux et d'accueillir plusieurs auditeurs simultanément.

Dernier points de détails : IceCast requiert une authentification pour les sources et pour un accès administrateur via l'interface Web. Les identifiants associés sont respectivement source (il n'est pas possible de changer ceci dans la version 2.3.2) et admin. Faisons l'hypothèse que les mots de passe associés sont respectivement sourcepass et adminpass.

Voici notre fichier de configuration IceCast reprenant ces points. Il est vivement conseillé de lire la documentation du serveur, notamment concernant sa sécurisation, des options plus avancées et la compréhension de ce qui est présenté ici.

<icecast>
    <limits>
        <clients>100</clients>
        <sources>5</sources>
        <threadpool>5</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>130000</burst-size>
    </limits>

    <authentication>
        <source-password>sourcepass</source-password>

        <relay-password>relaypass</relay-password>

        <admin-user>admin</admin-user>
        <admin-password>adminpass</admin-password>
    </authentication>
 
    <hostname>icecast.telecomix.org</hostname>

    <listen-socket>
        <port>4242</port>
        <bind-address>91.191.136.153</bind-address>
    </listen-socket>
    
    <listen-socket>
        <port>4242</port>
	<bind-address>10.0.13.37</bind-address>
    </listen-socket>
    
    <fileserve>1</fileserve>

    <paths>
        <basedir>/usr/share/icecast2</basedir>

        <logdir>/var/log/icecast2</logdir>
        <webroot>/usr/share/icecast2/web</webroot>
        <adminroot>/usr/share/icecast2/admin</adminroot>

        <alias source="/" dest="/status.xsl"/>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>

      	<loglevel>3</loglevel> 
     	<logsize>10000</logsize> 
    </logging>

    <security>
        <chroot>0</chroot>
    </security>
</icecast>

VLC

VLC est un lecteur multimédia libre et gratuit qui permet la lecture de fichiers vidéos, DVD, de flux réseaux ainsi que des flux d'un périphérique d'acquisition comme une webcam. Outre l'affichage des fichiers lus, VLC offre la possibilité de convertir les flux dans d'autres formats et, une fois convertis, de les écrire soit dans des fichiers, soit de les mettre à disposition par accès réseau (il existe plusieurs techniques).

Ici, nous lisons le flux vidéo depuis un périphérique Video 4 Linux 2, par exemple /dev/video0. Le flux est transcodé puis envoyé vers le serveur IceCast. Agir sur la bande passante utilisée se fait par le réglage de différents paramètres :

• les choix de codecs audio et vidéo (paramètres acodec et vcodec), toutefois limités par les formats supportés par IceCast et la capacité de VLC a utiliser certains codecs avec certains conteneurs multimédia ;
• le nombre d'images par secondes (paramètre fps) ;
• le bitrate video (paramètre vb) ;
• la taille de l'image (un des paramètres suivant : scale, width, height) ;
• le bitrate audio (paramètre ab) ;
• le nombre de canaux audio (paramètre channels) ;
• le taux d'échantillonage audio (paramètre samplerate).

Ces paramètres doivent être réglés en faisant des tests, par exemple en utilisant iftop afin de trouver le bon compromis entre qualité d'image et bande passante utilisée. Ici, nous avons choisi des valeurs correspondant à nos contraintes de bande passante.

La ligne de commande suivante utilise cvlc, à savoir VLC sans l'interface graphique, en reprenant les paramètres susmentionnés ainsi que les informations nécessaires à VLC pour qu'il se connecte au serveur IceCast. Notre client sur lequel cvlc est lancé est dans le même VPN que le serveur. Nous encodons la vidéo avec le codec Théora pour la vidéo et Vorbis pour l'audio, ce qui nous permet d'utiliser le conteneur Ogg. Il existe probablement d'autres combinaisons mais les limitations d'IceCast en terme de formats supportés semble rendre cela un peu plus difficile.

cvlc v4l2:///dev/video0 --sout '#transcode{vcodec=theo,vb=120,fps=5,width=320,acodec=vorb,ab=96,channels=1,samplerate=8000}:std{access=shout,mux=ogg,dst=source:sourcepass@10.0.13.37:4242/mystream.ogg}'

À noter qu'il est possible d'utiliser acodec=none si l'émission de flux audio n'est pas nécessaire ou si cela permet d'économiser de la bande passante.

Pour se simplifier la vie, il est possible de retrouver les lignes de commande utilisées en utilisant VLC en mode graphique : il affiche la ligne de commande avant lancement du streaming. Il manque à notre commande l'affichage local de la vidéo émise vers le serveur.

Mesure et limitation de bande passante

iftop

iftop est un petit utilitaire, souvent présent dans un paquetage à part dans les distributions Linux, permettant d'afficher en temps réel la bande passante consommé en trafic montant et descendant.

Dans notre cas, il nous permet d'estimer la bande passante montante utilisée par le streaming. C'est notre interface wifi wlan0 qui est connectée à Internet. Nous exécutons donc (il faut être super-utilisateur) :

iftop -n -i wlan0

La première option spécifie à iftop de ne pas faire de requêtes DNS pour convertir les adresses IP en nom d'hôte.

À noter qu'en mesurant la bande passante utilisée sur l'interface physique, cela permet de prendre en compte l'overhead rajouté par la présence du VPN.

tc

tc nous permet de limiter de façon « dure » la bande passante de notre interface wifi wlan0, simulant ainsi approximativement une condition de débit limité pouvant être trouvé en Syrie. La commande suivante nous permet de limiter le débit montant à 300kbits/seconde (à exécuter comme super-utilisateur) :

tc qdisc add dev wlan0 root tbf rate 300kbit burst 30k latency 100ms peakrate 400kbit minburst 1540

La manipulation de tc est complexe, il faut passer du temps sur la documentation pour la comprendre correctement.

Résultats

Nous sommes parvenus à émettre le flux vidéo à travers le VPN, en ne dépassant pas une consommation de débit montant de 200kbits/seconde. À noter que cela varie légèrement en fonction de la webcam utilisée. Des Américains, Français et Syriens ont pu nous voir en direct depuis leurs pays respectifs. Nous avons même reçu sur la Chaos Printer une capture d'écran du live stream vidéo !

Un test préliminaire a été effectué en émettant le flux depuis la Syrie : ça fonctionne ! Quelques images live d'un correspondant à Damas ont pu être captées.

Prochaines étapes : caméra sans fil, puis accrochée à un appareil volant.

Soudure TV B-Gone

Des gens contents, trop de demandes de TV-B-Gone pour satisfaire tout le monde. Les teles vont morfler.

pas beaucoup plus d'infos sur : http://www.hacknowledge.org/drupal/?q=node/44

Atelier Jukebox partagé (MPD + NFS)

Objectifs :

• mettre en place un jukebox que tout le monde puisse contrôler via le réseau
• faire en sorte que tout le monde puisse envoyer sa musique sur le jukebox

Problèmes :

• si 10 personnes veulent changer la musique et qu'elles ne sont pas d'accord, c'est le bazar (mais c'est marrant ;) )
• si on laisse un accès en écriture sur l'endroit où est stockée la musique, n'importe qui peut potentiellement foutre le bazar à coup de rm -rf
• homogénéité de la bibliothèque musicale résultante (au niveau tagging, format, …)

Pour le partage de fichier, le plus simple est de monter un NFS…

Se prémunir des pertes de données

Par principe, le NFS est ouvert : n'importe qui peut écrire dedans pour rajouter sa musique. Ça pose le problème de la perte potentielle de données.

Deux solutions :

• jouer avec les permissions Unix (lecture partout pour l'utilisateur NFS, mais écriture seulement sur le dossier racine, pour pouvoir rajouter des dossiers). C'est pas super pratique, et ça marche juste pas si on veut écrire quelque chose en dehors de la racine. En plus, ce que les gens écriront le seront sous l'utilisateur NFS, donc accessible en écriture par tout le monde…
• utiliser des snapshots LVM

Snapshots LVM

C'est joli, c'est facile à faire : on met la musique sur une partition LVM, et on fait des snapshots de temps en temps pour pouvoir revenir en arrière si quelqu'un fait une connerie.

Atelier Réparation MacBook

Objectif : réparer un MacBook pro tout pété (tasse de café renversée dessus).

Matériel nécessaire

• un MacBook pro présentant les caractéristiques suivantes :
  • clavier qui ne fonctionne plus
  • bouton marche/arrêt branché au clavier (situation par défaut), qui ne fonctionne donc plus non plus
  • chipset SATA qui marche une fois sur deux (si possible, garder la surprise pour la fin)
• un fer à souder
• un bout de fil (ou de nappe)
• un adaptateur USB ↔ SATA
• un marteau pour que ksamak puisse donner un coup de main ;)
• un clavier USB
• de la documentation sur l'EFI (c'est le plus difficile à trouver)

Si on n'a pas de MacBook répondant aux critères ci-dessus, il est possible d'emprunter un MacBook en bon état à un de ses amis (annoncer que c'est pour « faire une expérience amusante »). Si on est motivé, on peut même utiliser n'importe quel matériel Apple (iPod, etc) pour s'exercer.

Réparation du bouton marche/arrêt

Un MacBook est extrêmement bien conçu : le bouton marche/arrêt est relié au clavier par une nappe, puis une nappe unique connecte le clavier à la carte mère. C'est super bien quand le clavier ne marche plus.

Il faut donc d'abord déterminer quel pin (sur le connecteur de la nappe du clavier) contrôle la fonction marche/arrêt :

• brancher un fil à la masse avec une pince croco (par exemple sur une des vis qui tient la carte mère)
• brancher ce fil sur un tournevis et essayer de faire contact sur chaque pin, un à un, jusqu'à ce que l'ordi démarre

Il faut ensuite souder un fil sur ce pin. Étant donné que le clavier est hors-service, on peut raisonnablement considérer que le connecteur ne servira plus en usage normal :

• tordre/retirer quelques pins adjacentes (attention à ne pas enlever le pin qu'on veut souder...)
• souder un fil avec soin
• mettre de la colle pour tenir tout ça mécaniquement

Il reste à souder l'autre bout du fil au bouton marche/arrêt. Pour accéder à celui-ci, il faut au moins enlever le lecteur CD.

Problème : la nappe du bouton est irrécupérable (si on essaie de la faire chauffer, le plastique fond sans révéler la piste métallique...)

Solution : trouver un autre bouton (par exemple, bouton de lecteur disquette) et le mettre à la place, en calant le tout à coup de pistolet à colle.

Ne pas oublier de relier une des pattes du bouton à la masse...

Installation d'un vrai système

Curieusement, il se trouve que OS X ne boote pas (équivalent d'un kernel panic au boot).

C'est l'occasion de mettre un véritable OS, GNU/Linux pour faire simple. Pourquoi pas Archlinux ? :)

Pour faire propre, on a besoin de Archboot [4], qui fournit les outils nécessaires à l'utilisation d'une table de partition GPT ainsi que de quoi faire booter depuis EFI (grub2-efi).

Malheureusement, le MacBook ne semble pas vouloir booter sur USB de base, donc il faut graver un CD (ça marcherait peut-être en faisant une clé usb avec une table de partition GPT, m'enfin bon…)

Heureusement, la combinaison de touche pour booter depuis un CD (maintenir « c » appuyé avant que OS X ne boote) fonctionne depuis un clavier USB \o/

Attention en partitionnant : il faut laisser la partition FAT32 de 200 Mio au début du disque (c'est ce qui contient le boot manager EFI, on pourra mettre Grub2 ou un autre boot manager comme rEFIt ici)

Y U NO WANT MY DATAZ?

Bon bah… ça marche pas… Créer les systèmes de fichier fonctionne bien, mais dès qu'on veut écrire sur le disque, le lien SATA reset, et on a des erreurs d'I/O en pagaille.

Ça ressemble fort à un disque dur foireux… Après test du disque dur sur un autre système avec un adaptateur USB ↔ SATA, il se trouve qu'il marche parfaitement bien. On a donc le choix :

• soit le contrôleur SATA ne tourne plus vraiment rond
• soit le pilote du noyau Linux n'aime pas trop le contrôleur (c'est un chipset SATA Nvidia en même temps…)

Vu qu'OS X ne bootait pas, c'est plutôt le contrôleur. Bref, on arrive à installer en branchant le disque en USB.

Bootloader

La partie chiante… l'installeur d'Archboot n'arrive pas à installer grub2-efi (btw, c'est un EFI x86_64 sur ce Macbook, donc utiliser grub2-efi-x86_64)

Il faut le faire à la main : si l'installeur a déjà copié ce qu'il faut dans /tmp/install/boot/efi/EFI (sachant que la partition FAT32 de 200 Mio, probablement /dev/sda1, est montée dans /tmp/install/boot/efi : on peut aussi faire ça directement dans la partoche), il faut *juste* dire au firmwire EFI qu'il a un nouveau bootloader, avec efibootmgr. Évidemment, ça marche pas…

Solution quick & dirty : le firmware est censé regarder dans EFI/boot et essayer de lancer EFI/boot/bootx64.efi. On copie donc le .efi de grub2 là, et ça marche™.

Attention : ne pas oublier de configurer grub2, sinon il n'arrivera pas à booter Archlinux. Le plus simple est de chrooter [5] et de faire un :

 grub-mkconfig -o /boot/grub/grub.cfg