Humus numericus - Linux, Debian, etc.

Canal IRC francophone dédié à R

Juba — Mon, 21 Jul 2008 10:39:00 +0200

R est un langage libre de traitement de données et d'analyses statistiques. Il est extrêmement puissant, son développement est très actif, mais son apprentissage n'est pas forcément des plus aisés, en partie à cause du manque de ressources en français.

Un des modes de support en anglais qui marche plutôt bien est le canal IRC #R, sur le réseau freenode. Plusieurs habitués francophones de #R (bon d'accord, deux habitués francophones de #R), dont je fais partie, ont lancé récemment un canal baptisé #Rfr, toujours sur freenode, pour tenter d'apporter le même genre de service en français.

Si vous souhaitez nous rejoindre, pointez votre client IRC préféré vers le serveur irc.freenode.net, canal #Rfr. Vous pouvez aussi y accéder via une interface web à l'une des adresses suivantes :

Pour l'instant le canal est assez calme, la seule activité réelle est celle du bot de traduction automatique de #R. Mais si vous avez une question au sujet de R, n'hésitez pas à venir la poser, et à être patient pour la réponse...

Plugin Rbot de traduction automatique de canal IRC

Juba — Mon, 21 Jul 2008 10:10:00 +0200

Rbot est un bot IRC écrit en Ruby que j'ai découvert récemment et qui s'avère très agréable à utiliser et à programmer.

