willoblog

Ah, enfin. Ça y est, hourra, depuis le temps que l’on attendait cela, c’est enfin possible : il est enfin possible avec Apache et OpenSSL d’héberger sur un même serveur plusieurs sites sécurisés avec chacun son certificat propre.

J’héberge sur mon serveur plusieurs sites. Deux en particulier ont besoin d’être sécurisés, non pas pour garantir qu’il s’agit de moi (je ne suis pas une banque, personne n’essaiera jamais de se faire passer pour moi), mais parce que ce qui y est écrit est personnel et que je suis un grand parano qui ne veux pas laisser d’accès à des personnes que je ne connais pas.
Comme je veux cependant garantir l’accès de mes sites au plus grand nombre, je cherche à éviter les affichages d’erreurs moches et incompréhensibles des problèmes de sécurité, qui deviennent particulièrement pénibles avec Firefox 3.5. Du coup, deux choses à faire :

• acheter des vrais certificats, du moins ne pas utiliser des certificats auto-signés. C’est tout à fait contre ma pratique et mes habitudes en informatique, mais il faut se rendre à l’évidence : tous les navigateurs font croire que l’on tombe chez des pirates quand le certificat est auto-signé. C’est très triste d’en arriver là. Néanmoins, ayant trouvé des certificats à pas cher, je me fournis maintenant chez RapidSSL pour des certificats que ne m’ont causé aucun problème.
• pouvoir séparer les noms de domaine sur mon serveur web.

Le deuxième point paraît simple. Il s’agit pourtant d’une grande impossibilité du chiffrement SSL tel qu’il été conçu à l’origine : le chiffrement est effectué sur l’adresse dès l’envoi de la requête par le navigateur, et le déchiffrement n’a lieu sur le serveur qu’après sélection du certificat pour déchiffrer… La sélection du certificat ne peut donc pas dépendre de l’adresse demandée.
Sous Ubuntu, une solution existait jusqu’à maintenant. Utiliser GnuTLS, qui comme son nom l’indique permet l’utilisation du protocole TLS, dernière évolution de SSL. Pourquoi ? Parce qu’avec TLS, il est possible de balancer en clair l’adresse grâce à l’extension appelée SNI. Problème de GnuTLS, c’est un peu instable et il arrive notamment en cas de requêtes multiples de se voir servi par un mauvais certificat : on retombe sur les messages d’erreur, encore plus dérangeant parce qu’incompréhensibles vu que ça fonctionnait une seconde avant…
Apache, le logiciel serveur, supportait le TLS, mais pas le SNI avec OpenSSL. C’était un bug connu, qui a été réparé début août, mais pour Ubuntu Karmic uniquement. Cette version est installée depuis quelques jours (tout juste avant sa sortie finale, soyons fous…) sur mon serveur, et cela marche comme un charme. Il suffit de mettre dans la configuration générale, par exemple /etc/apache2/ports.conf :

Listen 443
NameVirtualHost *:443

puis dans la configuration de chaque site :

<VirtualHost _default_:443>
  ServerName votredomaine.fr
  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/votrecertificat.crt
  SSLCertificateKeyFile /etc/apache2/ssl/laclécorrespondante.key
  ...
</VirtualHost>

À noter aussi l’existence d’un autre logiciel serveur, Lighttpd. Il a notamment l’avantage d’être plus léger qu’Apache. Je ne l’utilise pas sur mon serveur plus par inertie, parce qu’Apache est parfaitement configuré, mais je l’utilise sur mon portable pour avoir un serveur web de test avec moi, et je le trouve très bien et très réactif. Je pensais qu’il supportait SNI depuis quelques temps, mais visiblement ce n’est le cas que depuis 5 jours. Bref, le choix est ouvert, comme toujours dans le monde libre.

