2011-07-10 23:32

Linux : configurer la souris pour un gaucher

mr_bump

C'est marrant comme chaque action quotidienne devient compliquée avec le bras droit dans le plâtre. Tout devient complexe : valider un ticket SNCF/RATP (on valide sa carte du mauvais côté), utiliser des ciseaux (on ne voit pas ce qu'on coupe), se servir d'un ordinateur (la souris devient inutilisable), ouvrir son canif (prévu pour s'ouvrir d'une seule main, mais de la droite)...
L'avantage, pour la souris, c'est qu'on peut modifier facilement sa configuration et l'adapter à ses besoins.

La manière la plus simple de le faire et d'utiliser xmodmap. Mais cette méthode modifie le mapping de manière identique pour toutes les souris connectées.
À l'inverse, xinput permet de configurer indépendamment chaque souris. Il permet par exemple de modifier le mapping d'une souris USB sans toucher à celui du touchpad. C'est cet outil que je vais utiliser.


Configurer la souris


Il faut d'abord lister les différents périphériques connectés :

~$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                   	id=10	[slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                   	id=11	[slave  pointer  (2)]
⎜   ↳ ImPS/2 Generic Wheel Mouse              	id=14	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
↳ Power Button                            	id=6	[slave  keyboard (3)]
↳ Video Bus                               	id=7	[slave  keyboard (3)]
↳ Power Button                            	id=8	[slave  keyboard (3)]
↳ Sleep Button                            	id=9	[slave  keyboard (3)]
↳ HP Webcam-50                            	id=12	[slave  keyboard (3)]
↳ AT Translated Set 2 keyboard            	id=13	[slave  keyboard (3)]
↳ HP WMI hotkeys                          	id=15	[slave  keyboard (3)]

On voit que deux périphériques correspondent à ma souris et portent le même nom. L'option --long permet d'avoir une description plus détaillée.
~$ xinput list --long
[...]
⎜   ↳ Logitech USB Receiver                   	id=10	[slave  pointer  (2)]
Reporting 3 classes:
Class originated from: 10
Buttons supported: 24
Button labels: Button Left Button Middle Button Right Button Wheel Up Button Wheel Down Button Horiz Wheel Left Button Horiz Wheel Right Button Side Button Extra Button Forward Button Back Button Task Button Unknown Button Unknown Button Unknown Button Unknown Button Unknown Button Unknown Button Unknown Button Unknown Button Unknown Button Unknown Button Unknown Button Unknown
Button state:
Class originated from: 10
Detail for Valuator 0:
Label: Rel X
Range: -1.000000 - -1.000000
Resolution: 1 units/m
Mode: relative
Class originated from: 10
Detail for Valuator 1:
Label: Rel Y
Range: -1.000000 - -1.000000
Resolution: 1 units/m
Mode: relative
⎜   ↳ Logitech USB Receiver                   	id=11	[slave  pointer  (2)]
Reporting 3 classes:
Class originated from: 11
Buttons supported: 7
Button labels: Button 0 Button Unknown Button Unknown Button Wheel Up Button Wheel Down Button Horiz Wheel Left Button Horiz Wheel Right
Button state:
Class originated from: 11
Keycodes supported: 248
Class originated from: 11
Detail for Valuator 0:
Label: None
Range: 1.000000 - 652.000000
Resolution: 10000 units/m
Mode: absolute
Current value: 683.000000
[...]

C'est donc la première qui possède les boutons à inverser (Button Left, Button Middle et Button Right). On note qu'elle est identifiée par l'id 10. On va tester ça tout de suite. Pas trop d'hésitations à avoir : si on s'est trompé, un redémarrage de X.org rétablira les paramètres d'origine.

 ~$ xinput set-button-map 10 3 2 1

10 correspond ici à l'ID de la souris. Les trois chiffres qui suivent correspondent aux différentes actions affectées, dans l'ordre des boutons : 1 correspond au clic gauche pour un droitier, 2 au clic du milieu, et 3 au clic droit pour un droitier. On inverse ici les actions 1 et 3.

Conserver la configuration au redémarrage


La souris devrait maintenant fonctionner comme attendu, mais les paramètres d'origine seront restaurés au prochain redémarrage de X.org ou de l'ordinateur. Il faudra donc lancer cette commande à chaque lancement de X.org.

Pour les utilisateurs d'OpenBox, il suffit d'éditer ~/.config/openbox/autostart.sh et d'ajouter la ligne :

xinput set-button-map <id> 3 2 1 &
Où <id> correspond à l'identifiant de la souris, 10 chez moi.

Pour les utilisateurs de gnome, il faut créer un script de démarrage. Ouvrir un éditeur de texte et coller le texte suivant :

#!/bin/sh
xinput set-button-map <id> 3 2 1 &
exit 0
Où <id> correspond à l'identifiant de la souris, 10 chez moi.

L'enregistrer, par exemple sous dans ~/.lhmouse.sh, et le rendre exécutable :

chmod +x ~/.lhmouse.sh

Il faudra ensuite ajouter ce script aux programmes lancés au démarrage par gnome (Système → Préférences → Applications au démarrage).


Posted by St3rk | Permanent link | File under: linux
- - - -

2011-05-29 01:16

FreeBSD : activer l'égaliseur sous OSS

FreeBSD utilise OSS pour la gestion du son. Certes, l'interface de mixer est bien plus sobre que celle d'alsamixer, mais elle est tout aussi efficace.

Une fois la carte son activée, il suffit d'éditer /boot/loader.conf pour ajouter le support de l'égaliseur.

Ajouter la ligne :

hint.pcm.0.eq=1

Après un reboot, on vérifie le changement grâce à mixer :

%mixer
Mixer vol is currently set to 75:75
Mixer bass is currently set to 50:50
Mixer treble is currently set to 50:50

Cool, ça marche :-)
On peut maintenant modifier le niveau des basses ou des aigus à l'aide de la commande mixer. Par exemple, pour passer les basses à 40% au lieu de 50% :

