Humus numericus

Aller au contenu | Aller au menu | Aller à la recherche

R, Spip et autres

Linux, Debian, etc.

Fil des billets - Fil des commentaires

mardi 25 novembre 2008

Quelles belles courbes !

Que voilà :

Munin postfix mailqueue

C'est quoi donc ? C'est le nombre de mails contenus dans la file d'attente du postfix de ce serveur... La jolie courbe bleue qui monte qui monte ce sont les 15000 mails reçus dans la nuit de dimanche à lundi suite à un envoi massif de spams depuis un autre serveur qui ne m'appartient pas mais dont je reçois les mails d'admin. Les 15000 mais sont tous les Undelivered mail returned to sender résultant de cet envoi de spams.

Bon ben tout ça n'a pas plu à mon postfix, mais surtout à mon dspam, qui a régulièrement lâché après les différentes relances effectuées dans la journée. Ça n'est que dans la soirée que j'ai vraiment pu m'occuper du problème (Lles jolies courbes verrtes sur la figure), surveiller dspam et le relancer lorsqu'il plantait. Mais vu le débit (pas plus d'un mail à la seconde, pas sûr que mon installation soit bien optimisée), j'en avais pour un moment.

Heureusement, j'ai pu trouver un petit script permettant de supprimer des mails de la file d'attente à partir d'un regexp sur le résultat de postqueue -p. Résultat, le script suivant :

while true; do for i in $( sudo postqueue -p |head -n 500 | grep -i mail |awk '{print $1}'|sed s/\*// );do sudo postsuper -d $i; done; done

m'a permis de terminer l'évacuation du bouchon vers 2h du matin, au lieu de beaucoup plus tard...

lundi 21 juillet 2008

Canal IRC francophone dédié à R

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

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

mercredi 14 mai 2008

Problème avec VirtualBox

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

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

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.

mercredi 12 décembre 2007

Ras le bol des grosses configs

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

jeudi 6 décembre 2007

Script shell de transfert de photos

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 !

jeudi 10 mai 2007

Passage à Dotclear 2.0

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]

mardi 30 janvier 2007

Utiliser Gimp avec Ion3

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.

vendredi 12 janvier 2007

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

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"

Par défaut, cron-apt ne fait que mettre à jour les sources de paquets, et ne les installe pas. Si vous souhaitez automatiser également l'installation, il faut que vous rajoutiez un fichier nommé 5-install dans le répertoire /etc/cron-apt/action.d/ et qui contient la ligne suivante :

dist-upgrade -y -o APT::Get::Show-Upgraded=true

Attention : il est normalement déconseillé d'effectuer ce genre d'actions automatiquement sur un serveur. En cas de problèmes lors de la mise à jour, ceci peut empêcher certains services de redémarrer. Dans tous les cas, pensez à bien regarder les rapports envoyés par Cron pour vérifier que tout s'est bien dérouolé...

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

jeudi 11 janvier 2007

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

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.

- page 2 de 4 -