En attendant, je faisais face à un “problème” de vibe lors du reveil. En effet, depuis un nombre d’années qu’il serait indécent de préciser, la radio qui me fait émerger du sommeil, c’est, comme vous pouviez vous en douter, RadioFG. Seulement voila, si à partir de 23h, départ de la programmation clubbing, le son est souvent très bon et les invités de qualité (Roger Sanchez, Pete Tong, Laidback Luke, Guetta…), il n’en va pas de même pour la programmation du matin. Le matin, sur FG, on met de la soupe. De lamentables productions “grand public” à la “wash my world” ou autre saloperies qui font gagner un blé collossal aux grands DJs de l’époque, mais leur a retiré toute crédibilité dans les clubs. Ajoutons à cela le “flash info” toutes les demi heures, ou encore les deux nouveaux animateurs-drôles chargés de disséminer quelques blagues désopilantes entre chaque titre, c’en était trop, je devais retrouver le son pur et récent de la radio officielle de l’île: Flaix Eivissa (oui, Ibiza est catalane, et en catalan on dit “Eivissa”).

Ni une ni deux, je m’en vais rechercher dans la pile de vieux portables un valeureux Celeron 600 amputé de son écran fissuré qui se logerait parfaitement derrière un meuble (Mme iMil deteste les cables apparents, je comprend pas, c’est beau un cable). Le portable en question n’a plus de disque dur, mais sait booter en PXE sur sa carte réseau intégrée, et comme tout portable qui se respecte, dispose d’une sortie casque, que je pourrai, à l’aide d’un cable (toujours derrière le meuble sus-cité) jack-RCA, brancher à l’entrée “Auxiliaire” de la mini chaine qui me sert de radio-reveil.

Étape 1: faire booter le portable en PXE.

Le serveur DHCP de la maison tourne sur une machine NetBSD. Il s’agit de l’excellent ISC-DHCP. Voici la configuration nécessaire :

host snootles {
        hardware ethernet 00:a0:b9:c5:d7:ec;
        fixed-address 192.168.1.8;
        next-server 192.168.1.1;
        filename "/pxelinux.0";
}

Le next-server est une machine Debian GNU/Linux sur laquelle sont installés atftpd et nfs-kernel-server. Le root de tftpd pointe par defaut sur /srv/tftp, nous copions donc le fichier /usr/lib/syslinux/pxelinux.0 issu du package syslinux-common à cet endroit.
Nous devons ensuite créer un fichier /srv/tftp/pxelinux.cfg/default (ou pour les plus pointilleux 01-00-a0-b9-c5-d7-ec) :

DEFAULT linux
PROMPT 0
MENU TITLE PXE Boot Menu
TIMEOUT 2

LABEL linux
KERNEL /snootles/vmlinuz
APPEND root=/dev/nfs initrd=/snootles/initrd.img nfsroot=192.168.1.1:/srv/tftp/snootles ip=dhcp rw --

Une configuration très basique, je vous l’accorde.

Préparons maintenant le fichier d’export NFS afin que l’invité puisse monter son filesystem :

/srv/tftp 192.168.1.0/255.255.255.0(insecure,sec=sys,rw,async,no_subtree_check,no_root_squash)

Et on redémarre les services associés :

# /etc/init.d/openbsd-inetd restart
# /etc/init.d/nfs-kernel-server restart

Reste à peupler ces conteneurs, opération rendue d’une simplicité enfantine grace à l’outil debootstrap :

# debootstrap lenny /srv/tftp/snootles

Afin de préparer l’environnement, nous pouvons chrooter dans notre conteneur :

# chroot /srv/tftp/snootles

Puis faire quelques modifications indispensables :

# cat /etc/fstab
# /etc/fstab: static file system information.
#
#     
       

proc            /proc           proc    defaults        0       0
/dev/nfs        /               nfs     defaults        1       1
none            /tmp            tmpfs   defaults        0       0
none            /var/run        tmpfs   defaults        0       0
none            /var/lock       tmpfs   defaults        0       0
none            /var/tmp        tmpfs   defaults        0       0 

# cat /etc/network/interfaces
# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
	address 192.168.1.8
	netmask 255.255.255.0
	gateway 192.168.1.254

# echo "snootles" > /etc/hostname
# cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	snootles

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

# apt-get install linux-image-2.6.26-2-686 alsa-base mplayer openssh-server sudo lm-sensors

Afin de pouvoir administrer la machine à distance, il conviendra d’y ajouter un utilisateur et de lui permettre de devenir root.