%mixer bass 40
Setting the mixer bass from 50:50 to 40:40.


Posted by St3rk | Permanent link | File under: freebsd, musique
- - - -

2011-05-14 18:48

FreeBSD : jail et client VPN

monopoly_icon_small.gif

Les jails sous FreeBSD sont souvent qualifiées de "chroot sous steroïdes". Elle permettent de confiner des processus, mais également des systèmes FreeBSD complets.

On se rapproche alors des possibilités de la para-virtualisation : la jail possède sa propre IP, et sa propre liste d'utilisateurs.

La configuration du réseau est cependant plus complexe qu'avec une solution de types xen. Par exemple, la jail partage la table de routage de la machine "hôte". Il est également impossible de changer d'IP ou de créer une interface virtuelle depuis la jail.


Le problème


Je souhaite mettre en place la configuration suivante :

- Une jail, configurée et démarrée par ezjail. Elle devra router router le trafic à destination de l'extérieur par un serveur VPN, ce qui me permettra de télécharger des ISO Linux en toute tranquillité.

- La machine "hôte", qui me sert entre autre de serveur mail. Pour continuer à bénéficier du reverse-DNS, elle devra conserver l'IP publique attribuée par mon FAI.

Il est impossible de créer une interface virtuelle tun/tap depuis la jail. Il est possible d'en créer une depuis la machine "hôte", puis de l’attribuer à la jail, mais cette procédure est complexe. Il est plus simple d'installer le client VPN sur la machine "hôte".


Le plan


On procédera de la manière suivante :

- Installer et configurer OpenVPN :
configurer la machine hôte pour qu'elle soit connectée au VPN.

- Activer le support des tables de routage multiples :
recompiler le noyau afin de pouvoir configurer plusieurs tables de routage.

- Attribuer l'une des tables de routage à la jail et la remplir :
une des tables de routage, comportant le serveur VPN comme passerelle par défaut, permettra à la jail de joindre l'extérieur via le VPN.

- Créer un script afin de remplir la table de routage au démarrage :
pour ne pas avoir à le faire à la main à chaque reboot.


Toutes les manipulations seront effectuées sur la machine "hôte".


Installer et configurer OpenVPN


Installons OpenVPN :

#cd /usr/ports/security/openvpn
#make config-recursive
#make install clean