Firefox 3.5 est sorti il y a maintenant plus d'un mois. Il ne sera pas intégré dans Jaunty, la version actuelle d'Ubuntu, ni dans les précédentes. C'est normal, c'est une question de stabilité : aucun logiciel ne peut être intégré dans sa nouvelle version après le gel de la version de la distribution. Même Firefox, aussi important soit-il.

Mais il est pourtant possible d'obtenir Firefox 3.5. Rien de très compliqué, mais on pourra faire les choses de façon expéditive ou méticuleuse... Je vous propose la deuxième.

Avant de commencer, installons

On commence par installer Firefox, qui est disponible en dépôt pour Ubuntu Jaunty, si, si :

sudo aptitude install firefox-3.5 firefox-3.5-gnome-support

Firefox 3.5 est disponible par la commande firefox-3.5, alors que la commande firefox est liée à Firefox 3.0.

ls -l /usr/bin/firefox*
lrwxrwxrwx 1 root root 11 2009-08-04 09:07 /usr/bin/firefox -> firefox-3.0
lrwxrwxrwx 1 root root 32 2009-08-04 09:07 /usr/bin/firefox-3.0 -> ../lib/firefox-3.0.12/firefox.sh
lrwxrwxrwx 1 root root 31 2009-07-21 15:08 /usr/bin/firefox-3.5 -> ../lib/firefox-3.5.1/firefox.sh

Pour les plus vieilles versions d'Ubuntu, Firefox 3.5 n'est pas disponible en dépôt et il faut aller le chercher sur le site officiel, puis le décompresser par exemple dans /usr/local/src :

sudo mv firefox*tar.bz2 /usr/local/src
tar -xjvf /usr/local/src/firefox*tar.bz2

et l'utilitaire se trouve alors à /usr/local/src/firefox-3.5

La mauvaise méthode

Je vous vois venir : c'est facile, il suffit de lier la commande firefox au bon endroit

sudo rm /usr/bin/firefox && sudo ln -s firefox-3.5 /usr/bin/firefox

C'est la mauvaise méthode. Pourquoi ? Au moins deux raisons :

• Rien ne vous assure que le lien ne sera pas remis à la prochaine mise à jour de Firefox. Il a bien été mis là ce lien, il vient pas de nulle part.
• Vous allez peut-être regretter d'avoir bousillé votre profil Firefox (voir aussi les explications sur Geckozone). C'est ce qui arrive quand on ne fait pas attention.

Une bonne méthode

Il faut savoir que quand une commande est ordonnée (par vous très souvent), l'interpréteur (souvent bash) va chercher dans certains répertoires les uns après les autres. Ceci est réglé par la variable $PATH, que l'on peut voir dans une console :

echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

D'abord on cherche dans /usr/local/sbin, puis dans /usr/local/bin, puis... Donc si un firefox se trouve dans /usr/local/bin, celui de /usr/bin ne sera jamais lancé ! Et /usr/local/bin a comme grand avantage de ne pas être écrit par le système (d'où le « local », pour l'écriture locale de l'administrateur). Il suffit donc de faire :

sudo ln -s /usr/bin/firefox-3.5 /usr/local/bin/firefox

Et on pourra avoir Firefox 3.5 avec firefox ou Firefox 3.0 avec /usr/bin/firefox.

Mais la deuxième objection reste toujours valable...

La gestion des profils

Le mieux est de créer deux profils, parce que Firefox 3.5 peut ne pas fonctionner exactement comme la version précédente, et parce que les extensions elles aussi connaissent des versions différentes, compatibles ou non avec les différentes version de Firefox. Pour chaque utilisateur, vous pouvez avoir accès au Gestionnaire de profils par firefox -P. Alors vous pouvez créer ou supprimer un répertoire. Je suppose que celui utilisé jusqu'à maintenant (par Firefox 3.0) est default. Créez-en un nouveau, en le nommant par exemple F3-5 (le point serait gênant). Puis fermez.

