C’est en soi assez édifiant, mais je viens de constater un phénomène qui l’est encore plus. À l’heure où j’écris ces lignes, si l’on tape mon nom dans Google, le deuxième résultat est la page d’accueil du présent weblog (j’insiste : la page d’accueil). C’est dans un sens surprenant, vu que cette page ne comporte pas mon nom, et que la seule page qui le contient n’apparaît que bien plus bas dans les résultats.

L’explication de ce phénomène est tout simple. Depuis quelque temps, les articles que je poste sur usenet se terminent par la « signature » suivante :

-- 
<mon prénom et nom nom>             Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/            http://people.math.jussieu.fr/~mpg/

où bien sûr il y a réellement mon prénom et mon nom au lieu de mon prénom et mon nom. C’est donc uniquement le contexte dans lequel le lien apparaît qui assure son bon placement sur cette requête précise.

Si j’ai maquillé la signature ci-dessus, c’est juste pour préserver la magie apparente du résultat de recherche dans l’extrait duquel Google ne peut surligner aucun des mots-clé de la recherche…

Structure générale du fichier

Commençons par le commencement, c’est un fichier texte contenant sur chaque ligne le nom d’une option et sa valeur. Le fichier est séparés en blocs commençant par l’option Host, les directives de chaque bloc ne s’appliquant qu’aux hôtes qui correspondent au motif indiqué. Par exemple

Host *.math.utah.edu
User g-pdm

dit qu’à chaque fois que je me connecte à un hôte du domaine math.utah.edu, mon nom d’utilisateur est g-pdm. En clair, les deux lignes suivantes deviennent équivalentes :

$ scp foo sunset.math.utah.edu:
$ scp foo g-pdm@sunset.math.utah.edu:

Comme on le voit, les options de ssh-config sont utilisée par tous les outils de la suite, et pas seulement par la commande ssh.

Alias

Précisons que Host se réfère au nom d’hôte que vous saisissez sur la ligne de commande, qui peut être différent du nom d’hôte réel, lequel se spécifie alors avec HostName. Par exemple, la section suivante n’a d’autre but que de raccourcir mes lignes de commandes en ne tapant que le nom d’hôte au lieu du nom pleinement qualifié. (C’est de la flemme, oui, et alors ?)

Host thue
HostName thue.elzevir.fr

C’est aussi pratique pour les hôtes qui n’ont pas d’adresse IP publique. Par exemple j’ai chez moi une machine principale, et parfois mon laptop qui tourne et auquel je peux vouloir accéder depuis la fac. Pour cela, j’utilise les fonction NAT de ma « libreboîte » (qui porte assez mal son nom, mais passons), mais c’est pénible de devoir préciser à chaque fois le numéro de port. L’entrée suivant concernait mon ancien laptop (paix à son âme) :

Host siegel
HostName elzevir.fr
Port 12622
HostKeyAlias siegel.elzevir.fr
ForwardAgent yes

La directive Port se passe sans doute de commentaires, mais si on utilise qu’elle, on a vite des problèmes. En effet, l’hôte en question a la même adresse que thue, mais une clé publique de serveur SSH différente. Ceci provoque des avertissements à chaque fois, car le client vérifie que la clé présentée par le serveur coïncide avec celle enregistrée dans le fichier known_hosts. On peut désactiver cette vérification, mais ça ne me paraît pas très prudent. Une bonne solution est fournie par HostKeyAlias, qui permet de donner un nom arbitraire (et donc unique si on le veut) à l’entrée de cet hôte dans known_hosts.

Au passage, une directive que j’aime bien est HashKnownHosts no : c’est la valeur par défaut en général, mais dans Debian, c’est à yes. L’idée du yes est que les entrées de known_hosts fournissent à un éventuel intrus des informations. L’idée du no, c’est d’une part que vous pouvez lire le fichier et donc le maintenir (effacer les vieilles entrées inutiles, par exemple), et d’autre part que ça peut être une source d’info utile (ça m’a bien dépanné le jour où les DNS de mon FAI étaient en rade, d’avoir des IP d’hôtes auxquels je pouvais me connecter, par exemple).

Toujours en passant, j’ai un peu menti à la fin du dernier billet : en fait, ForwardAgent vaut no par défaut, et je le passe à yes individuellement par hôte.

Tunnels

La dernière directive que j’utilise est LocalForward, qui est l’équivalent de l’option -L en ligne de commande. C’est utile pour les tunnels qu’on établi souvent. Par exemple, pour me connecter à la fac, je dois passer par un sas : les serveurs internes ne sont pas accessibles directement de l’intérieur. C’est embêtant, mais on a plusieurs stratégies pour simplifier la chose. L’une passe par l’utilisation de ProxyCommand : je ne pratique pas, je n’en dirai donc rien. Celle que j’utilise est la suivante.