Il faut configurer OpenVPN afin de se connecter au serveur. Le fichier par défaut se trouve dans /usr/local/etc/openvpn/openvpn.conf. Créons le fichier :

#mkdir /usr/local/etc/openvpn
#touch /usr/local/etc/openvpn/openvpn.conf

Il faut maintenant le remplir. Son contenu dépend du serveur VPN. Le fichier d'exemple est un bon point de départ si vous ne pouvez pas vous en procurer un "tout fait".

Dans ma configuration, la machine est connectée au serveur VPN mais continue de router le traffic normalement. Il faut donc empêcher OpenVPN de changer la passerelle par défaut, en commentant le ligne suivante si elle est présente (toujours dans /usr/local/etc/openvpn/openvpn.conf) :

# redirect-gateway def1 bypass-dhcp

Ajoutons ensuite la ligne suivante à /etc/rc.conf afin de lancer OpenVPN au démarrage :

openvpn_enable="YES"

Lançons openVPN afin de vérifier qu'il n'y a pas d'erreur :

#openvpn /usr/local/etc/openvpn/openvpn.conf &

Si tout se passe bien, vous verrez normalement une ligne de ce types au démarrage :

May 14 15:19:00 kirby openvpn[1492]: Initialization Sequence Completed

Notez également la présence d'une ligne ressemblant à :

openvpn[1492]: /sbin/route add -net 10.13.3.0 10.13.3.61 255.255.255.0

On voit ici que l'IP de la passerelle permettant de passer par le VPN est 10.13.3.61. Retenez-la, elle servira bientôt.

Activer le support des tables de routage multiples


Le problème qui se pose dans cette partie est le suivant :

- La machine "hôte" est connectée au serveur VPN, mais celui-ci n'est pas défini comme passerelle par défaut. Le trafic est donc toujours routé par la box.

- La machine "hôte" et la jail partagent la même table de routage.

Donc le trafic de la jail est également routé par la box (ça ressemble à un sophisme, mais le raisonnement me semble bon :-) ).


Il faut donc attribuer des tables de routage différentes à la machine "hôte" et à la jail. Pour cela, nous allons recompiler le noyau en activant le support des tables de routage multiple.

Créons le fichier de configuration pour notre noyau :

#cd /usr/src/sys/<ARCHITECTURE_PROC>/conf
#cp GENERIC KIRBY

<ARCHITECTURE_PROC> devra être remplacé par le type d'architecture de votre micro-processeur, i386 dans mon cas.
Le nom du noyeau, ici KIRBY n'a pas d'importance. Vous pouvez l'appeler comme vous le souhaitez. Conventionnelement, il est écrit tout en majuscule.

Ajoutons la ligne suivante à notre fichier de configuration (toujours /usr/src/sys/<ARCHITECTURE_PROC>/conf/kirby) :

options         ROUTETABLES=4         # default is 1, max 16

On va maintenant compiler le noyau, et l'installer :

cd /usr/src
make buildkernel KERNCONF=KIRBY
make installkernel KERNCONF=KIRBY


Attribuer l'une des tables de routage à la jail et la remplir


Il faut maintenant attribuer la table de routage à notre jail. Avec ezjail, le fichier de configuration est :

/usr/local/etc/ezjail/<NOM_DE_LA_JAIL>

Il faut ajouter ou modifier la ligne suivante :
export jail_<NOM_DE_LA_JAIL>_fib="1"

<NOM_DE_LA_JAIL> correspond au nom que vous avez donné à votre jail.

Remplissons la table de routage afin de lui donner accès à l'extérieur:

setfib 1 route add default <IP_DE_LA_PASSERELLE>

<IP_DE_LA_PASSERELLE> correspond à l'adresse de la passerelle du VPN, chez moi 10.13.3.61.

Vous pouvez tester le fonctionnement, par exemple en vous rendant sur le site geoiptool depuis la machine "hôte" et depuis la jail. Vous devriez avoir deux IP publiques différentes.


Créer un script afin de remplir la table de routage au démarrage


