Pour ceux qui aiment bien lire la fin en premier, je mets la fin au début  :

echo "mypassword" |sudo -S id

Pour illustrer le problème, prenons un cas concret qui m’est arrivé.
Un serveur s’est soudainement mis dans un état bizarre, à savoir que tout marchait, les processus déjà en cours continuaient de s’exécuter, d’autres processus pouvaient se créer, mais certaines choses ne marchaient pas, notamment l’allocation de pseudo-terminaux (les /dev/pts/*) ; si je tente une connexion SSH au serveur, le serveur répond bien, l’authentification se fait, et au moment d’avoir mon prompt, la connexion se freeze.
Après divers tests, je m’aperçois qu’en passant directement une commande à ssh, ça marche :

ssh serveur-foireux dmesg

La différence vient du fait que dans le deuxième cas, ssh n’ouvre pas de pseudo-terminal sur le serveur distant, puisqu’il se contente de récupérer directement stderr et stdout.
On peut faire en sorte de se connecter sans allouer de terminal sur le serveur avec l’option -T de la commande ssh :

     -T      Disable pseudo-tty allocation.

On a ainsi un shell qui s’exécute sur la machine, et on récupère la sortie brute de stderr et stdout (pas de prompt, d’édition de la commande en cours, etc…). Pareil pour stdin, ce qui fait que les commandes sudo ou su retournent une erreur, étant donné qu’elles font une manipulation spécifique sur stdin (pas d’echo pour la saisie du mot de passe). De ce fait, on est un peu coincé pour passer root.

Il existe une solution (que j’ai bien sûr trouvé après avoir brutalement redémarrer le serveur), une simple option à sudo qui permet de lire le mot de passe depuis stdin. Et là, pas besoin d’exécuter la commande dans un terminal donc !

echo "mypassword" |sudo -S id
[sudo] password for rdessort: uid=0(root) gid=0(root) groupes=0(root)

Et comme cela affiche votre mot de passe en clair sur l’écran, voici un petit script pour améliorer la chose :

1
2
3
4
5
6

#!/bin/bash
 
echo -n "Enter password: "
read -s passwd
 
ssh serveur-foireux "echo $passwd |sudo -S id"

Une autre application probablement beaucoup plus courante pourrait être de pouvoir scripter des commandes nécessitant d’être root sur le serveur. Notamment exécuter la même commande sur plusieurs dizaines de serveurs d’affilée.

L’hôte en question fait tourner des environnements virtuels à l’aide d’OpenVZ, ce qui m’oblige donc à rajouter ceci dans mon /etc/sysctl.d/openvz.conf pour qu’ils puissent avoir une chance de sortir sur Internet :

1

net.ipv6.conf.all.forwarding=1

Cependant cela entraine la désactivation de l’autoconfiguration « stateless » de l’hôte, c’est à dire qui n’est plus capable de prendre une IP automatiquement, ni de positionner sa route par défaut.
Je ne rentrerai pas dans les détails de pourquoi c’est comme ça, n’ayant pas trouvé d’explications sur le sujet, mais je suppose que le noyau doit ainsi transférer tous les paquets NDP sur sa seconde interface, même s’il ne devrait pas car ces paquets ne sont pas censés traverser les routeurs. Bref si quelqu’un a une explication, qu’il n’hésite pas !

Une fois qu’on sait ça, rien de compliqué (le plus dur en fait est de se rendre compte que le forwarding désactive l’autoconfiguration de l’hôte). On peut configurer l’interface de manière statique dans /etc/network/interfaces (pour Debian et dérivés) :

1
2
3
4
5

iface eth0 inet6 static
    address 2a01:e35:2e31:da50:1e6f:65ff:fe54:5c96
    netmask 64
    up route -A inet6 add default gw fe80::224:d4ff:feb4:f9b6 dev eth0 metric 1
    down route -A inet6 del default gw fe80::224:d4ff:feb4:f9b6 dev eth0 metric 1

Source de l’image : http://www.potaroo.net/presentations/2008-11-17-ipv6-failure.pdf (http://www.potaroo.net)

Par défaut l’encodage des fichiers n’est pas précisé dans le champ « Content-Type », comme le montre une requête HTTP HEAD :

$ HEAD http://univers-libre.net/plop.txt
200 OK
Connection: close
Date: Fri, 27 May 2011 20:23:14 GMT
Accept-Ranges: bytes
ETag: "1885714849"
Server: lighttpd/1.4.28
Content-Length: 7767
Content-Type: text/plain
Last-Modified: Sun, 02 May 2010 09:34:31 GMT
Client-Date: Fri, 27 May 2011 20:20:53 GMT
Client-Peer: 192.168.0.60:80
Client-Response-Num: 1

Dans la majeure partie des cas, on s’en fou grave car l’encodage est précisé dans la balise HTML , et le client interprète donc bien le texte comme étant de l’UTF-8 (ou ce que vous voulez). Oui mais justement, lorsqu’on veut que Lighttpd serve de bêtes fichiers texte, nous n’avons plus cette balise pour nous aider. Il faut donc forcer le champ Content-Type pour rajouter charset=utf8 à la fin.

Avec Apache, cela se fait en rajoutant la directive AddDefaultCharset. Sous Lighty, il faut redéfinir le type MIME en question, de cette manière :

1

mimetype.assign  += ( ".txt"  => "text/plain; charset=utf8" )

Attention, petite particularité sous Debian (ce n’est peut-être pas spécifique à Debian non plus), les types MIME sont générés par un script perl /usr/share/lighttpd/create-mime.assign.pl, appelé dans la conf de lighttpd. Il faut donc bien faire attention à rajouter la ligne de conf ci-dessus *après* cette ligne :

1

include_shell "/usr/share/lighttpd/create-mime.assign.pl"

echo "foo"

Mais bref, là n’est pas le sujet. J’ai entendu beaucoup de retours positifs sur php-fpm, ce qui m’a convaincu de le le mettre en place.

Je n’ai pas encore eu trop l’occasion de regarder en détail la conf, celle par défaut marche sans soucis. Je vais donc pour l’instant juste vous faire part d’un petit détail lié à la page de status de php-fpm et Lighttpd (mais qui doit probablement impacter d’autres serveurs web).
En fait, par défaut elle ne marche pas (erreur 404). Dans la conf, il est dit :

; Note: The value must start with a leading slash (/). The value can be
; anything, but it may not be a good idea to use the .php extension or it
; may conflict with a real PHP file.

Soit, mais rien est dit quant à la configuration du serveur web devant.
J’ai mis un petit moment à comprendre, donc je vous donne l’astuce pour éviter de se prendre la tête.

Voici le petit bout de conf à rajouter dans Lighty :

1
2
3
4
5
6
7

        fastcgi.server += ((
                "/status" => (
                        "host" => "127.0.0.1",
                        "port" => 9000,
                        "check-local" => "disable"
               )
        ))

Et une petite explication sur le problème (qui est en fait tout à fait logique) :
Par défaut le serveur web ne peut pas savoir que php-fpm fournit la page /status. Pour lui, si pas de fichier nommé status, il s’arrête là en renvoyant une 404. Il faut donc forcer Lighttpd à passer cette URL à php-fpm (comme si c’était un .php), et sans vérifier si le fichier existe bien sur le système de fichier.

Comme j’ai l’habitude d’installer et peu de tout et de n’importe quoi pour découvrir, et de ne surtout rien désinstaller, je me retrouve vite avec une quantité de paquets inutiles. Pour m’aider à nettoyer tout ce bazar, j’ai fais un mini script qui affiche de manière triée la liste des paquets Debian avec leur taille.
Le voici :

1
2
3
4
5
6

#!/bin/bash
 
dpkg --get-selections |cut -f1 |while read package
do
	dpkg -p $package |perl -ne "print \"\$1: $package\n\" if /^Installed-Size: (.*)$/"
done |sort -rn

Et voici le résultat (la taille est en ko bien sûr) :

romain@heimdall:~$ bash package-size.sh |head
84496: mysql-server-5.0
78328: linux-image-2.6.26-2-amd64
33904: apcupsd-doc
31780: erlang-nox
22812: vim-runtime
21440: linux-headers-2.6.26-2-common
19364: mysql-client-5.0
18880: smbclient
18304: perl
15934: libgtk2.0-common

romain@heimdall:~$ bash package-size.sh |wc -l
1432

Sur Apache ou Lighttpd ça marche sans problème, mais sur un serveur web qui ne supporte pas CGI (NginX par exemple, à moins de passer par des hacks assez tordus) ça ne marche plus.

La solution est donc de dire à AWStats de générer les page HTML automatiquement après chaque mise à jour de sa base de données. Voici la procédure :

• Créez tout d’abord le répertoire qui contiendra les pages HTML, avec les bons droits :

  mkdir /var/www/awstats/
  chown www-data:www-data /var/www/awstats/

• Modifiez ensuite le fichier /etc/cron.d/awstats pour appelez le script awstats_buildstaticpages.pl au lieu de awstats.pl :

  1 2 3 4

  [ -x /usr/share/doc/awstats/examples/awstats_buildstaticpages.pl \ -a -f /etc/awstats/awstats.yoursite.conf -a -r /var/log/nginx/yoursite.access.log ] \ && perl /usr/share/doc/awstats/examples/awstats_buildstaticpages.pl -update \ -config=yoursite -dir=/var/www/awstats -awstatsprog=/usr/lib/cgi-bin/awstats.pl >/dev/null

  À adapter bien sûr avec les bons noms de fichiers de conf et de log.

• N’oubliez pas d’ajouter un alias dans la conf de votre serveur web pour les icônes. Sous NginX, ça donne ça :

  1 2 3

  location /awstats-icon/ { alias /usr/share/awstats/icon/; }

Sous Debian ce n’est pas le cas, car cette version est difficilement maintenable au niveau sécurité (cf le bug report Debian)

Pour contourner le problème, en cherchant un peu sur le net (ici pa exemple), beaucoup de monde recompile PHP avec la version embarqué de GD. Ce n’est à mon avis pas la meilleure solution au niveau « maintenabilité ».

Voici donc 2 autres possibilités :

Utiliser les dépôts dotdeb

Les dépôts dotdeb contiennent des versions plus récentes et/ou modifiés de paquets Debian pour serveurs LAMP. Le paquet php5 présent dans dotdeb est justement compilé avec la version embarqué de la bibliothèque.

Réécrire la fonction imagerotate()

Si vous n’avez besoin que de cette fonction et que vous n’avez pas envi d’utiliser la version embarqué de GD, il est tout à fait envisageable de réécrire la fonction en question :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?php
if ( !function_exists( 'imagerotate' ) ) {
  function imagerotate( $source_image, $angle, $bgd_color ) {
      $angle = 360-$angle; // GD rotates CCW, imagick rotates CW
      $temp_src = '/tmp/temp_src_'. rand( 10000,99999 ) .'.jpg';
      $temp_dst = '/tmp/temp_dst_'. rand( 10000,99999 ) .'.jpg';
      if (!imagejpeg($source_image,$temp_src)){
       return false;
      }
      $imagick = new Imagick();
      $imagick->readImage($temp_src);
      $imagick->rotateImage(new ImagickPixel($bgd_color?$bgd_color:'black'), $angle);
      $imagick->writeImage($temp_dst);
      //trigger_error( 'imagerotate(): could not write to ' . $file1 . ', original image returned', E_USER_WARNING );
      $result = imagecreatefromjpeg($temp_dst);
      unlink($temp_dst);
      unlink($temp_src);
      return $result;
  }
}
?>

Fonctionnalités

• Création/édition/suppression/listage des articles et pages ;
• Prévisualisation hors-ligne de l’article dans un navigateur ;
• Publication/retrait d’un article ;
• En-tête de l’article (un peu comme pour les mails) permettant de définir le titre, les tags et catégories…
• Des hooks blogit_format et blogit_unformat, appelés respectivement juste avant un commit et juste après un edit, permettant de formater/déformater le texte avec des langages comme markdown, textile, reStructuredText… à l’aide de pandoc.

Installation

Je reprend un peu la procédure du wiki, mais traduite en français ici.

Tout d’abord, il vous faut un Vim compilé avec le support de python (rarement le cas par défaut) :

vim --version |grep python

Sous ArchLinux, il faut installer le paquet gvim, et sous Debian et dérivées, il s’agit du paquet vim-python (qui installera vim-gtk).

Vous pouvez ensuite récupérer l’archive et la décompresser dans votre ~/.vim/.

Il faut maintenant créer le fichier ~/.vim/passwords.vim qui contiendra les informations de connexion à votre blog :

1
2
3

let blogit_username='Your blog user name'
let blogit_password='Your blog password. Not the API-key.'
let blogit_url='https://example.com/xmlrpc.php'

Au passage, un chmod 600 sur ce fichier ne sera pas de trop…

Utilisation

Le script s’appelle via :Blogit. Un :Blogit help vous renverra la liste des commandes possibles :

Available commands:                                                                                                               
   :Blogit ls [blog]         list all posts
   :Blogit new [blog]        create a new post
   :Blogit this [blog]       make this a blog post
   :Blogit edit {id} [blog]  edit a post
   :Blogit page {id} [blog]  edit a page
   :Blogit commit            save article
   :Blogit push              publish article
   :Blogit unpush            unpublish article (save as draft)
   :Blogit rm {id}           remove a post
   :Blogit tags              update and list tags and categories
   :Blogit preview           preview article in browser
   :Blogit help              display this notice

Je ne détaille pas plus, les commandes sont assez explicite selon moi.

Bonus

Vous voudriez surement rajouter des options automatiquement lors de l’édition des articles
(par exemple set spell pour la correction orthographique). Dans ce cas, il faut les
définir dans la méthode python init_vim_buffer() de la classe BlogPost du
plugin (attention à le faire dans la bonne classe, il y en a plusieurs), comme ceci :

vim.command('setlocal spell tw=80')

De même, il peut être sympa d’affecter une touche à la commande :Blogit commit, à l’aide de map :

vim.command('map <f9> :Blogit commit <CR>')

Article fièrement écrit avec Vim .

Dimanche 3 octobre, j’ai couru mon premier semi marathon, accompagné de 2 collègues. Pour une première fois, j’en suis plutôt content, j’ai finis en 2h12 les 21,1 km. J’ai été classé 736^ème sur 988, mais le milieu de peloton (le 494^ème) a mis 2h pile, ce qui laisse entendre qu’on était beaucoup à arriver entre 2h et 2h15.

D’un point de vue parcours et organisation, c’était superbe. Le circuit partait de Pertuis pour rejoindre la Tour d’Aigues en passant par l’étang de la Bonde. Il y avait très peu de portion dans la ville, la majorité du circuit suivait une route en pleine campagne ou un chemin de terre au milieu des vignes, sans compter le tour du très joli étang de la Bonde. À l’arrivée, on avait de quoi boire et manger à volonté (en plus des ravitaillements le long du parcours), et une bouteille de vin du Lubéron offerte ! (les marathoniens en avaient droit à 2…). Plan du parcours.

L’ambiance était très orientée fête, entre les personnes qui courraient déguisées, le marché du terroir à l’arrivée, etc… c’était très bien organisé.

D’un point de vue difficulté, j’ai senti la fatigue venir vers le 14^ème km (je cours rarement plus de cette distance là en tant normal), et à partir du 17^ème km, je ne pensais plus qu’à l’arrivée.

Les derniers 100 mètre était très dur, malgré le public et la fanfare, dans le sens où je savais que l’arrivée était toute proche, mais je ne la voyais toujours pas.

Mais malgré la difficulté, je n’ai jamais pris autant de plaisir à courir. Le fait de courir pour un but précis surtout (atteindre l’arrivée), mais aussi d’être entouré d’un tas d’autres gens qui courraient également dans le même but et avec un grand nombre de spectateurs était super motivant. Ça n’avait rien à voir avec courir le soir, seul ou avec des collègues.

Bref, après tout ça, je peux dire sans hésitation que ce ne sera pas mon dernier !

Pour finir, quelques photos :

Plus de photos ici, là, et encore là.

du -sh foo/*

Ou bien, si on veut avoir aussi les sous sous répertoires :

du -h --max-depth 2 foo/*

L’option -h permettant d’avoir la taille exprimé en kilo, méga, giga, etc…

Là où les choses se compliquent, c’est lorsqu’on veut trier numériquement le résultat par ordre décroissant. Si on fait un :

du -sh foo/* |sort -rn

le tri sera faussé du fait de la présence des lettres qui suivent la taille.

D’où l’astuce du jour : comment trier numériquement la sortie d’un du tout en ayant la taille exprimé en « human readable » ?

Si vous avez le paquet coreutils en version ≥ 7.5, vous êtes sauvé, sort implémente l’option -h qui répond exactement au problème (merci à Roland pour sa remarque) :

du -sh foo/* |sort -rh

Dans le cas contraire (si vous êtes sur une Debian Lenny par exemple), c’est un peu moins simple.
En cherchant un peu sur le net, il existe un tas d’astuces différentes utilisant perl ou awk. Voici celle que j’utilise, qui me semble la moins tordue (mais un peu quand même) :

du -s foo/* |sort -rn |cut -f2 |xargs -d '\n' du -sh

Le principe est d’obtenir d’abord la liste des répertoires avec leur taille « brute », de trier cette liste, puis de refaire un du (avec -h cette fois) sur chaque répertoire de la liste).
Le fait d’exécuter 2 fois un du n’est pas super élégant point de performance, mais en pratique, comme le résultat du premier du est caché en mémoire, le second est très rapide.