Deblan blog

Informatique

Debian + XPS 15 (9530)

Mon agence m'a acheté le dernier XPS 15 de Dell (9530). C'est une belle machine, autant à l'extérieur qu'à l'intérieur...Cependant, aussi jolie soit-elle, installer Debian dessus n'a pas été de tout repos. Livrée avec Windows 8 et des Gigas d'espace disque monopolisés par les partitions EFI, Windows 8 et les partitions de restauration, j'ai commencé par faire le grand ménage en virant tout.

J'ai installé Debian dessus, je me suis confronté à l'éternel problème des matériels plus ou moins reconnus. J'ai quand même eu de la chance car une grande partie d'entre eux l'était.

Il faut savoir que ce laptop n'a pas de port ethernet, ainsi, il m'a été nécessaire d'utiliser un adapteur USB/Ethernet. Sachez que Debian Wheezy pète une pile avec l'USB3 et les dongles USB2. Faute au kernel ? Sans doute, mais je n'ai pas voulu perdre de temps avec ces conneries donc j'ai migré sur la SID. Le kernel est donc plus récent et j'ai écarté des problèmes de connectivité.

Après l'installation, j'ai rencontré 3 problèmes majeurs :

  • pas d'interface wifi
  • pas de son
  • mplayer lisait les vidéos de manière saccadée
  • mon touchpad ne me permettait pas de faire un middle click : pas pratique du tout pour faire des copiés/collés

Le Wifi

Il a suffit d'installer le paquet iwlwifi et tout est rentré dans dans l'ordre. Ça implique d'avoir paramétré les dépots non-free (@see).

Le son