Host galois2
HostName 127.0.0.1
Port 1033

Host tunnels
HostName sas.math.jussieu.fr
LocalForward 1033 galois2.math.jussieu.fr:22

J’établis d’abord une redirection du port local 1033 vers le port 22 de la machine à laquelle je veux me connecter via le sas. Cette opération est à effectuer seulement une fois quand j’ouvre ma session (je fais ça en même temps que ssh-add via un alias shell) avec la ligne de commande ssh -Nf tunnels (-N dit de ne pas exécuter de commande distante (on veut juste rediriger les ports en fait) et -f de tourner en arrière-plan). Ensuite, je peux me connecter directement à galois2 en tapant juste ssh galois2.

Ligne de commande

Oui, le titre du billet est ssh_config(5) et pas ssh(1) ni scp(1), mais bon, voyons quand même trois options pratiques en ligne de commande. Le première est -o qui permet de spécifier sur la ligne de commande toute option disponible dans le fichier de configuration.

Une autre option que j’aime, spécifique à scp, est -l pour limiter la bande passante utilisée (pratique pour un téléchargement non urgent en tâche de fond, un cron de sauvegarde, etc.)

Enfin, une spécifique à ssh est -t, qui permet de forcer l’attribution d’un tty sur la machine distante, même quand on spécifie une commande distante. Exemple : je veux me connecter sur thue, mon serveur de fichiers, relié à ma chaîne hifi, pour y lancer mocp, un lecteur de musique en console. Essayons naïvement.

mpg@roth:~% ssh thue mocp
Error opening terminal: unknown.

L’option -t est faite précisément pour ça. Je l’utilise aussi pour me connecter à la fac en choisissant mon shell (on n’a pas le droit de changer son shell de login) : ssh -t galois1 'zsh -l' et hop !

1. Garder en cache une copie déchiffrée de votre clé privée ssh, pour vous éviter d’avoir à saisir constamment la passphrase.
2. Permettre de voyager facilement entre différentes machines : les demandes d’authentification sont retransmises à la machine initiale.

Mon propos ici n’est pas de faire un guide de l’usage normal de ssh-agent mais plutôt de montrer comment le détourner légèrement. L’usage prévu est que les processus fils de ssh-agent ou du shell où il a été lancé aient dans leur environnement une variable SSH_AUTH_SOCK pointant vers un socket Unix permettant de communiquer avec l’agent.

Il n’y a pas longtemps, j’ai voulu utiliser une connexion ssh dans le contexte d’un hook post-commit de Subversion. Il s’agit par exemple de pages web que je tiens sous contrôle de version, et dont je souhaite qu’à chaque commit elles soient mises à jour sur le serveur web (auquel j’ai accès par ssh). Ça tombe bien, je me connecte à mon serveur SVN par la méthode ssh+svn://, et en principe j’ai toujours un ssh-agent qui tourne sur la machine de départ. Problème, les hooks SVN démarrent avec un environnement essentiellement vide.

Il faut donc essayer de retrouver soi-même les informations de ssh-agent. Ce n’est pas très difficile, en fait l’accès au socket n’est protégé que par les permissions au niveau du système de fichiers. Les quelques lignes de Perl suivantes trouvent un socket ssh-agent actif s’il y en a un et positionnent la variable SSH_AUTH_SOCK pour permettre son utilisation facile par les fils du processus courant.

sub hack_ssh_agent {
    return if $ENV{'SSH_AUTH_SOCK'};
    $success = 0;
    opendir TMP, "/tmp";
    for my $dir (grep (/ssh-/, readdir TMP)) {
        opendir TEST, "/tmp/$dir";
        ($agent) = grep (/^agent/, readdir (TEST));
        closedir (TEST);
        $ENV{'SSH_AUTH_SOCK'} = "/tmp/$dir/$agent";
        print "Trying /tmp/$dir/$agent\n";
        $success = (system("ssh localhost true") == 0);
        last if $success;
    }
    closedir TMP;
    die "Pas moyen de trouver un ssh-agent.\n" unless $success;
}

Outre l’utilisation présentée, à savoir récupérer les informations permettant de se connecter à un ssh-agent depuis un processus qui n’en est pas un descendant, je pense que ces quelques lignes de code ont un intérêt pédagogique. Elles montrent qu’il est très facile pour root de récupérer les ssh-agent de tous les utilisateurs s’il le désire. (Notons quand même que ça ne lui donne pas accès à la clé déchiffrée de façon permanente, non plus : c’est déjà ça.)

