Flaix, la formule anti-aigr’

Tags: , , , , ,
11 Comments »

Le retour de l’île est toujours un moment difficile. Lorsqu’on a passé deux semaines dans la joie, la fête, parmi les siens, baigné dans une culture aux antipotes de la jérémiade permanente, revenir au pays qui a fait de la plainte son leitmotiv est psychologiquement très angoissant.
Une conséquence de cette aversion, c’est que pendant plusieurs semaines, je serai totalement imperméable, voire volontairement réfractaire à l’information politique et sociale. Cette façon de présenter l’actualité, plaintive à outrance, me fatigue et n’aide pas à l’atterrissage en douceur tant le choc culturel est immense. L’autre conséquence, c’est que je prépare mon départ définitif, très probablement dans l’une des deux capitales de la péninsule. Cette migration n’aura probablement pas lieu avant plusieurs années, je ne m’étendrai donc pas plus, je la prépare, c’est tout.

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é

Front de Liberation du SON

Tags: , ,
6 Comments »

Comme je le disais il y a quelques jours sur GCU, les sirènes d’OSSv4 me charment depuis quelques mois, épuisé que je suis de me battre avec les differents framework sonores “”"modernes”"” apparus sous GNU/Linux depuis quelques années. Et bien ça y est, j’ai sauté le pas. Et comme prévu, ce passage est une véritable sinécure.

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.

Au feu, tournez à gauche

Tags: , , , ,
3 Comments »

Pour des raisons évidentes, j’ai décidé de rendre un peu moins aisée (i.e. pas immédiate) la découverte de mon IP. Plus précisemment, pour certains protocoles et pour certaines machines, je veux que l’IP vue par mon/mes peers ne soit pas directement l’IP que mon fournisseur d’accès m’affecte.

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.

pkgin 0.3.0 dans ton wip

Tags: , , , , ,
2 Comments »

Pkgin 0.3.0 voit -enfin- le jour. Pas de changements fondamentaux dans le code de gestion d’install/upgrade mais plutot une tripotée de petits fixes issus d’utilisateurs-hackers autour du globe. Dans le désordre :

. 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 !

OpenSolaris nfs client: “permission denied”

Tags: , ,
No Comments »

Petite astuce, ça evitera de chercher trop loin. J’ai constaté que, par defaut, mon desktop OpenSolaris ne parvenait pas à lister le contenu d’un serveur NFS situé sur une Debian GNU/Linux testing.

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.

Google Chrome, la claque

Tags: ,
5 Comments »

J’entend parler de Google Chrome depuis un certain temps déjà. Lorsque les premières Alphas Linux sont sorties, je m’y suis même essayé, je l’avais trouvé vraiment rapide, mais le manque de support de proxy HTTP dans ces premières versions m’avait fait le mettre de côté.

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.

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in
Performance Optimization WordPress Plugins by W3 EDGE