Ce souci de son m'a littéralement fait rager. Le problème est simple en fait : la sortie HDMI est considérée comme une carte son et Alsa la positionne comme carte par défaut. Pour résoudre le problème, j'ai installé pulseaudio (et ça m'a fait mal aux fesses) et j'ai placé la conf suivante dans mon ~/.asoundrc :

Edit : Pulseaudio ne sert à rien en fait....sauf poser des problèmes donc il a été supprimé.

pcm.!default { 
    type hw 
    card 1 
} 

ctl.!default { 
    type hw 
    card 1 
} 

Au démarrage de mon WM (i3), j'exécute pulseaudio comme suit :

exec pulseaudio --start

Et j'ai également cet init d'Alsa :

exec alsactl init -c 1

Mplayer

Pour pouvoir lire des vidéos avec mplayer2, voici la conf que j'ai écrite dans ~/.mplayer2/config

[default]
vo=x11
vc=ffh264vdpau,ffmpeg12vdpau,
zoom=1

Le Touchpad

Pour "activer" le middle click sur le touchpad, j'ai transpiré quelques heures. Encore une fois, le problème est simple (et la solution également) :

  • le touchpad n'a qu'un seul boutton
  • c'est la position du clique qui détermine si on fait un clique gauche, un clique droit ou bien le clique du mileu (middle click)

Synclient (en ligne de commande) permet de connaître les valeurs attribuées par Synaptics pour les paramètres du touchpad. Il s'avère que par défaut, le middle click a tout à 0, c'est à dire qu'aucune position de clique ne permet de détecter ce fameux clique.

Il suffit donc de modifier ces valeurs et tout devrait rentrer dans l'ordre. Voici ce que j'exécute au lancement du WM :

exec synclient MiddleButtonAreaLeft=2700
exec synclient MiddleButtonAreaRight=3500

Un bout de scotch pour repérer au touché cette position (entre les clique gauche et le clique droit) et l'affaire est bouclée.

Edit. Dans /etc/X11/xorg.conf (à créer si besoin) :

Section "InputClass"
    Identifier      "SynPS/2 Synaptics TouchPad"
      Driver          "synaptics"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Option          "SHMConfig"             "on"
    Option          "Emulate3Buttons"       "on"
EndSection

J'espère que ça pourra aider :)


[tips] Envoyer du mail depuis un post de développement

Le développement d'applications web nécessite souvent l'envoi d'emails, ne serait-ce que pour la gestion d'un espace membre par exemple. On a deux façons de voir les choses quand on est encore en phase de développement :

  • Utiliser un serveur de mail "fake" qui va délivrer une copie du mail si il avait été envoyé
  • Utiliser un vrai serveur d'envoi de mail

La première méthode est pas mal du tout, cependant il arrivera le moment où il faudra vraiment envoyer le mail, ne serait-ce que pour s'assurer qu'on n'est pas passé à côté de quelque chose (comme un problème lié aux clients mails). Ainsi, je suis assez partisant d'envoyer du vrai mail, même dans la phase de développement.

Pour se faire, deux nouvelles solutions s'offrent à nous :

  • Passer par un serveur de mail en local pour délivrer le mail
  • Passer par un relais SMTP pour délivrer le message

Dans le premier cas, vous avez 1 chance sur 100 que le message ne soit pas bloqué par les services anti-spam. Du coup, on va préférer passer un relais SMTP qui lui ne devrait pas poser de problème.

Pour se faire, on va installer un serveur de mail en local puis configurer un relais SMTP. Ça veut dire que le serveur de mail va faire office de client pour se connecter à un autre serveur de mail pour délivrer nos messages. Le principal intérêt de cette méthode est que quelque soit le programme qui enverra du mail en utilisant le serveur de mail "localhost" pourra faire transiter les messages vers le relais SMTP et les délivrer correctement.

Le seul pré-requis est d'avoir un relais SMTP sur lequel se connecter. En d'autres mots, vous devez avoir un prestataire d'envoie de mail qui n'est pas trop restrictif (donc pas Free par exemple) : OVH, Gandi, Gmail, …

Il faut déjà installer un serveur de mail sur sa machine. Je vous propose d'utiliser Postfix dont la renommée n'est pas à faire :

$ su - 
# aptitude update
# aptitude install postfix

Éditions à présent le fichier de conf (/etc/postfix/main.cf) :

[...]
myhostname = exemple.fr

relayhost = serveur.smtp.relais # exemple : mail.deblan.fr
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
[...]

Il est nécessaire de prévoir un fichier pour s'authentifier sur le serveur SMTP relais :

# touch /etc/postfix/sasl_passwd
# echo "serveur.smtp.relais login:password" > /etc/postfix/sasl_passwd

Modifiez le login et le password, si le login contient un "@", remplacez le par "#".

# postmap /etc/postfix/sasl_passwd (à faire à chaque modification du fichier)
# chown root:root /etc/postfix/sasl_passwd*
# chmod 600 /etc/postfix/sasl_passwd*
# service postfix restart

À présent, si le relais mail n'est pas bloquant et que les identifiants sont bons, vous passerez par un "vrai" serveur de mails pour délivrer les messages de votre espaces de développement (et pas que).

Si vous envoyez le mail au nom d'un domaine qui n'est pas celui du serveur de mail, il faudra prendre le temps de faire une configuration SPF pour rendre l'envoi de mail légitime depuis ce serveur relais. À titre d'exemple, j'ai deux serveurs de mails qui peuvent délivrer des messages avec comme domaine d'expédition "deblan.fr". Les ip's associées sont 5.135.190.125 et 109.190.159.83. Voici les entrées DNS que j'ai créées :

$ dig -t TXT deblan.fr
[...]
deblan.fr. 10739 IN TXT	"spf2.0/mfrom mx ip4:109.190.159.83 ip4:5.135.190.125 ~all"
deblan.fr. 10739 IN TXT	"v=spf1 ip4:109.190.159.83 ip4:5.135.190.125 ~all"
[...]

$ dig -t SPF deblan.fr
[...]
deblan.fr. 10739 IN	SPF	"spf2.0/mfrom mx ip4:109.190.159.83 ip4:5.135.190.125 ~all"
deblan.fr. 10739 IN	SPF	"v=spf1 ip4:109.190.159.83 ip4:5.135.190.125 ~all"
[...]

Si je fais un test de query SPF, voilà résultats :

$ spfquery -i 5.135.190.125 -s foo@deblan.fr | tail -n 1
Received-SPF: pass (spfquery: domain of deblan.fr designates 5.135.190.125 as permitted sender) client-ip=5.135.190.125; envelope-from=foo@deblan.fr;
'
$ spfquery -i 109.190.159.83 -s foo@deblan.fr | tail -n 1
Received-SPF: pass (spfquery: domain of deblan.fr designates 109.190.159.83 as permitted sender) client-ip=109.190.159.83; envelope-from=foo@deblan.fr;

$ spfquery -i 1.2.3.4 -s foo@deblan.fr | tail -n 1
Received-SPF: softfail (spfquery: transitioning domain of deblan.fr does not designate 1.2.3.4 as permitted sender) client-ip=1.2.3.4; envelope-from=foo@deblan.fr;

Les 2 ip's que je rend légitimes passent le test sans problème alors que le 3ème est en échec. Ce test SPF devient très important et par expérience, c'est la source de beaucoup de rejets. Si vous avez des IPV6, pensez à les déclarer, je me suis fais avoir il y a quelques jours encore :)