En soi, ce n’est pas un grand problème de sécurité : si on a pas confiance en root, on est de toutes façons déjà dans… les problèmes jusqu’au cou. Par contre, j’ai un compte sur la machine d’un ami en qui j’ai en général toute confiance mais qui est souvent très blagueur en matière informatique. J’ai donc pris soin d’insérer ForwardAgent no dans mon ~/.ssh/config concernant sa machine.

Petite parenthèse pour qui se demande d’où vient cette idée de désinstaller la libc : ça fait partie du folklore de fr.misc.bavardages.linux, un groupe iouzenette ma foi fort sympathique (voir ses conseils d’utilisation et notamment les liens de la section 4 (alerte procrastination) mais aussi le fortune-file (alerte bis)). La vérification du rapport avec la désinstallation de libc est laissée au lecteur.

Bref, souhaitant retrouver les termes exacts de la phase de sécurité en question (pour vérifier si elle suppose bien que l’utilisateur est de sexe masculin, ce qui ne serait pas forcément sexiste : une fille est bien trop responsable pour désinstaller sa libc…), me voilà parti à bidouiller les trois commandes sus-citées pour leur faire cracher le message. Quand, sûr de moi car n’ayant pas précisé --force-remove-essential je tape (en root sur mon laptop, qui est ma machine principale) :

dpkg --force-depends --remove libc6

à ma grande surprise ça « marche » (si l’on peut dire), sauf les scripts post-désinstallation, qui échouent, comme on devrait s’en douter. J’ai alors le plaisir d’entretenir avec mon shell préféré un dialogue aussi réjouissant que

% /bin/ls
zsh: command not found: /bin/ls
% ??!

le temps de réaliser ce que je viens de faire.

Arrivés à ce stade de votre lecture, vous êtes sans doute mort de rire. Même si j’en suis heureux, ce n’est pas la finalité principale de ce blog, qui avait plutôt pour but de partager des astuces techniques en LaTeX, ou en geekeries linuxiennes. La partie technique arrive : je vais vous expliquer comment il est facile de réinstaller sa libc. (Je lis la déception dans votre regard : rassurez-vous, ça m’a quand même pris un bon moment avant de comprendre que c’était facile.)

On s’arme bien sûr d’un bon Live CD, car le système n’est pas bootable (on pourrait en fait, avec l’option init=/sbin/sash mais je ne pense pas que ça avance à grand chose). Mon choix se porte que grml pour sa parenté avec Debian, son état d’esprit et sa finition que j’apprécie (je pratique aussi sysresccd à l’occasion). Je vous épargne les détails, mais je finis par découvrir ici l’option --root de dpkg qui semble résoudre mon problème.

Après avoir monté toutes les partition adéquates de mon disque dur (petit instant de doute en voyant qu’il n’y a rien dans /dev/mapper, mais la FAQ grml me conseille Start lvm et a bien raison), j’essaie et là c’est le drame : la version de dpkg du CD grml gravé il y a un an est trop vieille pour toucher à ma Lenny (la prochaine version de Debian) à jour. Yaka en graver une plus récente. Ou pas, parce que graver un CD en tournant sur Live CD, euh… Bref, vivent le boot sur clé USB, et les tutoriels qui marchent du premier coup (c’est aussi pour ça que j’aime grml).

Deuxième essai. Ok, dpkg fait de son mieux mais c’est le script d’installation qui marche pas : command not found: /bin/ls, ça vous dit quelque chose ? Visiblement --root en fait un peu trop. On passe donc au 6.3.7 de la page qui en parlait : faire soi-même le boulot de dpkg. Enfin, juste une partie de son boulot, lui il est plus subtil. Mais ça suffit, ouf.

Donc résumé en deux mots, le how-to (même si le mieux c’est de pas commencer, hein) :

1. Démarrer sur Live CD, récent ou pas.
2. Télécharger le .deb de la libc sur http://packages.debian.org.
3. Monter ses partoches ou volumes LVM du système cassé quelque part.
4. ar x lic6-*.deb où vous voulez, puis tar xf data.tar.gz à la racine du point de montage.
5. Redémarrage sur le système anciennement cassé, et dpkg -i libc6-*.deb quand même, juste pour que les petits papiers de dpkg soient à jour.

Morale de l’histoire : ne plus jamais tester des trucs idiots ailleurs que sur une machine de test (fut-ce une machine virtuelle ou un simple chroot).

