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à…

Evidemment, j’ai été m’inspirer du limite rigolo “PulseAudio Perfect Setup” et ses 4000 conditions (pour flash, faites ça, pour les jeux, ça, pour amarok, ça, pour audacity, ça etc…), mais comme on peut s’y attendre, y’a des cas non couverts, et de toutes façons, cela ne résoud aucunement, par exemple, les problèmes (connus !) de libflashsupport / flashplugin qui monopolisent le device son, le rendant indisponible pour certaines autres applications.

Jusqu’à hier, je pensais que ces problemes ne concernaient que les gens ayant migré de versions anterieures en 8.04. Et puis je me rend chez mon cousin, ingenieur du son, qui est passé à UbuntuStudio il y a pratiquement deux ans. Lui aussi a migré en 8.04 (d’ubuntustudio, donc), et là encore, cette grosse merde de moisiaudio rend sa machine totalement inutilisable pour un musicien qui a clairement autre chose à foutre que d’aller debugger pourquoi jackd, qui fonctionnait parfaitement en 7.10, refuse de démarrer. Et non, il ne s’agit pas d’un upgrade, mais d’une install from scratch.

Bref, cette release qui devait être majeure a subi l’assaut débile des gens qui ne peuvent pas s’empêcher de mettre des nouveaux trucs alors même qu’ils ne sont pas éprouvés (les mêmes qui ont foutu le bordel dans la gestion ATA du noyau ?), et cela aura pour résultat la citation suivante: “ah bin c’est pas terrible Linux, j’arrive même pas à avoir du son”.

La domination totale, elle ne s’obtent pas en mettant les derniers softs cutting-edge dans une distribution, parce que l’utilisateur lambda, il s’en tape de l’infrastructure sonore de son OS, il veut juste du son. Un peu de discipline merde.

update

Mon ingenieur du son de cousin a réinstallé son Héron Boiteux en prenant soin de bien désinstaller tout ce qui avait trait de près ou de loin avec MoisiAudio. Bin devinez quoi ? tout fonctionne au poil. PulseAudio, ça marche surement super bien sur la box des developpeurs.