J'espère que ça vous sera utile :)


NeutralNetwork fusionne avec Chat-IRC

Depuis plusieurs semaines, NeutralNetwork et Chat-IRC travaillent main dans la main pour aujourd'hui avoir fusionnés. Les deux réseaux IRC sont à présent interconnectés et notre service devient plus en plus solide.

Ce rapprochement s'est fait tout naturellement de part nos idéologies communes et l'ambition de grandir. Ainsi est né NeutralIRC !

SE CONNECTER AU CHAT


Installer plusieurs versions de PHP sur un serveur web

Il arrive qu'il soit nécessaire d'installer des versions de PHP spécifiques pour des projets qu'on héberge. Le must du must est de passer par son gestionnaire de paquet mais ce n'est pas toujours possible. Il convient donc de récupérer le ou les versions nécessaires et de les compiler.

Une des problématiques réside dans la sécurisation du serveur web. Il est important de considérer que se passer de son gestionnaire de paquet est dangereux car on ne bénéficie pas des mises à jour de sécurité et qu'il est impératif de gérer les droits pour que les projets impactés s'exécutent avec des utilisateurs qui leur sont dédiés.

La procédure d'installation n'est pas compliquée mais ça demande d'être minutieux.

Pour gérer la récupération du code source et de sa compilation, j'aime beaucoup travailler avec PhpFarm. On va donc récupérer le projet et simplement balancer un peu de config.

Pour cet exemple, je veux d'installer PHP 5.4.28. L'ensemble des commandes est fait en root.

aptitude update
aptitude install git make
cd /usr/local
git clone git://git.code.sf.net/p/phpfarm/code phpfarm
cd phpfarm/src

Je vous propose de modifier les options de compilation afin d'avoir quelques outils souvent très utilisés. Il suffit d'éditer le fichier src/options.sh et d'éditer la liste des paramètres :

configoptions="\
--enable-bcmath \
--enable-calendar \
--enable-exif \
--enable-ftp \
--enable-mbstring \
--enable-pcntl \
--enable-soap \
--enable-sockets \
--enable-sqlite-utf8 \
--enable-wddx \
--enable-zip \
--with-openssl \
--with-zlib \
--with-gettext \
--enable-libxml \
--with-zlib \
--with-xsl \
--with-jpeg-dir \
--with-png-dir \
--with-gd \
--with-ttf \
--with-freetype-dir \
--with-pdo-mysql \
--with-mysql \
$gcov"

À présent, il suffit de demander à PhpFarm de télécharger et compiler notre version de PHP.