Les profils Firefox peuvent être choisis au démarrage du logiciel de deux façons. Avec firefox -P, le Gestionnaire de profils permet ce choix en mode graphique. Avec firefox -P default ou firefox -P F3-5 dans notre cas, on peut choisir directement sans fenêtre supplémentaire le profil voulu.

Nous pouvons donc créer deux lanceurs, que l'on mettra par exemple dans /usr/local/bin/firefox-3.0 :

#!/bin/sh
 
/usr/bin/firefox3.0 -P default $* &

et dans /usr/local/bin/firefox-3.5 :

#!/bin/sh
 
/usr/bin/firefox-3.5 -P F3-5 $* &

Après un

sudo chmod +x /usr/local/bin/firefox*

les commandes firefox-3.0 et firefox-3.5 sont maintenant transformées : ainsi, elles ne peuvent plus lancer le mauvais profil... Il ne reste plus qu'à lier firefox à celle que l'on souhaite :

sudo ln -s firefox-3.5 /usr/local/bin/firefox

(supprimez /usr/local/bin/firefox si vous l'aviez créé précédemment).

On y est presque : derniers détails

Vous venez d'ouvrir Firefox 3.5, et vous vous rendez compte d'une chose abominable : l'interface est en anglais !
No problemo. Après avoir regardé le numéro exact de votre version dans le menu « Aide -> À propos de Mozilla Firefox » (du genre 3.5.x), il suffit d'installer par simple téléchargement l'extension qui va bien, que vous pourrez trouver sur le site de mozilla.org en choisissant là votre 3.5.x puis linux-i686 -> xpi -> fr.xpi. Elle ne s'installe que dans votre profil actuel, le F3-5 (on retrouve l'intérêt de ne pas avoir le même profil pour les deux versions).

Mais où sont passés tous vos mots de passe, vos historiques, vos entrées de formulaires, vos habitudes ?
Facile : fermez le Firefox ouvert, et copiez d'un profil à l'autre les fichiers qui vont bien :