Important: par defaut, l’initrd installé ne sait pas utiliser NFS comme root device, il est donc nécessaire de changer la valeur de BOOT dans le fichier /etc/initramfs-tools/initramfs.conf :

# BOOT: [ local | nfs ]
#
# local - Boot off of local media (harddrive, USB stick).
#
# nfs - Boot using an NFS drive as the root of the drive.
#

BOOT=nfs

Puis de reconstruire l’initrd :

# dpkg-reconfigure linux-image-2.6.26-2-686
# update-initramfs -u

À cet instant, l’invité doit pouvoir démarrer en réseau.

Et nous en venons enfin à la raison principale de ce setup: le radio-reveil. Je crée le script bin/alarm dans le $HOME de mon utilisateur :

#!/bin/sh

URL="http://flaixeivissa.flaix.stream.flumotion.com/flaix/flaixeivissanopub.mp3.m3u"
DURATION=3720
CACHE=512

/usr/bin/mplayer -endpos ${DURATION} -cache ${CACHE} ${URL} > /dev/null 2>&1

Ce dernier jouera le stream de Flaix Eivissa pendant 1h et 2 minutes. Puis nous créons une entrée dans la crontab de l’utilisateur qui appellera ce script du lundi au vendredi à 7h30 :

$ crontab -l
30 07 * * 1-5 /home/imil/bin/alarm

On verifie que la machine ne chauffe pas trop dans son maigre espace entre le mur et le meuble :

imil@snootles:~$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:       +43.0 C  (crit = +97.0 C)

La prochaine étape consistera à monitorer cette valeur et l’existence de la machine via mon Nagios. D’ici là, FINI LE SON DE MERDE LE MATIN.

Et voila comment la technologie peut nous aider à vivre un peu mieux la depression post-vacances, j’enverrai peut-être cet article à Top-Santé…

Résumé des opérations :

# aptitude install oss4-base oss4-source oss4-gtk
# module-assistant prepare
# module-assistant auto-install oss4
# dpkg-reconfigure linux-sound-base # choisir "OSS"
# /etc/init.d/alsa-utils stop
# aptitude remove alsa-base alsa-utils
# reboot

Et c’est tout.
Si.
Pas de vim .asoundrc aux conditions délirantes, pas de “perfect setup” aux 1001 actions, non, juste ça marche.

Reste l’inévitable et problèmatique flash pour lequel il faudra se fendre d’une manipulation, uniquement parce que la librairie libflashsupport de Debian n’est pas compilée avec le support OSS :

$ wget http://www.4front-tech.com/developer/sources/stable/gpl/oss-v4.2-build2003-src-gpl.tar.bz2
$ tar jxvf oss-v4.2-build2003-src-gpl.tar.bz2
$ cd oss-v4.2-build2003-src-gpl/oss/lib
$ cc -shared -fPIC -m32 -O2 -Wall flashsupport.c -o libflashsupport.so
$ sudo install -s libflashsupport.so /usr/lib
$ sudo ldconfig

Moyennant quoi, ENFIN, je n’ai plus besoin de redémarrer mon navigateur web (quel qu’il soit) lorsque que je visualise une video flash et que je le laisse crever quelques heures (impliquant un inéxorable blocage du DSP).

Reste à espérer qu’OSSv4 fera son trou et convaincra les utilisateurs, jusqu’à faire bouger les distributions de cet empilage d’architectures sonores qui font de nous la risée de la MAO.

Update

Dans la liste des paquets à installer, remplacez désormais oss4-source par oss4-dkms sur testing.

J’ajoute, mais cela n’a evidemment aucun rapport avec cet article, que certains pays intellectuellement plus développés ont recemment confirmé que le partage de fichiers sur le réseau n’était pas illégal sur leur sol.

Le postulat est donc le suivant: seules certaines machines de mon réseau privé devront “sortir” sur une passerelle differente, et uniquement pour certains ports et protocoles.

Pour réaliser cette petite tambouille, j’ai à ma disposition :

• Un serveur dédié ou virtuel hébergé “ailleurs”, possédant une interface sur une DMZ
• Le serveur en question fonctionne sous GNU/Linux, on gère donc le NAT et le firewalling grâce à iptables
• Une passerelle qui me relie à l’Internet par le biais de mon fournisseur d’accès
• Cette passerelle fonctionne sous NetBSD 5.0.2, on gère le NAT et le firewalling grâce à pf (notez qu’ipf ne permettrait pas, à ma connaissance, d’utiliser les fonctions qui nous seront nécessaires)