./compile.sh 5.4.28

Il manquera sans doute des lib de dev. Par exemple, s'il remonte une erreur concerant jpeg, faite une recherche du type aptitude search jpeg | grep dev et installez ce qui convient (le paquet libjpeg8-dev dans ce cas).

Une fois la compilation achevée, il faut configurer le serveur web (apache2 dans mon cas). Je rappel que je veux que mes projets aient un utilisateur dédié. Je vais faire une configuration similaire à celle-ci.

a2enmod actions suexec
mkdir -p /var/www/service-web/bin/cgi
echo /usr/local/phpfarm/inst/bin /var/www/service-web/bin/cgi none bind >> /etc/fstab
mount /usr/local/phpfarm/inst/bin

Si j'ai un projet "blog", mon utilisateur dédié sera "webblog". J'ai également un groupe "webgroup" pour tout mes projets.

addgroup webgroup
useradd -G webgroup -s /bin/false -M webblog
chown -R webblog:webgroup /chemin/vers/projet/blog
mkdir /var/www/service-web/bin/cgi/webblog
cd /var/www/service-web/bin/cgi/webblog
cat > php-cgi <<EOS
#!/bin/sh
exec /usr/local/phpfarm/inst/bin/php-cgi-5.4.28
EOS
chown -R webblog:webgroup .
chmod u+x php-cgi

Il manque plus que la modification du VirtualHost :

<VirtualHost *:80>
	[...]
	SuexecUserGroup webblog webgroup
	ScriptAlias /phpfarm-bin/ /var/www/service-web/bin/cgi/webblog/
	AddHandler application/x-httpd-php5 php
	Action application/x-httpd-php5 /phpfarm-bin/php-cgi
	[...]
</VirtualHost>

Faites une petite prière et relancez apache :

service apache2 restart

Comme je n'utilise que du FastCGI (ou des CGI), je ne sais pas comment la configuration réagit si PHP (en module apache) est activé.


Utiliser la console de débug sous Firefox mobile

La vue adaptative de Firefox est très intéressante mais je ne couvre pas tous les problèmes d'affichage d'un Firefox mobile. En effet, j'ai déjà rencontré des cas où Firefox mobile ne réagissait pas du tout pareil que sur la vue adaptative.

Il est possible d'utiliser la console de débug de votre Firefox PC pour inspecter votre Firefox mobile. Ça fonctionne à l'aide d'ADB. Ainsi, la première chose à faire est d'installer le SDK Android sur votre machine. Vous le trouverez ici et vous aurez simplement à décompresser l'archive quelque part.

Une fois le SDK disponible sur votre machine, activez le débogage USB sur votre terminal Android (Paramètre > Option de développement > Débogage USB). Branchez votre terminal sur votre machine et lancez Firefox mobile. Dans les paramètres, allez dans "Outils de développement" et cochez "Débogage distant".

Pour tester si l'Android est détecté, lancez cette commande :

$ /chemin/vers/sdk/platform-tools/adb devices

La sortie devrait ressembler à ça :

List of devices attached   
xxxxxxxxxxxxx	device

Ouvrez la console de débug et activez le débogage distant (à gauche de l'onglet "Console").

La dernière étape de configuration consiste à forwarder le port 6000 de votre machine vers le terminal Android :

$ /chemin/vers/sdk/platform-tools/adb forward tcp:6000 tcp:6000

En plus de message de confirmation d'ADB, on pourra s'assurer que ça fonctionne avec netstat :

$ netstat -nl | grep 6000
tcp        0      0 127.0.0.1:6000          0.0.0.0:*               LISTEN

Ouvrez une page sur votre Firefox mobile, puis, dans votre Firefox PC, allez dans Outils > Développeur Web > Se connecter. Une demande confirmation s'affichera sur votre terminal Android. Vous pouvez à présent débugger plus facilement vos sites web sur Firefox mobile :)