Emile "iMil" Heitor 's home

Quatre ans que j’avais pas reuni liveice, icecast et… ÇA



Bah putain que ça fait du bien…
La qualité est pas encore top top étant donné que dans l’immediat j’ai un… hm… accès au net… “bridé” :



Ma freebox est arrivée, j’attend plus que la ligne…

Alors que j’étais plein d’entrain et que je m’apprétais à utiliser les snapshots LVM avec mon Xen, je lance, confiant, un

lvcreate -s -L2048M -n lvconvivial /dev/vgconvivial/base

et je me mange un

LV vgconvivial/lvconvivial in use: not deactivating
Couldn't deactivate new snapshot.

Je cherche donc un peu, et je tombe sur ça http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343671#msg20
Je m’empresse donc d’éditer le-dit udev-rules, comme mentionné dans le ticket, pis ça marche.

Tu notes ça dans un coin ?

Au Centre de l’Univers, on capte evidemment parfaitement bien les chaines TNT. Et comme je me suis payé, y’a qques mois, une clé USB tuner TNT, jme suis dit qu’avant de recevoir ma freebox, ce serait une solution convenable pour streamer la télé dans l’appart. La carte en question est supportée par les drivers DVB linuxtv. J’ai du utiliser les sources recupérées via mercurial, car les drivers fournis dans Ubuntu Edgy ne la supportent pas. Le tuto d’install sur le wiki linuxtv est parfait pour mener à bien l’opération.
J’ai compilé ces drivers avec comme base le kernel xen ubuntu. À noter qu’un vilain hack à base de #if 0 est nécéssaire pour la compilation d’un des modules, il devra remplacer un #ifdef qui check la version courante du kernel. Rien de bien terrible.
Le but du jeu étant de streamer, je me suis bien evidemment orienté vers vlc.L’ ‘idée, c’est par exemple d’avoir un lappy dans la cuisine, connecté via wifi, qui se connectera à un serveur http vlc.
Comme la machine hostant le serveur en question possède déjà une configuration en bridge, j’ai ajouté l’interface wifi, ra0 en l’occurrence, dans le bridge préalablement configuré pour Xen :

# brctl addif xen0 ra0

Une simple configuration de l’interface à l’aide de iwconfig permettra à mon client vlc de faire partie du LAN du serveur :

# ifconfig ra0 up
# iwconfig ra0 essid "gnagna" channel 10 mode Ad-Hoc rate 54M 

Du coté client, j’ai simplement configuré l’interface wireless :

# ifconfig ath0 up
# iwconfig ath0 essid "gnagna" channel 10 mode Ad-Hoc rate 54M
# ifconfig ath0 192.168.10.3 netmask 255.255.255.0

À partir de maintenant, les deux boxes devraient se voir.
Tout est prêt, me dis-je, et appliquant simplement les consignes du howto du site videolan, je devrais bientôt pouvoir comater devant Kamelott en sirotant mon apero. Que nenni ! car effectivement, si ma conf fonctionne (serveur ok, client ok), le flux transporté est bien trop important (TNT !) et ma reception lagge tellement qu’il est totalement impossible de regarder un programme convenablement.
Qu’à cela ne tienne, j’envisage donc d’utiliser les fonctions de transcoding de vlc. Et ça marche. Voici la ligne magique :

vlc --programs 1025 -vvv --color --ttl 12 dvb:// --dvb-frequency=498000000 --dvb-adapter=0 --dvb-bandwidth=8 --sout '#transcode{deinterlace,vcodec=mp4v,vb=1200,scale=0.8}:std{access=http,mux=ts,server=192.168.10.1}'

Fonction de la qualité de votre lien, vous pourrez jouer avec les valeurs vb et scale
Evidemment, sur le client, je lance :

vlc http://192.168.10.2:8080

Et “mouahhaha comment l’est trop con Perceval mouahahaha :”)”

Je pouvais evidemment pas résister à transformer tatooine, ma ws ubuntu, en convi-Xen0. Muni d’une carte graphique à base de chipset nvidia, j’avais lu de-ci de-la qu’il existait des patches pour faire fonctionner les drivers du malin sur un domaine 0.Voici donc les quelques liens sur lesquels je me suis basé ainsi que quelques confs

. Procédure de chez OpenSUSE pour patcher les-dits drivers

Perso, j’ai pas litteralement suivi la procédure, après patchage, j’ai simplement executé nvidia-installer, présent à la racine de l’archive NVIDIA-Linux-x86-1.0-9631-pkg1.

. Une doc fort bien concue sur la xenification d’une debian, l’adaptation à ubuntu est triviale

Mon /etc/network/interfaces :

auto xenbr0
iface xenbr0 inet static
  pre-up brctl addbr xenbr0
  post-up brctl addif xenbr0 eth0
  post-up ifconfig xenbr0 up
  post-up ifconfig eth0 up
  post-down brctl delbr xenbr0
  address 192.168.0.2
  netmask 255.255.255.0
  gateway 192.168.0.1
  bridge-ports eth0
  bridge_maxwait 0

Mon NetBSD-domU, basique :

kernel = "/home/xen/netbsd/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 256
name = "netbsd"
disk = [ 'file:/home/xen/netbsd/netbsd.qcow,ioemu:hda1,w',
	'file:/home/xen/netbsd/i386cd-3.1.iso,ioemu:hdc:cdrom,r' ]
vif = [ 'bridge=xenbr0' ]

Et le resultat :)

Addon

J’ai noté d’horribles ralentissements lors de l’utilisation intensive du disque virtuel, et après quelques recherches, je suis tombé sur ceci dans la FAQ de Xen :

2.3. Error about root device still mounted when it’s not mounted, zombie domU that can’t be killed, domU hangs under heavy I/O (e.g disk) access

You may try to pass nousb to dom0 kernel command line, or pass ignorebiostables, or try to disable software IRQ affinity for 1850/2850 systems.

Et effectivement, après avoir ajouté l’option ignorebiostables dans mon menu.lst, tout semble réagir au poil :

title           XEN/2.6.17
root            (hd0,0)
kernel          /boot/xen-3.0-i386.gz ignorebiostables
module          /boot/xen0-linux-2.6.17-6-generic-xen0 root=UUID=387cb651-f182-4
b1f-a5b9-a2e5ef119d5a ro
module          /boot/xen0-linux-2.6.17-6-generic-xen0.initrd.img

Si ton Xen t’insulte tout plein avec des phrases du genre :

Error: Device (vbd) could not be connected. Backend device not found.

Pas de panique ami lutin, le pauvre Xen n’a juste tout plus de devices loopback à disposition. Rend leur heureux, et agrémente ton /etc/modprobe.conf de cette petite ligne magique :

options loop max_loop=64

Et tu pourras xm create tout plein de domaines supplémentaires.