La première étape consiste à établir un lien VPN entre la passerelle et le serveur dédié. J’ai utilisé OpenVPN, solution de choix de par sa simplicité, sa souplesse et sa grande stabilité. Étant donné qu’il existe un nombre incalculable de documentations sur cet outil, je colle ici mes configurations client et serveur sans plus de détails :

Sur le serveur :

tls-server

port 4444
dev tun
proto udp
local mon.serveur.dedie

cd /home/imil/etc/openvpn
ca keys/ca.crt
cert keys/dedie.crt
key keys/dedie.key
dh keys/dh1024.pem

client-config-dir ccd

server 10.20.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

client-to-client
route 192.168.1.0 255.255.255.0

comp-lzo

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

status openvpn-status.log

verb 3

Sur le client :

tls-client

proto udp
dev tun0

remote mon.serveur.dedie 4444

nobind

cd /usr/pkg/etc/openvpn/dedie-keys
ca ca.crt
cert monhost.crt
key monhost.key

comp-lzo

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

pull

verb 3
log /var/log/openvpn.log

Une fois OpenVPN démarré sur chaque point, une interface tun0 monte, avec coté serveur une IP du type 10.20.0.1 et côté client, 10.20.0.6.
Notez que, coté serveur dédié, on verra arriver une machine depuis la passerelle avec son IP réelle sur le réseau domestique, soit ici 192.168.1.0/24. Ainsi, c’est ce sous-réseau que nous devons NATer sur le dédié GNU/Linux.

Une particularité de mon montage est que je ne souhaite pas utiliser l’IP publique principale de mon serveur public car celle-ci possède un reverse sur mon domaine et est facilement identifiable. Par chance, mon hébergeur me donne la possibilité d’ajouter des alias IP routés sur l’interface publique. En l’occurence, c’est précisemment sur cet alias que j’effectue un source NAT plutot que du MASQUERADING :

### règles INPUT
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # j'autorise en entrée les connexions établies et connexes
# iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT # j'autorise l'echo-request
# iptables -A INPUT -p udp -m udp --dport 4444 -j ACCEPT # j'autorise la connexion vers OpenVPN
# iptables -A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable # et je rejette tout le reste sur l'interface eth0
### règles de NAT
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source mon.alias.ip.public

Désormais, si sur ma passerelle je plaçais une route par defaut sur 10.20.0.1 (le boût du tunnel sur le serveur dédié), les machines de mon réseau 192.168.1.0/24 apparaîtraient avec l’IP mon.alias.ip.public.
Cependant, seulement certaines machines, et surtout certains protocoles devront être soumis à cette politique, et c’est grâce à pf, et en particulier la directive route-to, que nous allons mettre en place ce routage conditionnel. Voici les lignes corresponsantes du fichier pf.conf de notre passerelle NetBSD :

int_if="xennet0"

[...]

pass in on $int_if route-to (tun0 10.20.0.1) proto tcp from 192.168.1.10 \
        to any port 80
pass in on $int_if route-to (tun0 10.20.0.1) proto udp from 192.168.1.10 \
        to any port > 10000

Décodage: Concernant le traffic qui arrive sur l’interface interne $int_if, toute demande en provenance de l’IP 192.168.1.10 à destination du protocole HTTP devra être routée vers l’interface tun0 en utilisant l’adresse de passerelle 10.20.0.1.
toute demande en provenance de l’IP 192.168.1.10 à destination de ports UDP supérieurs à 10000 devra être routée vers l’interface tun0 en utilisant l’adresse de passerelle 10.20.0.1.

J’utilise ce routage depuis hier soir, l’overhead du lien VPN est minimal et l’ensemble se comporte correctement. Je ne prétend pas, avec ce système, bénéficier d’un anonymat hors du commun, mais il me permet au moins de ne pas exposer mon IP publique.

. Basculement vers autoconf pour la génération du Makefile
. Correction du bug d’affichage en console
. Pas mal de fixes autour de la standardisation des variables
. Le lookup du pkg_summary en bz2 ou gz est désormais automatique
. Gros ménage des conditions pour opensolaris
. substitution de variables dans repositories.conf ($arch et $osrelease)
. De traditionnels bugfixes
. Portage -encore un peu hors des clous- pour SunOS 5.8

Le soft est disponible sur pkgsrc-wip et si aucune plainte n’apparait, je mettrai à jour pkgsrc.

À vos torture tests !

Quelques recherches m’ont conduit sur ce thread ou l’on comprend que l’implémentation de NFSv4 n’est pas encore totalement synchro entre Linux et Solaris. Ainsi, il suffit de modifier la valeur de NFS_CLIENT_VERSMAX dans le fichier /etc/default/nfs sur le client OpenSolaris de cette façon :