J'ai créé, avec l'aide de pingou, un plugin permettant de traduire automatiquement un canal IRC : le bot récupère tous les messages publics postés sur un canal, les traduit via l'API de Google translate, et poste le résultat dans un deuxième canal. Il est actuellement utilisé pour traduire le contenu du canal #R de l'anglais vers le français (dans #Rfr) mais aussi le norvégien (dans #Rno). Je ne vous cache pas que le résultat de la traduction peut être assez fantaisiste.

Le plugin AutoTranslate peut être téléchargé depuis le dépôt des plugins non-officiels de Rbot.. Pour l'installer, il suffit de le copier dans le dossier plugins, puis d'éditer le fichier et de modifier le tableau TRANSLATIONS comme désiré.

Problème avec VirtualBox

Juba — Wed, 14 May 2008 17:54:00 +0200

VirtualBox est une application de virtualisation qui peut servir, entre mille autres choses, à faire tourner un windows à l'intérieur d'un linux.

Après la mise à jour de ma Debian unstable effectuée ce matin, plus moyen de démarrer l'appli. J'avais un pop-up d'erreur me signalant une impossibilité de démarrer les services COM, et en cas de lancement de la commande VirtualBox en ligne de commande, j'obtenais le joli message suivant :

/usr/lib/virtualbox//VBoxSVC: symbol lookup error: /usr/lib/virtualbox/VBoxXML.so: undefined symbol: _ZN11xalanc_1_1016XalanTransformer10initializeERN11xercesc_2_713MemoryManagerE

La solution ? Récupérer la dernière version (la 1.6) depuis le site de Virtual Box. Apparemment leurs dépôts Debian sont un peu en retard, d'ailleurs le lien de téléchargement renvoit sur le site de Sun, je ne savais pas qu'ils avaient été rachetés...

En tous cas l'installation du .deb pour Debian 4.0 a résolu le problème en ce qui me concerne.

Générer un certificat SSL auto-signé pour Apache

Juba — Wed, 14 May 2008 11:27:00 +0200

D'abord on génère une clé non chiffrée sur disque (pour éviter d'avoir à saisir un mot de passe à chaque redémarrage d'Apache) :

# openssl genrsa -out mykey.key 1024

Ensuite on crée un certificat signé avec cette clé :

# openssl req -new -x509 -days 365 -key mykey.key -out mycert.crt

Répondre à l'ensemble des questions posées. Le nom de la machine doit être donné en réponse à Common Name. On peut utiliser un wildcard (joker) du type *.example.com pour que le certificat s'applique à un ensemble de sous-domaines.

Ensuite, dans Apache, modifier le fichier de définition du VirtualHost qui va bien :

NameVirtualHost *:443
<VirtualHost *:443>

        SSLEngine on
        SSLCertificateFile    /etc/ssl/mycert.crt
        SSLCertificateKeyFile /etc/ssl/mykey.key
        SSLVerifyClient none

        [etc., etc.]

</VirtualHost>

Imprimer des calendriers en ligne de commande

Juba — Wed, 14 May 2008 10:18:00 +0200

Il existe un petit utilitaire en ligne de commande, nomé pcal, qui permet la génération et l'impression de calendriers avec de multiples options.

Pour l'installation, c'est comme d'hab :

# apt-get install pcal

Pour avoir une idée de toutes les options, c'est aussi comme d'hab :

$ man pcal

Petit exemple d'utilisation : la commande qui suit génère un fichier postscript des 6 mois suivant mai 2008, en format portrait, pour un papier A4, avec les semaines commençant le lundi, en français, et en ajoutant des calendriers miniatures des mois précédents et suivants.

$ pcal -l -P a4 -F 1 -a fr -K -o /tmp/cal.ps 05 2008 6

Le tout est placé dans un fichier postscript /tmp/cal.ps que l'on peut visualiser avec gv ou evince et imprimer avec xpp, lp, gtklp, etc.

Ras le bol des grosses configs

Juba — Wed, 12 Dec 2007 00:35:00 +0100

Je suis tombé sur un article via digg qui s'extasie du fait que KDE4 tourne correctement dans une machine virtuelle simulant un PC avec un proc à 1GHz et 256Mo de RAM. Et dans les commentaires sur digg on a droit à de jolis c'est chouette de penser aux vieilles machines, c'est bien pour les pays du Tiers-Monde ou encore on a du mal à croire qu'avant on travaillait sur des machines comme ça... Bon, d'accord, c'est sur Digg, mais ça a quand même le don de m'énerver...

A la maison nous avons deux machines. La première est un PC de bureau acheté d'occaze il y'a cinq ans : un magnifique Pentium 3 600 MHz avec 256Mo de RAM et une carte graphique Geforce4 64Mo. La deuxième est un portable également acheté d'occaze il y a deux ans, un rutilant Pentium 3 700MHz avec lui aussi 256 Mo de RAM.

Sur la machine de bureau, l'interface est un Xfce avec Compiz fusion. Et ça tourne nickel chrome, même le cube, le zoom interactif, les effets d'animation, etc.. Un Gnome ou un KDE tourneraient très bien aussi, mais en bouffant inutilement de la mémoire alors qu'il y en a quand même pas bézef. Niveau logiciel, même Firefox fonctionne bien, alors que c'est pas du léger. Gimp, Digikam, Videolan, ne posent aucun problème, et même OpenOffice se lance alors qu'il faut quand même bien admettre que c'est une bouse. Google Earth, Second Life et certains jeux en 3D tournent aussi, même si les performances ne sont pas hallucinantes.

Sur le portable, j'ai un bon vieux dwm avec un non moins bon vieil emacs, donc ça tourne évidemment très bien. Le portable en question n'avait que 128Mo de RAM il y a encore quelques semaines : là, Firefox commence à faire souffrir l'utilisateur, mais par contre Epiphany fonctionne très bien. Certes, ça swappait assez rapidement, mais une petite barette de 128Mo supplémentaire achetée d'occasion a résolu le problème sans difficulté. Et je n'ai évidemment aucun souci pour produire des documents avec TeX, développer une appli web en faisant tourner un Apache et un MySql, ou même pour faire des stats avec R si les données sont pas trop volumineuses.

Voilà, tout ça pour dire que pour un usage courant, on n'a certainement pas besoin d'un PC dernier cri dont les trois quart des ressources sont bouffées par des services inutiles. On peut travailler avec un bureau en 3D, des fenêtres ramollo et les dernières versions des derniers logiciels avec un Pentium 3 et 256Mo de RAM.

Et encore heureux, d'ailleurs...

Script shell de transfert de photos

Juba — Thu, 06 Dec 2007 00:14:00 +0100

Pas sûr que ça en vaille la peine, mais je me permets quand même de mettre en ligne le petit script bash que j'utilise pour transférer les photos depuis mon appareil numérique vers mon PC. Le script en question part du principe que l'appareil est reconnu comme un périphérique de stockage de masse USB et qu'il est automatiquement monté au point de montage indiqué par la variable mount_point. Il faut également renseigner les variable source_dir (chemin vers le répertoire dans lequel se trouve les photos à partir du point de montage) et cible_dir (emplacement des photos sur le PC). Vous aurez également besoin du paquet libjpeg-progs pour avoir la commande exifautotran.

Une fois que vous avez tout ça, vous aurez juste à brancher votre appareil et à lancer le script. Celui-ci s'occupera de monter le périphérique, de copier chaque image dans un répertoire nommé selon la date de prise de la photo (au format /home/photos/2007/12 par exemple) et d'effectuer une rotation en fonction de l'orientation horizontale ou verticale contenue dans les données EXIF.

#!/bin/sh                                                           
                                                                    
mount_point=/mnt/photo
source_dir=dcim/100km028 
cible_dir=/home/photos

mount $mount_point
for i in $mount_point/$source_dir/*.jpg; do  
        img=`basename $i`
        annee=`stat -c %y $i | cut -d '-' -f 1`
        mois=`stat -c %y $i | cut -d '-' -f 2`
        cible=$cible_dir/$annee/$mois
        if [ ! -d $cible ];
        then
                mkdir -p $cible
        fi      
        echo "Copie de $i vers $cible/$img"
        cp -i $i $cible/$img
        exifautotran $cible/$img
done;   
sleep 2s
umount $mount_point

Comme d'hab en ces lieux, vous constaterez que c'est du vite fait !

Passage à Dotclear 2.0

Juba — Thu, 10 May 2007 14:11:00 +0200

Après quelques hésitations, je me suis finalement décidé à migrer ce blog sous Dotclear 2 (version beta 6 pour être précis). Et comme il me fallait du PHP5, j'en ai aussi profité pour le changer de serveur et le transférer de L'autre net vers mon serveur dédié.

Du coup j'ai modifié un peu le thème, j'ai rajouté une redirection des anciennes URLs vers les nouvelles, etc. J'espère que tout fonctionnera correctement, en attendant y'aura forcément une période de rodage.

Voici quelques ressources utilisées pour effectuer la migration :

Et en exclusivité je vous livre mon .htaccess qui permet de rediriger les anciennes URLs et de supprimer la mention index.php dans les adresses du site en PATH_INFO. Attention, ce fichier n'a pas encore été complètement testé, à utiliser avec des pincettes :

RewriteEngine On
RewriteBase /

# URLs à ne pas rediriger
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/(cgi-bin|error|icons|robots.txt|favicon.*|\?.*|.*\?$|404|rss.php|atom.php)

# Suppression de l'index.php
RewriteRule (.*) index.php/$1
RewriteRule ^index.php$  index.php/

# Pour les redirections des flux RSS/Atom des categories
RewriteCond %{QUERY_STRING} ^cat=([A-Z][A-Za-z0-9_-]*)$
RewriteRule ^rss.php /feed/category/%1/rss2 [R=301]
RewriteCond %{QUERY_STRING} ^cat=([A-Z][A-Za-z0-9_-]*)$
RewriteRule ^atom.php /feed/category/%1/atom [R=301]

# Pour les redirections des flux RSS/Atom generaux
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^rss.php /feed/rss2 [R=301]
RewriteCond %{QUERY_STRING} ^type=co$
RewriteRule ^rss.php /feed/rss2/comments [R=301]
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^atom.php /feed/atom [R=301]
RewriteCond %{QUERY_STRING} ^type=co$
RewriteRule ^atom.php /feed/atom/comments [R=301]

# Redirection des anciens modes 

# Billet : ?YYYY/MM/DD/##*
RewriteCond %{QUERY_STRING} ^(\d{4})/(\d{2})/(\d{2})/(\d+.+)$
RewriteRule ^.*$ /post/%1/%2/%3/%4? [R=301]

# Categorie : ?Nom-categorie
RewriteCond %{QUERY_STRING} ^([A-Z][A-Za-z0-9_-]*)$
RewriteRule ^.*$ /category/%1? [R=301]

# Archives : ?YYYY/MM
RewriteCond %{QUERY_STRING} ^(\d{4})/(\d{2})$
RewriteRule ^.*$ /archive/%1/%2? [R=301]

Utiliser Gimp avec Ion3

Juba — Tue, 30 Jan 2007 15:00:19 +0000

Suite à la rédaction du document Introduction à Ion3, qui est, je le rappelle, un window manager totalement minimaliste mais diablement efficace, j'avais eu une petite controverse avec l'un des lecteurs du tutoriel pour savoir si Ion était adapté ou non à l'utilisation de Gimp. Le bougre en a même fait un article sur son blog.

Et ben il a fini par me convaincre. Une configuration semblable à celle qu'il présente est particulièrement pratique. Voici un petit guide pas à pas pour en mettre une en place.

Première chose à faire : créer un nouveau workspace. Pour cela, il vous suffit normalement de faire F9 et d'indiquer son nom : nous le nommerons ici gimpws. Par défaut, Ion crée un espace avec deux colonnes égales. Celle de gauche servira à la boîte à outils, celle de droite aux images. Vous pouvez modifier la taille respective des colonnes en utilisant Mod + bouton droit (remplacez Mod par la touche de votre config. Vous pouvez même rendre le cadre d'image flottant à gauche pour lui permettre de chevaucher la boîte à outils (clic droit sur le titre du frame, Tiling, Float split, at left.

Ensuite, nous allons donner un nom à ces frames pour les identifier. Sélectionnez celui de gauche, et tapez Mod + F3. A l'invite Lua code qui s'affiche, tapez la commande suivante :

mod_query.query_renameframe(_)

Ion vous demandez d'entrer le nom du frame : appelons-le gimptoolbox. Procédez de même avec le frame de droite et nommez-le gimpimage. La configuration de nos frames est terminée.

Reste à indiquer à Ion où afficher quoi. Nous allons le faire en utilisant des winprops, c'est à dire en rajoutant les lignes suivantes à la fin de notre fichier de configuration préféré (en général soit ~/.ion3/cfg_ion.lua, soit ~/.ion3/cfg_user.lua :

defwinprop {
  class="Gimp",
  role="gimp-startup",       
  target="gimpimage",
}
 
defwinprop {
  class="Gimp",
  role="gimp-tip-of-the-day",
  target="gimpimage",  
}

defwinprop {
   class="Gimp",
   role="gimp-image-window",
   target="gimpimage",
 }

defwinprop {
  class="Gimp",
  role="gimp-toolbox", 
  target="gimptoolbox",
}

defwinprop {
  class="Gimp",
  target="gimpws",
  float="true",
}

Que signifie tout ceci ? D'abord, on indique à Ion d'afficher la boîte de démarrage, l'astuce du jour et les images dans le frame nommé gimpimage. Ensuite, on lui dit de placer la boîte à outils dans le frame appelé gimptoolbox. Enfin, on lui dit d'afficher toutes les autres fenêtres de Gimp sous forme de fenêtres flottantes (utile pour tous les dialogues de config, de filtres ou d'effets).

Ainsi, lorsque vous lancez Gimp, vous pouvez le faire depuis n'importe où, vous serez sûr de le retrouver dans le workspace que vous venez de créer sans avoir à subir les barres de progression de chargement. Ensuite, vous disposez d'un grand espace pour visualiser et travailler sur l'image, et vous pouvez basculer l'image en plein écran avec un simple Mod + Return. Les fenêtres de config et d'outils s'affichent en flottant, ce qui permet de les déplacer pour ne pas masquer l'image. Et enfin, dernier avantage à mon avis, lorsque vous effectuez une capture d'écran d'une autre fenêtre depuis Gimp, celle-ci va automatiquement se placer dans le bon frame.

Automatiser les mises à jour de sécurité sous Debian

Juba — Fri, 12 Jan 2007 22:10:16 +0000

Tout utilisateur de Debian qui se respecte connaît les dépôts de paquets spécialement conçus pour colmater les failles de sécurité. Dès qu'un problème est identifié, l'équipe de sécurité applique les correctifs existants et met tout ça à disposition le plus vite possible. Nous allons voir ici comment faire en sorte que ces mises à jour soient appliquées automatiquement, par exemple une fois par jour.

La première chose à faire est d'installer le paquet cron-apt, qui est spécialement fait pour ça :

# apt-get install cron-apt

Ce paquet permet de lancer une mise à jour à intervalle régulier. Le problème est que nous ne voulons mettre à jour que les paquets concernés par les problèmes de sécurité, et pas l'ensemble de notre distribution. Ceci est particulièrement important si on utilise une distribution testing ou unstable. Pour cela nous allons créer une source de paquets restreinte aux dépôts de sécurité. On va donc éditer un fichier /etc/apt/security.sources.list contenant la ligne suivante :

deb http://security.debian.org/ testing/updates main contrib non-free

(remplacez testing par stable ou unstable selon votre config)

Il faut ensuite indiquer à cron-apt d'utiliser ce fichier. Pour cela, ouvrez le fichier /etc/cron-apt/config et ajoutez ou décommentez la ligne suivante :

OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list"

Et voilou. Il nous reste à régler la fréquence et le moment des mises à jour. Par défaut elles ont lieu une fois par jour à 4h du matin (cf le fichier /etc/cron.d/cron-apt). Ceci est très bien si vous avez un serveur qui tourne en permanence. Mais pour une machine de bureau, on pourra plutôt utiliser anacron et faire un lien sympolique vers /usr/sbin/cron-apt dans /etc/cron.daily :

# ln -s /usr/sbin/cron-apt /etc/cron.daily/cron-apt

Gérer ses DNS soi-même avec Xname

Juba — Thu, 11 Jan 2007 11:27:46 +0000

Suite à ma migration vers Site5, je me suis retrouvé avec quelques soucis au niveau de la gestion des DNS de mon domaine. L'hébergeur principal de nozav.org, c'est à dire L'autre net, propose une gestion des DNS tout à fait suffisante pour l'usage que j'en avais jusqu'à présent, mais un peu limite pour pouvoir partager un domaine en deux et en héberger des bouts chez un hébergeur et des bouts chez un autre.

J'ai donc testé les services de gestion de DNS de Xname.org. C'est un service gratuit, basé en France, qui fournit des serveurs DNS primaire et secondaire pour ses domaines, et qui permet d'éditer sa zone comme on le souhaite. Il faut s'y connaître un minimum, c'est à dire savoir au moins ce que sont des enregistrements NS, A, CNAME ou MX, mais ensuite c'est très simple à utiliser, et les enregistrements sont mis à jour une fois par heure. Et pour les experts, il y a même une interface avancée qui permet de gérer des paramètres tels que les TTL et autres joyeusetés.

Du coup, j'ai pu faire des choses un peu tarabiscotées, comme par exemple :

Héberger mon domaine nozav.org et certains sous-domaines comme blog.nozav.org sur L'autre
Gérer les mails du domaine nozav.org sur L'autre
Héberger d'autres sous-domaines comme dev.nozav.org sur Site5
Gérer les mails de certains sous-domaines sur Site5

Et tout ça en même temps, bien sûr.

Hébergement pour Ruby on Rails : essai avec Site5

Juba — Thu, 28 Dec 2006 23:40:10 +0000

Dans un précédent billet, j'avais fait une rapide comparaison entre quelques hébergeurs supportant Ruby on Rails. J'avais dans un premier temps choisi Dreamhost, dont les offres sont pour le moins alléchantes. J'avais finalement abandonné, d'une part car cela ne correspondait plus à mes besoins, mais aussi car en termes de performance ça me semblait un peu poussif, au moins depuis l'Europe.

Je viens de retenter le coup mais cette fois avec un autre hébergeur, en l'occurrence Site5. Les avis semblent partagés, mais j'en suis pour l'instant satisfait. Ils proposent une promo spectaculaire en ce moment, mais qui oblige à payer pour deux ans d'un coup, ce qui ne me convient pas, j'ai donc opté pour un plan de base avec paiement mensuel qui me revient à environ 8,50 euros par mois. Pour ce prix là vous avez : 10Go de stockage, 200Go de trafic, PHP, Perl, Python, Ruby on Rails via Apache/FastCGI, Accès SSH, Cron jobs, mails, bases de données, Subversion, etc. Pour le peu que j'en ai vu les performances m'ont l'air tout à fait honorables, j'ai d'ailleurs migré dev.nozav.org dessus il y a quelques temps, et ça tourne très bien.

Inconvénients

Pour l'instant, la seule limitation qui me saute aux yeux concerne l'hébergement des domaines. Avec le plan de base, vous ne pouvez héberger qu'un seul domaine (vous devez en héberger un d'ailleurs, il n'y a pas de sous-domaine machin.site5.com). Ça n'est qu'avec les plans plus onéreux qu'on accède aux domain pointers qui permettent d'en utiliser plusieurs. En ce qui me concerne ce n'est pas trop gênant pour le moment, l'hébergeur principal de mon domaine nozav.org me permettant de faire pointer des sous-domaines vers une adresse IP.

Avantages

Un des gros plus de l'offre de Site5 est le fait que chaque site hébergé se voit assigner une adresse IP unique. Ceci est très pratique pour un tas de choses, et notamment pour gérer l'hébergement de sous-domaines. Autres avantages, l'installation de base est assez claire, avec un home qui contient deux répertoires, public_html pour les sites web et public_ftp pour utiliser un serveur FTP déjà installé à la base. Par ailleurs, leur système d'administration est bien foutu, clair et visiblement écrit en Rails.

Mise à jour (7 janvier 2007)

Après plusieurs semaines, mon point de vue est toujours positif. J'ai migré dev.nozav.org, c'est à dire un site statique en HTML, mais aussi une petite application en Rails, et les performances sont tout à fait convenables, en tous cas bien meilleures que ce que j'avais expérimenté avec Dreamhost. Par ailleurs, le service de support est très performant (pourvu qu'on parle anglais, bien sûr) : en l'espace de deux heures, j'ai pu échanger trois ou quatre mails avec eux, et ils ont très rapidement modifier la config du serveur pour que je puisse déléguer la gestion des mails de mon domaine à un autre serveur tout en conservant la possibilité de comptes mails pour des sous-domaines (ce qui n'est pas trivial trivial comme demande).

Bref, pour l'instant je vous conseille cet hébergeur. Si vous souhaitez l'essayer, il y a toujours la garantie de 60 jours qui permet un remboursement intégral si vous n'êtes pas satisfaits.

Nouvelle mise à jour (20 janvier 2007)

Bon, comme je ne tiens pas en place niveau hébergement en ce moment, je viens à l'instant même de clôturer mon compte chez Site5. Non pas que je sois mécontent de leurs services, bien au contraire. Tout ce qui a été dit précédemment reste vrai à cette date : rapidité, fiabilité, support compétent, etc. Et ils m'ont bien reversé l'intégralité des sommes que je leur ai payé jusque là sans aucun problème puisque j'ai résilié mon compte avant 60 jours d'utilisation.

Si je change, c'est pour passer carrément sur un Virtual private server chez Tektonic. C'est un poil plus cher, y'a aucun support et faut tout faire soi-même. Par contre c'est totale liberté : on se retrouve avec l'équivalent d'un serveur dédié rien qu'à soi, et ce pour 15 dollars par mois, et on peut faire ce qu'on veut, y compris tout casser. J'essaierai de détailler davantage d'ici quelques temps.

Comparaison d'un script simple en Perl, Python et Ruby

Juba — Thu, 24 Aug 2006 01:03:16 +0000

Tiens, suite à une question d'un collègue de boulot aujourd'hui, je me suis amusé à comparer la manière de faire une tâche assez simple dans trois langages de script différents. L'objectif est d'afficher le chemin complet de tous les répertoires contenus (récursivement) dans un répertoire donné (en l'occurrence /var/log). Je trouve le résultat assez représentatif des particularités des différents langages :

En Python

import os
from os.path import join
for root, dirs, files in os.walk('/var/log'):
    for name in dirs:
        print join(root, name)

C'est pas forcément super intuitif (faut comprendre que la fonction os.walk renvoit un tuple avec le répertoire racine, les répertoires contenus et les fichiers contenus de chaque sous-répertoire parcouru. Mais c'est assez efficace.

En Perl

use File::Find;
find sub { print $File::Find::name, "
" if -d } , '/var/log';

Ah bah c'est sûr, difficile de faire plus bref. Mais c'est pas forcément évident du premier coup d'oeil, entre l'utilisation d'une référence à une fonction en argument de find, ou celui du test -d.

En Ruby

require 'find'
Find.find('/var/log') { |path| puts path if File.directory?(path) }

Et voilà. Simple, lisible, compact, compréhensible (du moins si on a compris le concept de bloc et d'itérateur). En un mot : é-lé-gant.

Bon, allez, je suis pas tout à fait objectif, je vous l'accorde...

Boîtes aux lettres corrompues par Procmail

Juba — Fri, 18 Aug 2006 22:45:11 +0000

Il y a visiblement un petit problème récurrent avec procmail, l'outil de tri de courrier électronique sous Linux, que la plupart des gens utilisent sans forcément le savoir. J'avais déjà rencontré le souci il y a pas mal de temps, ça s'était réglé, et finalement c'est revenu.

Le problème vient du fait qu'à certains moments, les fichiers stockant les messages reçus, du type /var/mail/user, sont corrompus car ils commencent par rom au lieu du traditionnel et attendu From. Du coup, plus moyen d'accéder aux messages situés à l'intérieur.

La solution est facile à trouver avec un minimum de googling, mais je la mets ici pour m'en souvenir : il suffit de rajouter le code suivant à la fin de votre fichier procmailrc (en général, ~/.procmailrc).

:0
* ^^rom 
{
 LOG="*** Dropped F off From_ header! Fixing up. "

 :0 fhw
 | sed -e '1s/^/F/'

}

Petite astuce pour le sélecteur de fichiers de Gnome

Juba — Fri, 07 Jul 2006 13:34:05 +0000

Je ne sais pas si vous êtes du même avis, mais j'ai personnellement du mal avec l'actuel sélecteur de fichier de Gnome, qui sert entre autres pour toutes les fonctions relatives au file system de Firefox. Ce qui est le plus gênant est surtout l'impossibilité à première vue de pouvoir rentrer directement le nom du fichier au clavier, par auto-complétion ou par copier-coller.

Et ben en fait c'est possible. Il suffit de faire un petit Control + L et un champ texte s'ouvre devans vos petit yeux émerveillés, champ dans lequel vous pouvez saisir le nom du fichier, avec en prime une autocomplétion digne de la ligne de commande. Si c'est pas du bonheur...

Installation du client Cisco VPN avec un noyau 2.6.16

Juba — Mon, 19 Jun 2006 10:51:46 +0000

Je viens de me rendre compte que mon client VPN Cisco ne fonctionnait plus au boulot depuis mon passage au noyau linux 2.6.16.18. Après un peu de Googling, voici les deux opérations à effectuer pour que ça tourne :

Problème de compilation

Pour régler l'erreur apparaissant à la compilation du module, il faut éditer le fichier linuxcniapi.c et remplacer toutes les occurrences de skb->stamp en skb->tstamp.

Problème à l'initialisation

Une fois le module compilé et chargé, je n'arrivais plus à lancer le VPN et me retrouvais avec le message d'erreur suivant :

privsep: unable to drop privileges: group set failed.

La solution est assez simple : un petit chmod 4111 /opt/cisco-vpnclient/bin/cvpnd et ça roule.

Je préfèrerais utiliser un client libre comme vpnc, mais il ne fonctionne pas avec notre super installation de la mort qui tue du boulot. Bref.

Hébergeurs alternatifs

Juba — Tue, 18 Apr 2006 00:01:15 +0000

L'hébergement de sites web et d'autres services liés à l'Internet (mails, domaines, listes...) constitue un marché plutôt ouvert sur lequel se trouvent des offres très différentes, d'autant plus si l'on considère que les frontières ne sont pas franchement un obstacle (héberger un site aux Etats-unis ou en Inde est presque aussi simple que le faire en Poitou-Charentes). On peut donc trouver :

de très nombreuses offres commerciales très difficiles à départager en termes de fonctionnalités, prix, support, espaces de stockage ou volume de trafic ;
des hébergeurs gratuits, mais souvent au prix de fonctionnalités limitées (pas de noms de domaines) ou de contraintes insupportables (pub) ;
des hébergeurs spécialisés, notamment ouverts seulement à des associations à but non lucratifs.

On trouve également un certain nombre d'hébergeurs "alternatifs", qui se situent plus ou moins en dehors des circuits commerciaux classiques et qui gagnent souvent à être connus. Voici un rapide descriptif de trois d'entre eux (la liste n'est certainement pas exhaustive), que je connais plutôt bien puisque je les utilise pas plus tard qu'actuellement.

Ouvaton

Ouvaton est un hébergeur coopératif. Ceci signifie qu'il fonctionne avec des AG et ce genre de choses, et qu'à l'inscription vous aurez à souscrire une ou plusieurs parts sociales de la coopérative. Ouvaton me semble avant tout intéressant pour des sites de petite taille et avec un trafic peu important, faute de quoi l'hébergement peut vite devenir onéreux. Le principe de tarification est celui de "briques de base", qui correspondent chacune à 20Mo d'espace disque et à 600Mo de trafic mensuel pour un coût annuel de 12 euros par an. Pour ce prix-là vous avez de la gestion de domaines et de mails, du PHP, une base MySQL, et des listes de discussion rudimentaires. D'expérience, les problèmes techniques sont assez rares (sauf quand RedBus tombe en rade, bien sûr), et le support plutôt réactif. L'implication possible dans la vie de la structure se fait surtout à travers les AG ou la participation à des sites de documentation et d'échanges.

En deux mots, Ouvaton me semble intéressant pour un site de petite taille ne nécessitant qu'une ou deux briques d'hébergement. Au-delà, on peut trouver des offres plus intéressantes.

L'autre net

L'autre net est un hébergeur autogéré. Il s'agit à la base d'une association, qui essaie d'appliquer le principe de l'autogestion pour son fonctionnement : en gros, deux listes de discussions servent de "lieux de vie" et un système de vote permet de trancher les choix importants. En pratique, le maintien d'une activité démocratique soutenue n'est pas évident et le système repose essentiellement sur les épaules de quelques bénévoles, notamment les administrateurs des serveurs. L'offre de l'autre net est intéressante puisque pour 23 euros par an, vous avez droit à 500Mo d'espace de stockage, pas de limite en termes de trafic (si ça reste raisonnable), une gestion des noms de domaines et des mails, des listes de discussion avec Mailman, du PHP, une base MySQL. Le fonctionnement des serveurs reposant entièrement sur une poignée de bénévoles, il peut arriver que des difficultés techniques ne soient pas résolues dans la minute, ou que certaines opérations délicates (comme la migration de Debian Woody vers Sarge) entraînent des perturbations, mais depuis que j'utilise leurs services (ce site, mon mail, plusieurs listes), je n'ai vraiment pas à me plaindre de quoi que ce soit. Et puis si j'avais à me plaindre, je n'aurais qu'à mettre la main à la pâte, car la participation de tous est vraiment encouragée.

L'autre net est donc un hébergeur intéressant, sans doute plus engagé qu'Ouvaton sur pas mal d'aspects, et qui propose des services très intéressants à un prix défiant toute concurrence. Je le recommande donc vivement, sauf si vous voulez monter un site de e-business avec une disponibilité de 99,99%. Mais dans ce cas, vous ne seriez pas en train de lire ce billet.

Hcoop

Enfin, dernière piste, Hcoop est un hébergeur situé aux Etats-Unis et qui fonctionne de manière assez proche de celle de L'autre net. Il s'agit par contre d'un service orienté vers les utilisateurs expérimentés (maîtrise de l'anglais, connaissance de la ligne de commande sous Linux et de la configuration de base d'Apache obligatoires). Il s'agit en fait d'un regroupement de personnes qui se partagent les frais pour la location de deux serveurs dédiés pour un montant d'environ 200 dollars par mois. Le coût total est divisé par le nombre d'adhérents, qui tourne actuellement autour de 60, ce qui fait environ 3 dollars par mois et par adhérent (le paiement se fait par Paypal). Les services proposés sont très riches du moment qu'on sait les utiliser, et les quotas sont assez flous du moment que personne ne nuit trop au fonctionnement de l'ensemble. En gros, pour ce prix là vous avez autour de 1Go d'espace, un trafic important, un accès SSH direct au serveur, de l'hébergement de domaines, de mails, de listes de discussion avec Mailman, mais aussi du CGI (mais pas de FastCGI), ce qui vous permet de faire tourner du Python, Perl, Ruby, PHP... Mais la force de Hcoop est que tout cela est à la fois très souple et très sécurisé. Comme vous avez un accès direct à un serveur sous Debian Testing, vous pouvez très bien vous installer une base MySQL, Postgres ou SQLite, un dépôt Subversion, voire vous recompiler votre propre Apache, etc. Mais tout cela est également très bien conçu dès le départ et très bien encadré. Il semble également y avoir une vie démocratique interne avec des listes de discussion, un bureau élu, un wiki, un système de votes, etc. Le fait que le serveur soit aux Etats-Unis ne pose pas de problèmes en termes de temps d'accès d'après ce que j'ai pu constater.

Je recommanderais donc Hcoop à des utilisateurs avertis souhaitant avoir une grande souplesse d'utilisation pour un prix au final plutôt modique, surtout compte tenu des taux de change actuels.

Hébergement pour Ruby on Rails

Juba — Sat, 11 Mar 2006 15:48:08 +0000

Comme je m'intéresse de plus en plus à Ruby et Ruby on Rails, d'autant que j'ai l'occasion de m'y mettre au boulot, je me suis demandé quels pouvaient être les hébergeurs intéressants pour un hébergement de sites web en général et d'applis RoR en particulier.

Il y'a pas mal d'infos là-dessus sur le wiki de RoR, avec toute une liste d'hébergeurs disponibles. Une liste un peu plus synthétique se trouve sur Rails Hosting, avec en plus un avis personnel : les hébergements les plus sérieux se trouveraient sur TextDrive (l'hébergeur officiellement soutenu par RoR, mais un peu cher), Site5 et Dreamhost. A noter que le seul hébergeur français à proposer RoR est Typhon, qui propose d'ailleurs une offre de découverte de Rails.

En m'y penchant d'un peu plus près, j'ai trouvé que l'offre de Dreamhost était assez stupéfiante : 20 Go d'espace (avec 160 Mo de plus chaque semaine), 1 To de trafic (avec 8 Go de plus chaque semaine), domaines, mails, listes de diffusions illimités, un nom de domaine gratuit pendant toute la durée de l'hébergement, bases MySql illimitées, PHP4, PHP5, Ruby, CGI, FastCGI, accès FTP, SFTP, WebDAV, accès direct sur le serveur par SSH, dépôts CVS et Subversion... le tout pour environ 9.95$ par mois (selon le mode de paiement).

Sachant qu'il y a 97 jours d'essais pendant lesquels on peut changer d'avis et se faire rembourser intégralement, j'ai donc pris un compte pour tester, et ça a l'air de marcher plutôt bien. C'est assez bluffant de pouvoir avoir un accès SSH direct avec un compte sur le serveur tout en sachant qu'on dispose de 20 Go de stockage...

Au niveau du tarif, si le montant annuel peut paraître un peu élevé de prime abord (120 dollars par an, soit environ 100 euros), il faut noter qu'il y a des codes promotions très intéressants disponibles pour une première inscription. Le principe est que pour tout code promotion utilisé, une partie va au nouvel abonné, une autre à celui qui a créé le code. J'en ai créé un qui vous permet de bénéficier de 75$ de promotion pour tous les plans annuels (ce qui fait que je touche 22$ que je pourrai soustraire du prix de mon hébergement) et le maximum possible pour tous les autres plans. Pour être tout à fait honnête, il est possible de bénéficier de réductions plus importantes assez facilement en Googlant un peu.

Si vous souhaitez bénéficier de cette réduc, il vous suffit d'utiliser le code *** (plus d'actualité, cf. ci-dessous).

Mise à jour : je viens de résilier mon abonnement à Dreamhost à l'instant. Non que je sois mécontent de leurs services, mais j'ai trouvé un hébergeur coopératif intéressant et correspondant davantage à mon état d'esprit (je n'étais qu'à moitié à l'aise avec cette histoire de codes promos). A priori le remboursement des sommes engagées si l'on résilie dans les 97 jours semble fonctionner... Du coup, le code promo en question n'est plus valable !

Utiliser le browser SWT sous Eclipse 3.1.1 avec Debian

Juba — Wed, 15 Feb 2006 11:13:17 +0000

J'utilise depuis peu une version recompilée pour testing du paquet unstable d'Eclipse 3.1.1. Tout fonctionne bien a priori, mais je viens de rencontrer une difficulté après l'installation des RDT (Ruby Development Tools) pour utiliser la vue ri : j'obtiens un message d'erreur me signalant un crash de SWT.

En fait, cette erreur est due à l'impossibilité pour Eclipse et SWT d'utiliser le widget Browser du fait d'une dépendance non-satisfaite, en l'occurrence il a besoin de la librairie libgtkembedmoz.so qu'il ne retrouve pas. Les instructions pour faire tourner tout ça sont dans la FAQ d'Eclipse, mais en fait sous Debian le problème vient du fait que SWT cherche la librairie manquante sous Firefox alors qu'elle n'est présente que sous Mozilla. Et modifier la variable MOZILLA_FIVE_HOME, comme indiqué dans la faq, ne fontionne pas car celle-ci est initialisée dans le script de démarrage d'Eclipse.

La solution la plus simple est donc de modifier le script de démarrage en question, en l'occurrence le fichier /usr/bin/eclipse en transformant le passage suivant :

# Set path for the Mozilla SWT binding
if [ -d /usr/lib/firefox ]; then
    export MOZILLA_FIVE_HOME=/usr/lib/firefox
elif [ -d /usr/lib/mozilla-firefox ]; then
    export MOZILLA_FIVE_HOME=/usr/lib/mozilla-firefox
elif [ -d /usr/lib/mozilla ]; then
    export MOZILLA_FIVE_HOME=/usr/lib/mozilla
fi

en ceci :

# Set path for the Mozilla SWT binding
#if [ -d /usr/lib/firefox ]; then
#    export MOZILLA_FIVE_HOME=/usr/lib/firefox
#elif [ -d /usr/lib/mozilla-firefox ]; then
#    export MOZILLA_FIVE_HOME=/usr/lib/mozilla-firefox
if [ -d /usr/lib/mozilla ]; then
    export MOZILLA_FIVE_HOME=/usr/lib/mozilla
fi

Note : je viens de mettre à jour en version 3.1.2, et le problème est fixé dans le /usr/bin/eclipse de la distribution.

Mettre en place un antivirus pour Linux à la maison

Juba — Mon, 06 Feb 2006 10:41:28 +0000

A priori, le fait d'utiliser un système Linux met déjà son utilisateur à l'abri de la plupart des virus circulant sur le réseau et qui ciblent des systèmes plus répandus et moins fiables (suivez mon regard). Mais cela ne dispense pas d'utiliser un antivirus, surtout quand il en existe de très bons libres et gratuits comme ClamAV.

Voici la méthode que j'utilise pour filtrer mes mails à la maison. Elle utilise un ptit script Perl trouvé sur le web, et n'est certainement pas adéquate pour un gros serveur gérant des dizaines de comptes mails. Elle suppose que vous ayiez déjà un MTA (type postfix ou exim) qui tourne sur votre machine.

La première chose à faire est d'installer clamav en tant que démon. Sous Debian, comme toujours, c'est très simple, en une commande on installe tout ça ainsi que le service de mise à jour automatique de la base de virus :

# apt-get install clamav-freshclam clamav-daemon

La seconde chose est de faire passer tous les mails à travers l'antivirus. Ceci se fait à l'aide de la commande clamdscan. La solution la plus simple que j'ai trouvée consiste en un petit script Perl nommé clamfilter.pl. Le seul inconvénient est qu'il n'utilise pas le démon, mais le client clamav qui lui lance un processus à chaque mail scanné et prend beaucoup plus de ressources système. Le script étant du domaine public (vive le libre !), j'ai donc modifié une dizaine de caractères pour lui faire utiliser clamdscan plutôt que clamscan. Le résultat est le suivant :

#!/usr/bin/perl -w
#
# ClamFilter 1.0
# by Matt Hahnfeld (http://www.everysoft.com/)
# Requires perl, clamscan, procmail, and this script.
#
# This script is public domain.
#

use strict;
use File::Temp 'tempfile';

&main();
exit 0;

sub main {
  # Set up a temporary file for the original message
  my ($tmpfh, $tmpfn) = tempfile( UNLINK => 1 );
  -w $tmpfn or die 'Could not open temp file!';

  # Pass 1: Write out the temporary file
  while (<STDIN>) {
    print $tmpfh $_;
  }
  seek($tmpfh, 0, 0);

  # Pass 2: Scan the message
  open CLAMSCAN, "/bin/cat $tmpfn | /usr/bin/clamdscan --stdout - 2>/dev/null |" or die 'Could not open clamscan!';
  my $clamstatus = qq|X-Virus-Found: yes
X-Virus-Status:
 
 Virus Scan Status:
 
|;
  while (<CLAMSCAN>) {
    $clamstatus .= ' ' . $_;
  }
  close CLAMSCAN;
  $clamstatus .= qq| 
 

|;

  # Pass 3: Print out the message
  my $bodyflag = 0;
  while (<$tmpfh>) {
    if (! $bodyflag and $_ eq "
") {
      if ($?) {
	print $clamstatus;
      }
      else {
	print "
";
      }
      $bodyflag = 1;
    }
    else {
      print;
    }
  }
}

L'installation de ce script est très simple : copiez le contenu dans un fichier /usr/local/bin/clamfilter.pl, rendez le exécutable avec un petit chmod +x clamfilter.pl et ajoutez la ligne suivante dans votre fichier .procmailrc :

:0fw
| /usr/local/bin/clamfilter.pl

Et voilà ! Normalement tous vos mails devraient être scannés avant leur distribution. S'ils contiennent un virus détecté, le script rajoute un flag X-virus-found: yes dans les en-têtes (pratique pour créer des filtres automatiques dans votre lecteur de mail préféré) et ajoute quelques lignes d'information au début du message.

Vous pouvez tester le bon fonctionnement de votre installation d'abord en vérifiant qu'un mail normal passe sans problème, et ensuite en testant avec le fichier de test d'antivirus eicar.