cd ./mozilla/firefox/*.default
cp -a bookmarks.html cert8.db content-prefs.sqlite cookies.sqlite downloads.sqlite formhistory.sqlite key3.db signons3.txt urlclassifier3.sqlite urlclassifierkey3.txt ../*.F3-5

À noter que signons3.txt, contenant vos mots de passe, sera transformé en signons.sqlite désormais. Il restera les extensions à réinstaller, ce que vous pouvez éventuellement vous éviter en recopiant le répertoire extensions. Peut-être qu'il est intéressant de temps en temps de se demander de quelles extensions on a vraiment besoin (je vous conseille fortement Adblock Plus, Flashblock ; Firebug pour les développeurs et TabMixPlus pour ceux qui aiment bien avoir pas mal d'onglets ouverts).

Bon, troisième post de la journée sur le sujet, après les deux premiers. Petits trucs et astuces pour pouvoir afficher des scripts bash comme cela est réalisé sur mon site.

Pour le transcript, deux problèmes

Balises malgré elles

SyntaxHighlighter transforme tous les chevrons « < » et « > » en entités html correspondantes, respectivement « &lt; » (less than) et « &gt; » (greater than). Ce ne serait pas grave s'il ne le faisait pas seulement pour presque tous les chevrons... Or il cherche à détecter automatiquement les balises (ce qui n'est pas très malin dans du code bash d'ailleurs, ce qui fait que mon adresse mail par exemple était comprise comme une balise, dégradant quelque peu la suite de l'affichage. Total : il faut le faire pour lui.
Au départ, j'avais choisi d'utiliser readline en php, à savoir

<pre class="brush: bash">
<?PHP  @readline('compil'); ?>
</pre>

Mais transformer les chevrons à l'avance n'est pas beaucoup plus compliqué :

<pre class="brush: bash">
<?PHP  echo str_replace('<','&lt;',str_replace('>','&gt;',file_get_contents('compil'))); ?>
</pre>

Vous aurez remarqué que du coup, dès que le fichier est modifié, c'est le code de la dernière version qui s'affiche. Zéro maintenance (le fichier compil est un lien symbolique vers /usr/local/bin/compil sur mon serveur).

Décidément, ces chevrons...

Et c'est à ce moment que l'on relit un peu ce qui s'affiche à l'écran, et qu'on se rend compte que plein de chevrons (mais pas tous) sont restés à l'état d'entités html. Alors qu'en enlevant l'influence de SyntaxHighlighter, on obtient bien le résultat attendu. Il m'aura fallu quelques minutes pour me souvenir que lt et gt, sont des mots-clés en bash, justement pour des tests numériques plus grand/plus petit (ouais, tout est lié). Un grand dilemme se pose alors. Soit on laisse comme ça, et le code affiché est faux. Soit on s'arrange pour ne jamais avoir de chevrons (ce qui est impossible quand on a besoin de redirections). Soit on commente les mots-clés gt et lt dans le fichier de définition shBrushBash.js, et tant pis pour leurs rares apparences en tant que tests, où ils ne seront pas colorés comme il faut. J'ai choisi cette dernière solution.

Pour l'aide

Ah, là ça se corse. Au départ j'avais recopié telle quelle la réponse de compil -h. Je me suis dit alors « mais si t'as une coquille dans l'aide ou que tu la modifies, il faudra revenir ici... au secours ». Alors j'ai trouvé un moyen. Après plusieurs tâtonnements et hésitations sur la meilleure fonction php entre exec, system et passthru, j'ai opté pour

<pre class="aide">
$ compil -h
 
<?PHP 
exec('[ ! -e compil.help -o compil -nt compil.help ] && compil -h | tr -d "\033" | sed -e "s/\[1m/<b>/g" -e "s/\[0m/<\/b>/g" > compil.help');
@readfile('compil.help'); ?>
</pre>

Explication : la dernière commande lit et affiche un fichier compil.help. On va donc y mettre l'aide. Problème, j'utilise un formatage à base de caractères bizarres qui permettent de mettre en gras du texte en console. On prend donc le résultat de compil -h, on en vire donc le caractère bizarre (grâce à la commande tr -d), puis on identifie le début et la fin des mises en gras, que l'on remplace de façon moche mais fonctionnelle par des balises de formatage html.
Le début est un test, qui permet d'exécuter la commande seulement si compil.help n'existe pas ou est plus ancien que compil. Cela semble fonctionner à peu près correctement.

Ceux qui ont essayé le savent : il est a priori impossible d'utiliser une applet java dans la machine virtuelle java de Sun sur un ordi d'architecture AMD64 sous Ubuntu. Certes, d'autres implémentations de machines java, en particulier la prometteuse (si j'ai bien compris) et 100% libre OpenJDK, mais je préfère encore pour quelques temps utiliser la machine de chez Sun, en attendant que les derniers petits problèmes soient résolus. Il semble, par exemple, que la déclaration d'impôts (mon seul usage annuel d'usine à gaz java...) ne soit pas optimal par OpenJDK.

Non, au temps pour moi : il était impossible. C'est depuis quelques mois possible, sous Jaunty uniquement (sortie en avril dernier). La raison à ce problème : Sun n'avait pas cru bon de fabriquer un plugin de navigateur pour les architectures 64 bits.

Le problème, c'est que le paquet essentiel, sun-java6-plugin, n'est disponible dans les dépôts que pour Jaunty. Heureusement, des téméraires ont testé, et pas de problème, ça fonctionne. J'ai testé sous Hardy et sous Intrepid, ça a l'air de fonctionner.

Deux possibilités donc pour installer tout ça (sous Hardy ou Intrepid):

• télécharger les trois paquets, sun-java6-plugin, sun-java6-bin, sun-java6-jre et les mettre par exemple dans le répertoire /usr/local/src/. En une ligne (ah, la beauté de la ligne de commande...) :

adresse="http://fr.archive.ubuntu.com/ubuntu/pool/multiverse/s/sun-java6/";  for paquet in jre plugin bin; do fichier=`wget -q -O - $adresse | sed -n "/amd64\|all/s/.*\">\(sun-java6-$paquet.*.deb\)<.*/\1/p" | tail -n 1`; sudo wget -P /usr/local/src/ $adresse$fichier; done