Télécharger les sources du noyau sur kernel.org. Pour une version stable (ex. aujourd’hui : 2.6.27.7), utiliser le lien F (full source) sur la ligne. Dans tous les autres cas, il faut télécharger le patch (lien du numéro de version, ex. 2.6.28-rc6) et la base à laquelle l’appliquer, donnée par le lien B sur la même ligne. Dans les exemples qui suivent, je suppose que les trucs sont enregistrés sous ~/tmp.

Ajouter son utilisateur au groupe src si ce n’est pas déjà fait. Par exemple :

# adduser mpg src

Puis se relogguer avec cet utilisateur pour que la modification soit effective. Le vérifier en tapant id ou groups.

En utilisateur, aller dans /usr/src, y détruire le lien symbolique linux. Décompresser l’archive des sources. S’il s’agit d’une version à patcher, procéder comme dans l’exemple suivant.

% tar xjf ~/tmp/linux-2.6.27.tar.bz
% bunzip2 ~/tmp/patch-2.6.28-rc6.bz2
% cp -r linux-2.6.27 linux-2.6.28-rc6
% cd linux-2.6.28-rc6
% patch -p1 <~/tmp/patch-2.6.28-rc6

Une fois obtenue une belle arborescence des sources dûment patchée au besoin, rétablir le lien symbolique linux vers sa racine.

Il faut maintenant configurer le nouveau noyau. Pour partir de la configuration de l’ancien, faire par exemple

% cp /boot/config-2.6.27.5 /usr/src/linux/.config

Aller alors dans /usr/src/linux et y lancer alors make menuconfig. (Il faut sans doute installer un ou deux paquets pour ça, dont libncurses-devet peut-être d’autres.) Selon les besoins, sélectionner les drivers voulus (chez moi, c’est ath9k qui m’a motivé à installer une version récente du noyau, et que je vais activer la première fois dans Device driver -> Networks device support -> Wireless Lan -> Atheros 802.11n wireless cards support).

Il est alors temps de construire le noyau. Pour cela, il faut avoir installé les paquets nécessaires : kernel-package, fakeroot, build-essential et initramfs-tools en font partie, et je crois qu’ils suffisent. Exécuter alors

% fakeroot make-kpkg clean
% fakeroot make-kpkg --initrd kernel_image

(Si on envisage de faire plusieurs noyaux personnalisés successifs à partir d’une même version upstream, on a intérêt à utiliser l’option --append-to-version=.20081107 (ou tout autre numéro) pour les distinguer et ne pas mélanger leurs modules.) C’est en tout cas le moment de s’en jeter une petite de son breuvage favori, ou de faire autre chose d’intéressant sur sa machine si on elle a un double cœur.

Maintenant, la seule étape nécessitant les droits de root : l’installation du paquet créé.

# dpkg -i /usr/src/linux-image-2.6.27.5_2.6.27.5-10.00.Custom_amd64.deb

Voilà, il ne reste plus qu’à rebooter sur le nouveau noyau, et éventuellement recompiler les modules externes.

Le première point qui m’a frappé en essayant Wordpress, c’est que jamais je ne pourrai m’habituer au pseudo-éditeur de texte en ligne qu’il propose par défaut pour rédiger les billets. J’ai pensé un moment copier-coller depuis vim, mais c’est pénible, et de plus WP fait par défaut subir à mon texte un traitement bizarre qui remplace les fins de lignes par des balises <br /> : pénible, quand on édite sur 80 colonnes. (Je reviendrai sur ces traitements dans le prochain billet.)

Pour l’intégration de vim et de WP, j’ai gougueuler un peu à tout hasard, et après avoir trouvé une extension Firefox qui permettrait d’éditer n’importe quel champ de texte d’une page ouèbe dans vim (ou emacs pour ceux qui y tiennent), ce qui a l’air prometteur mais ne tient malheureusement pas ses promesse après 5 minutes d’essai/combat, j’ai plutôt rapidement trouvé le Nirvana, sous la forme de vimpress, un plugin vim.

L’idée est très simple : WP propose plusieurs API utilisant le protocole XMLRPC. En gros, ce protocole (pour ce que j’en comprends) est très générique et permet de représenter en XML quelques types de données naturels dans les langages courants. À partir de là, on peut définir facilement des type de données « billet de blog », « liste de billets », etc. et les échangers en XML. Pour l’utilisateur-programmeur, c’est magique : modulo l’existence d’une bibliothèque XMLRPC dans son langage favori, on a un type de données dans ce langage qui réprésente un billet de blog, et une fonction simple pour le récupérer ou l’envoyer.