Tout devrait fonctionner à cette étape. Mais dans la configuration actuelle il faut remplir la table de routage à chaque démarrage. Afin d'automatiser tout ça, j'ai crée un petit script. Au passage, merci à Smortex de m'avoir aidé à comprendre le système de démarrage de FreeBSD.

Créons le fichier /usr/local/etc/rc.d/fib, et insérons :

#!/bin/sh
#

# PROVIDE: fib
# REQUIRE: NETWORKING openvpn ezjail

. /etc/rc.subr

name="fib"
start_cmd="${name}_start"
stop_cmd="${name}_stop"
rcvar=`set_rcvar`

load_rc_config $name

: ${fib_enable="NO"}

command="/usr/sbin/setfib"

fib_start()
{
         :       ${fib_gw=$(cat /var/log/messages | grep -E '/sbin/route add' | awk '{print $10}' | sed -n ' $p')}
         ${command} ${fib_nb} route add default ${fib_gw}
}

fib_stop()
{
         ${command} ${fib_nb} route delete default
}

load_rc_config $name
run_rc_command "$1"

Modifions les droits pour le rendre exécutable :
#chown +x /usr/local/etc/rc.d/fib

Il faut aussi remplir /etc/rc.conf afin de lancer le script script au démarrage et de lui fournir les information dont il a besoin :
fib_enable="YES"
fib_nb="1"

Si l'IP de la passerelle est toujours identique, on peut ajouter dans /etc/rc.conf :
fib_gw="<IP_DE_LA_PASSERELLE>"

Tout est maintenant configuré. Il ne reste plus qu'à redémarrer pour en tester le fonctionnement.


sources :
http://www.freebsd.org/doc/handbook/kernelconfig-building.html
http://forums.freebsd.org/showthread.php?t=19607

source de l'image :
http://www.worldofmonopoly.com/fansite/index.php


Posted by St3rk | Permanent link | File under: freebsd
- - - -

2011-04-26 15:07

FreeBSD : configurer un serveur mail

Je continue donc ma migration sous freeBSD, et c'est maintenant le home-server qui y passe.
Première étape de configuration, le serveur mail, en utilisant Postfix et Procmail.

Ce tutoriel vous permettra de configurer facilement et rapidement un serveur mail. Par contre, chaque boite mail devra correspondre à un utilisateur existant sur le système. Cette méthode est donc inadaptée si vous souhaitez créer un nombre important de boites mail : à chaque fois il faudra créer l'utilisateur, éventuellement le chrooter ou désactiver l'accès ssh, paramétrer le .procmailrc, etc.

Bref, si vous avez des besoins plus complexes, je vous conseille plutôt d'aller voir ce tutoriel, bien plus élaboré mais aussi plus long à mettre en place.


Étape 1 : désactiver sendmail

Sendmail est le M.T.A. installé par défaut sous freeBSD. Comme je souhaite le remplacer par postfix (plus simple à configurer), il va falloir le désactiver.

On va commencer par l'arrêter à l'aide de la commande :

# /etc/rc.d/sendmail forcestop

S'il fait de la résistance, un killall sendmail devrait résoudre le problème.

Sendmail est maintenant désactivé, mais il sera relancé automatiquement au prochain démarrage de l'ordinateur. Afin d'empêcher cela, on prendra soin d'éditer le fichier /etc/rc.conf, et d'ajouter la ligne suivante :

sendmail_enable="NONE"

Étape 2 : installer les programmes nécessaires

Nous allons d'abord installer postfix, le MTA qui remplacera sendmail :

# cd /usr/ports/mail/postfix/
# make config-recursive
# make install clean

Les questions suivantes vous seront posées durant l'installation :

You need user "postfix" added to group "mail". Would you like me to add it [y]?
Would you like to activate Postfix in /etc/mail/mailer.conf [n]?

Il faut répondre oui au deux (en tapant "Y").

Maintenant, installons procmail :

# cd ../procmail/
# make config-recursive
# make install clean

Étape 3 : configurer postfix

Nous allons adapter la configuration de postfix à nos besoins. Le fichier de configuration principal est /usr/local/etc/postfix/main.cf.

Déplaçons le afin d'en garder ne copie intacte :

# mv /usr/local/etc/postfix/main.cf /usr/local/etc/postfix/main.cf.bak