Désinstaller les paquets éventuellement déjà installés

sudo aptitude purge icedtea-gcjwebplugin

Puis installer les paquets téléchargés

sudo dpkg -i /usr/local/bin/sun-java6-*

• utiliser un dépôt fait plus ou moins pour ça (trouvé à force de chercher, et je remercie la personne en question de m'avoir donné cette idée), le dépôt hardy de ce site. Il suffit alors, après modification de /etc/apt/sources.list, de mettre à jour

sudo aptitude update && sudo aptitude safe-upgrade

et d'installer le bon paquet

sudo aptitude install sun-java6-plugin

Et un redémarrage de firefox plus tard...

Edit : bon en fait pour la déclaration d'impôts, visiblement la signature par certificat ne fonctionne pas simplement. Par contre, la signature simplifiée fonctionne très bien, et du coup je ne suis pas allé voir plus loin...

Suite de mes découvertes latex du weekend : je me suis rendu compte que beaucoup de césures effectuées automatiquement par Latex étaient incorrectes. Après recherche, mon fichier de log contenait désespérément :
Package babel Warning: No hyphenation patterns were loaded for
(babel) the language `French'
(babel) I will use the patterns loaded for \language=0 instead.

Et cela, malgré toutes les options possibles et imaginables à babel, le package latex de traduction. L'erreur était en fait un peu plus haut dans le fichier de log :
Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, nohyphenation, loaded.
Il n'y a pas « french » ! La faute à un paquet Ubuntu qui n'est bizarrement pas installé automatiquement, texlive-lang-french.

Il suffisait donc de faire : sudo aptitude install texlive-lang-french. Et après, c'est gagné :
Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, nohyphenation, basque, french, loaded.

Pour Noël, j'ai eu un lecteur mp3 Samsung YP-P2. Il s'agit, comme présenté dans un très bon site dédié, d'un lecteur sorti fin 2007, dont l'interface est entièrement tactile, à l'instar de l'Ipod Touch. L'écran semble un peu moins « précis » que celui de l'Ipod, mais le comportement général est quand-même très agréable à utiliser.

Trois problèmes majeurs :

• l'utilisation obligatoire du logiciel Samsung
• le format propriétaire de la vidéo
• l'affichage des pochettes (ou cover) des albums

Tout écrire ici serait trop long et illisible. J'ai préféré détailler cela dans une page spéciale. Ce n'était en fait pas très compliqué de résoudre ces trois problèmes.

Nouvelle version d'Ubuntu sortie hier, nommée « 8.10 » (lire octobre 2008) ou « The Intrepid Ibex » (le bouquetin intrépide), alias intrepid.
Pas un très grand nombre de nouveautés, mais des trucs qu'on attendait depuis très longtemps :

• les onglets dans Nautilus, ah, enfin, ça va vraiment être génial ça !
• une session « invité » existante de base, et ça aussi ça change tout : plus besoin de se dire qu'il faut le faire sans en prendre le temps, puisque c'est dispo de suite.
• le chiffrement des données sur les disques plus facile
• un Network-manager qui gère plus de possibilités et permet d'avoir un ordinateur connecté avant d'être loggué (ce qui était le cas quand on utilisait l'ancienne méthode avec /etc/network/interfaces).
• la possibilité de démarrer simplement sur une clé usb, sur n'importe quel ordinateur... C'était déjà le cas avant ? J'avoue ne pas avoir suivi ce point...

Et pour l'essayer, toujours pareil : on peut http://www.ubuntu-fr.org/telechargement, ou http://doc.ubuntu-fr.org/migration_hardy_intrepid.

J'ai réinstallé récemment l'ordinateur qui me sert de télé/media center. J'ai un certain nombre de fichiers avi, que je regarde de temps en temps. Avant, je faisais ça avec, au choix, vlc, mplayer ou xine. Je me suis décidé à passer à Totem.

Pourquoi Totem ?

Bin simplement parce que c'est le logiciel par défaut de chez Gnome en fait, et donc le truc a priori le mieux intégré à mon environnement. Il est installé par défaut, il ne pause plus de problèmes de codecs comme j'ai toujours eu avant (et qui faisaient que je préférais l'éviter justement). Bref, pourquoi pas...
Autre avantage, il est plus rapide à se lancer que vlc, plus convivial que xine et... bon, ok, rien ne sera jamais mieux que mplayer. :)

Les codecs

Oui, tiens, précisons-le : il suffit d'installer le paquet ubuntu-restricted-extras, et il fait tout le reste... C'est pourtant simple, non ?

Problème : le lancement en plein écran

Moi ce que je veux, c'est juste d'ouvrir de façon systématique mes fichiers en double-cliquant dessus et que ça s'ouvre en plein écran. Je suis flemmard et je ne veux pas appuyer sur F après avoir ouvert le fichier. Avec tous les autres lecteurs, c'est une préférence à régler (dans un menu ou éventuellement un fichier de configuration).

Et là, on tombe sur un os. Impossible de trouver aucune configuration particulière, à part un .gconf/apps/totem/%gconf.xml inutilisable et un .gnome2/Totem/state.ini minimaliste. Le tout est visiblement mal documenté, ou du moins après avoir longtemps cherché je n'ai rien trouvé. Le menu des préférences bien sûr ne sert à rien.

Le man nous dit qu'il existe une option --fullscreen, mais uniquement pour Passer en plein écran une instance existante de Totem. Bon... Mal barrée cette histoire.

Et là, l'idée : créer un fichier /usr/local/bin/totem, qui sera systématiquement lancé à la place de l'original /usr/bin/totem, et y mettre ce qui va bien :

#!/bin/bash
 
[ "$TERM" != xterm ] && /usr/bin/totem $* || /usr/bin/totem "$*" &
sleep 1
/usr/bin/totem --fullscreen

Explications :

1. On lance /usr/bin/totem avec tous les arguments qu'on lui passe (en particulier, les noms de fichiers). Il faut échapper les noms si on lance totem en console, c'est pour ça que c'est un poil compliqué.
2. On attend une seconde, le temps que totem ait démarré. Sur une machine qui met un peu plus de temps, il faut rallonger...
3. On passe en plein écran.

C'est améliorable, je prends toute idée utile...

Edit 10 jours plus tard : J'avais oublié qu'il y a deux façon de prendre tous les arguments d'un script : "$*" concatène tout le monde entre des guillemets, on ne voit plus qu'un «mot»; "$@" met chaque argument entre des guillemets et les sépare par une espace, on voit le bon nombre de «mots». Il suffit donc de faire :

#!/bin/bash
 
/usr/bin/totem "$@" &
sleep 1
/usr/bin/totem --fullscreen

J’ai acheté un nouveau portable pour Noël (pas pour moi, pour Amélie en fait). Il s’agit d’un ultraportable. Le choix est restreint sur ce segment, sachant qu’on voulait un portable à la fois léger (2kg max) et puissant (processeur Intel Core 2 Duo T7100 minimum), et le tout sans mettre plus de 1300€.

Juste pour le garder à l'esprit, ça pourrait servir (piqué sur le blog de Damocles, en licence CC-ASA) :

Ça peut toujours servir. Au passage, ceux qui n'étaient pas au courant noteront combien il est facile de taper des accents sous Linux...