NFS_CLIENT_VERSMAX=3

Pour forcer l’utilisation de NFSv3, moyennant quoi, j’accède désormais sans problème à mes documentations multimédia à haute teneur informatives.

Ce soir, je pestais encore contre le duo infernal Firefox/Flash. En effet, depuis plus d’un an maintenant (!), lorsqu’une page contient du flash et que le navigateur est fraichement démarré, tout se passe pour le mieux, mais au bout de quelques heures, si d’aventure je voulais visualiser un contenu à haute teneur informative animé par cette bouse de lecteur, blocage à 1/10 de la video, et le son s’emballe, une seule solution alors: killall -9 firefox-bin, rechargement du veau etc etc. Très irritant à la longue.

Et puis mon dzen favori me reparle de Chrome et m’explique que je n’aurais probablement pas les mêmes problèmes avec le navigateur de google puisque ce dernier a d’ores et déjà implémenté le forking par fenêtre, en lieu et place du threading, et que par conséquent, chaque “page” constitue un processus en soi, gêré donc de façon autonôme. Je réessaye donc, et je prend une claque. Le browser se lance en un clin d’oeil, et le chargement des pages est proprement hallucinant. Cerise sur le gâteau, le proxying HTTP est désormais configurable.

Je l’essaye toute la soirée, me documente sur la façon d’utiliser cette verrue qu’est flash-plugin et tombe sur ce lien, qui explique parfaitement comment executer chrome pour que ce dernier utilise les plugins mozilla. Résultat des courses: “make google chrome my default browser”. Pour l’instant en tout cas.

Ils ont probablement pas besoin de pub, mais comme le lien est pas exactement facile à trouver, les packages Debian sont disponibles ici.

Après avoir consciencieusement refusé les conditions d’utilisation de l’”os” moisi livré par defaut et préparé ma lettre de demande de remboursement de la license de cette vermine qui polluait la machine, je me lançais dans l’installation d’une Debian Lenny sur la première partie du disque de 160Go, la seconde étant evidemment dédiée à un NetBSD 5.0.

L’installation via une clé USB fut une banale formalité, et 15 minutes plus tard, le NC10 bootait sur un kernel 2.6.26.

Et là, vous vous attendez à 10 pages de fixes et autres bidouilles pour faire fonctionner les divers periphériques de la bête. Eh bah non. Ok, j’ai du me fendre d’un module-assistant install madwifi pour des raisons evidentes, mais mis à part cela, _tout_ fonctionne out-of-the-box.

Cerise sur le gateau, Xen, qui lorsque je bootais mon X31 sur un hyperviseur/noyau-xen faisait s’emballer la température de la machine, ne provoque pratiquement aucune surchauffe (1 à 2 degrés de plus que sur un noyau classique).

Il est tout à fait regrettable que cette merveille ne se vende pas par defaut avec un OS convenable, car rien n’aurait rebuté le GENS, pas même la caméra integrée qui semble parfaitement fonctionner.

$ sudo rm -f /etc/asoundrc
$ sudo apt-get remove pulseaudio*

Cette dernière action effacera également la dépendance ubuntu-desktop, mais cela n’a aucun impact.

Virer toutes les références à pulse potentiellement présentes dans vos ~/.asoundrc et .asoundrc.asoundconf, puis dans System->Preferences->Sound, dans la section Devices, tout passer à Alsa.

On reboote histoire de tout remettre d’equerre, et HOPLAAaaa, dégage vieux “framework sonore” foireux.
Tout refonctionne par-fai-te-ment.

Comme on peut le constater sur ce suivi de bug launchpad, ça concerne un peu de monde.

Pour résumer, c’est pas gagné. Enfin pas pour le Héron Boiteux en tout cas. Mais on a bon espoir que d’ici Avril 2009 on ne passe plus pour des charlots quand un pote voit qu’”avec ton Linux présumément stable tu peux même pas matter deux videos youtube sans que ton navigateur crashe mOUAhahaha” – “oui mais c’est paske y’a pulseaudio qui… nan rien.”

Bref, en attendant un fix digne de ce nom, un des gars impliqués dans ce beau bordel propose une solution temporaire: virer la libflashsupport -qui est la machine-à-crasher-Firefox-, puis installer ce package nspluginwrapper de son cru. J’essaye sa solution depuis quelques minutes, ça a l’air de le faire.

</aigr>

Putain j’en avais chié avec celle là…