Recréons un fichier vide :

# touch /usr/local/etc/postfix/main.cf

On peut maintenant coller dans le fichier vierge /usr/local/etc/postfix/main.cf ainsi obtenu la configuration suivante :

queue_directory = /var/spool/postfix
command_directory = /usr/local/sbin
daemon_directory = /usr/local/libexec/postfix
mail_owner = postfix
unknown_local_recipient_reject_code = 550
mynetworks_style = host

debug_peer_level = 2

debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5

sendmail_path = /usr/local/sbin/sendmail
mailq_path = /usr/local/bin/mailq
setgid_group = maildrop
html_directory = no
manpage_directory = /usr/local/man
sample_directory = /usr/local/etc/postfix
readme_directory = no
home_mailbox = Maildir/
mailbox_command = /usr/local/bin/procmail -a "$EXTENSION" DEFAULT=$HOME/Maildir/ MAILDIR=$HOME/Maildir
mydomain = mon_nom_de_domaine.fr
myhostname = hote.$mydomain
myorigin = $myhostname
mydestination = $myhostname, localhost,$mydomain

mynetworks = 192.168.1.0/24
mynetworks_style = subnet

Les variables soulignées sont à remplacer par celles correspondant à votre machine. Le nom de domaine fini géralement par .com, .fr, .org (ou tout autre TLD). Le nom d'hôte correspond généralement au nom de la machine affiché sur le prompt, avant le "$" ou le "#".

La ligne home_mailbox = Maildir/ permet à chaque utilisateur d'avoir sa boite mail dans son home. Par exemple, toto pourra accéder à ses mails dans /usr/home/toto/Maildir/, au lieu de /var/mail/toto.

La ligne mailbox_command = /usr/local/bin/procmail -a "$EXTENSION" permet d'appeler procmail à chaque fois qu'on reçoit un mail. On pourra ainsi créer des règles pour trier le courrier.

Le plus gros est fait. On peut maintenant essayer de lancer postfix :

# /usr/local/etc/rc.d/postfix onestart

Étape 4 : tester le fonctionnement de postfix

Afin de tester son fonctionnement, vous pouvez vous envoyer un message à l'aide de mail depuis le serveur. Vous pouvez soit l'utiliser en mode interactif à l'aide de la commande :

% mail <utilisateur>

On rentrera ensuite le sujet, entrée, puis le corps du message. La saisie se termine par "ctrl + D" sur une ligne vide, ou un point sur une ligne vide puis entrée.

On peut aussi tout faire tenir en une ligne de commande :

% echo "<Message_à_envoyer>" | mail -s "<sujet_du_message>" <utilisateur>

Si tout s'est bien passé, un dossier Maildir a dû être créé dans le home de votre utilisateur. Vous devez pouvoir lire votre message :

% cat /usr/home/<utilisateur>/Maildir/new/1303821288.V5bd4c369I14M268867.hote.nomdedomaine.fr