vimpress, c’est l’implémentation de tout ça sous la forme d’un plugin vim en python, utilisant l’API MovableType, et sous GPL. (Il faut donc avoir une version de vim compilée avec le support python, j’en reparlerai sans doute un de ces jours.) C’est bel et bon, mais ça un défaut : ça ne gère pas la fonctionalité qui permet d’affiicher seulement les première lignes d’un billets comme je le fais sur le page d’accueil : quand on tente de récupérer un tel billet pour l’éditer, on reçoit seulement ses prmières lignes, justement.

Heureusement, après avoir un peu fouillé, on finit par comprendre des choses sur l’API metaWeblog (à mon avis mal documentée : là où j’ai le mieux compris, c’est dans le source PHP de WP), à savoir que les premières lignes d’un message et sa suite sont deux éléments metaWeblog distincts, à savoir description et mt_text_more. Heureusement aussi que python est facile à lire et à éditer même si on ne le connait pas : quelques temps après, j’avais patché avec succès ma version locale de vimpress.

Bref, c’est maintenant un plaisir pour moi de pouvoir éditer mes billets sous vim, confortablement. Pour augmenter ce confort, je rédige en markdown (et plus précisément en markdown extra), mais je vous ai déjà assez ennuyé pour aujourd’hui : ce sera l’objet du prochain billet.

Tout d’abord, j’ai lancé un petit aptitude install wordpress et commencé à regarder ce qui se trouvait dans /u/s/d/wordpress. Il y avait un README et des exemples de configuration Apache et de script pour aider à créer une base mysql et permettre à wordpress d’y accéder.

J’ai d’abord été surpris de constater que le script échouait, tout simplement parce que je n’avais pas de serveur mysql qui tournait. Enquête faite, mysql-server est simplement suggéré par wordpress et pas installé d’office, car on pourrait en principe utiliser une bdd distante. Soit, j’installe mysql-server-5.0 et tout marche.

Mais après quelques minutes à configurer la chose, je change d’avis et me met à penser que c’est mieux d’installer wordpress à la main dans mon home : je trouve lourd d’avoir à être root pour installer des thèmes par exemple. Donc on efface tout et on recommence, sauf qu’avant de désinstaller on dit aptitude unmarkauto avec la liste des dépendances de wordpress histoire de les garder sous le coude.

Bref, je suis donc parti du site http://fr.wordpress.org/, j’ai téléchargé l’archive et l’ai dézippée dans ~/www/weblog. J’ai alors suivi les instructions en bas de page et plus spécifiquement celles présentes ici pour la création et configuration de la bdd. Tout a bien marché.

Par contre, en testant, j’ai une mauvaise surprise, provenant des exemples de .htaccess préalablement recopiés : il semblerait que la directive ErrorLog, qui ne provoquait pas d’erreur à la relecture de la configuration, faisait par contre tout bonnement mourir le serveur (dans des souffrances atroces, j’imagine) quand on tentait d’accéder à la page. J’ai abandonné l’idée d’utiliser cette fonctionnalité pour le moment.

L’autre petit souci est survenu quand j’ai voulu configurer des jolis permaliens : d’une part il faut penser à mettre le code aimablement fournit par wordpress dans une directive <Directory> comme nous l’apprend le message d’erreur. D’autre part, c’est stupide mais il faut y penser : il faut activer mod_rewrite

Pour finir, deux mots sur la configuration d’Apache. Comme souvent chez Debian, c’est un peu sophistiqué mais assez bien fait : pour les sites comme pour les modules, il y a un répertoire *-available et un *-enabled et on active les trucs en faisant des liens symboliques du deuxième vers le premier. J’en profite d’ailleurs pour place dans le home de mon utilisateur les fichiers de configuration propres à chacun des serveurs virtuels, et lui donne le droit grâce à sudo de demander à Apache de relire ses fichiers de configuration.

Je trouve ça plus pratique que de lister les sites virtuels dans le fichier de conf principal d’Apache puis d’utiliser des .haccess. D’une part, au moment du reload on a les messages d’erreur si les directives ne sont pas correctes, d’autre part, ça fait toujours un fichier de moins à analyser chaque requête pour Apache.

Bref, mon ~/www/weblog.conf Kimarch® est le suivant :

<VirtualHost *:*>
    ServerName weblog.elzevir.fr
    DocumentRoot /home/mpg/www/weblog
    <Directory />
        Options FollowSymLinks
        AllowOverride All
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteBase /
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.php [L]
    </IfModule>
    </Directory>
</VirtualHost>

Je crois n’avoir rien oublié, tout a l’air de marcher pour le moment.