La suite de chiffre est bien sûr variable, et hote.nomdedomaine.fr dépend de votre configuration (heureusement qu'il y a la complétion :-) ).

Donc si tout s'est bien passé, vous pouvez voir votre dossier et votre mail. Ce n'était pas le cas pour moi. J'ai donc été voir le fichier de log (/var/log/message).

% cat /var/log/messages
[...]
Apr 26 12:28:50 <hote> postfix/smtpd[24331]: fatal: open database /etc/aliases.db: No such file or directory
[...]

Il suffit dans ce cas de créer une fichier d'allias vide, de reconstruire la base de donnée, puis de rédémarrer postfix :

# touch /etc/aliases
# postmap /etc/aliases
# /usr/local/etc/rc.d/postfix onestart

Vous pouvez re-tester en vous envoyant un mail, cette fois-ci ça devrait marcher.

Par contre, la configuration telle-quelle ne permet pas l'envoi de mail depuis le serveur : la configuration par défaut de procmail impose un chroot des démons.
Il y a donc deux possibilités :

- on met correctement en place le chroot, afin d'augmenter la sécurité du serveur
- on désactive le chroot dans les fichiers de configuration

J'ai choisi la deuxième solution, je pense que le niveau de sécurité reste largement suffisant. Il faut alors modifier le /usr/local/etc/postfix/main.cf.

Copier le fichier afin d'en garder une copie :

# cp /usr/local/etc/postfix/master.cf /usr/local/etc/postfix/master.cf.bak

Il faut maintenant éditer le fichier, afin de rdéfinir tous les démons comme non chrootés. On peut voir ici une ligne qui défini smtp comme chrooté :

# #================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
#================================================================
smtp inet n - - - - smtpd

Il faudra la modifier en :

# #================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
#================================================================
smtp inet n - n - - smtpd

Il faudra procéder de même pour toutes les lignes non commentées du fichier.

Maintenant que postfix est paramétré, et fonctionne correctement, on peut le lancer au démarrage. Il faut éditer le fichier /etc/rc.conf, et ajouter :

postfix_enable="YES"

Étape 5 : paramétrer procmail

Le paramétrage de procmail se fait directement dans le dossier de l'utilisateur, à l'aide du fichier ~/.procmailrc. Je ne vais pas m'étendre en explications dessus, il y a déjà pas mal de documentation.

Il faut par contre faire bien attention aux droits de ce fichier. Si vous avez un message du types :

Apr 26 21:39:13 <hote> procmail[56673]: Suspicious rcfile "/home/<user>/.procmailrc"

Vérifiez que le .procmailrc appartient bien à l'utilisateur, et que les droits sur le fichier sont à 640.


Conclusion

Voilà, le serveur mail est fonctionnel. Il reste à installer un client en ligne de commande (ex : mutt), un webmail (ex : roundcube), ou à le paramétrer pour le rendre accessible via un M.U.A..


Posted by St3rk | Permanent link | File under: freebsd
- - - -

2011-04-22 21:31

FreeBSD : faire fonctionner le NuForce uDac

nuforce µDAC

Le NuForce uDac est un DAC USB, qui joue le rôle d'une carte son externe. Malgré sa taille très réduite, sa qualité sonore est plus que correcte. Il permet donc de remplacer avantageusement les puces audio, souvent de qualité médiocre, intégrées au ordinateurs portables.

J'ai cependant eu quelques problèmes pour le faire fonctionner sous freeBSD. La démarche proposée dans le handbook ne permet pas de charger le driver adéquat.

On peut d'abord constater que le DAC est bien détecté au branchement :

# dmesg [...]
uhid1: <Vendor strings are placed here. Nuforce DAC, class 0/0, rev 1.10/1.00, addr 2> on usbus0

On tente donc de charger le méta-pilote snd_driver, ce qui permet de charger les pilotes audio les plus courants :

# kldload snd_driver

On affiche ensuite les modules sélectionnés :

cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386)
Installed devices:
pcm0: <Intel ICH4 (82801DB)> (play/rec) default

Manque de bol, seul le driver de la puce audio interne du portable a été chargé (Intel ICH4). Apparement la puce du NuForce uDac ne fait pas partie des plus courantes. Il va donc falloir trouver sa référence et chercher le driver correspondant dans les notes de compatibilité matérielle.

Un petit tour par headfi nous apprend que la puce utilisée est une Sabre ESS9022.
Re-manque de bol, elle ne fait pas partie de la liste de compatibilité. Si un driver existe, il faudra le trouver autrement.

Coup de chance cette fois, à force de chercher une solution sur internet, je suis tombé sur une page parlant de snd_uaudio. Un petit coup d’œil dans la page de man nous apprend que ce driver est destiné aux cartes son USB. Ça semble correspondre...

On le charge à la main :

# kldload snd_uaudio

On regarde s'il correspond bien au uDac :

# cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386)
Installed devices:
pcm0: <Intel ICH4 (82801DB)> (play/rec) default
pcm1: <USB audio> (play)

Cette fois ça marche. Il ne reste donc qu'à ajouter la ligne suivante dans /boot/loader.conf afin de charger tout ça au démarrage :

snd_uaudio_load="YES"

Voilà, après ces quelques efforts, je peux enfin profiter de ma musique sans saigner des oreilles :-P


Posted by St3rk | Permanent link | File under: freebsd, musique
- - - -