Blog de Thomas Martin

Et bien voila, c'est fait, j'ai ouvert mon blog.

Je traiterais ici principalement des sujets techniques auquels je suis confronté lors des projets
professionnels auquels je participe au sein de la société Evolix, ou de mes projets personnels/associatifs
au sein de l'association Oopss.org.

Si vous avez suivi les liens ci-dessus vous avez normalement compris que les thèmes abordés seront principalement liés au Logiciel Libre et à l'administration système et réseau.

A bientôt !

Debian a son wget, FreeBSD son fetch, et j'ai cru pendant longtemps que le seul moyen simple de récupérer un fichier via HTTP à partir d'un système de base OpenBSD était d'utiliser lynx.

Ce qui n'était pas très pratique car cela force de passer par un mode interactif (sauf option appropriée, mais j'avoue n'avoir jamais pris le temps de parcourir toute la page de man).

J'apprend aujourd'hui que l'outil ftp d'OpenBSD, comme son nom ne l'indique pas, gère aussi HTTP et HTTPS !

Exemple : ftp http://openbsd.org/index.html

Comme vous pouvez facilement le voir j'ai fait le choix du moteur de blog Chronicle.

Etant tout à fait novice dans l'univers du blogging j'avais tout d'abord installé Wordpress, qui a l'air très bien, mais que j'ai jugé finalement trop lourd : base MySQL et beaucoup de code PHP.

Je me suis alors orienté vers Blosxom, qui a l'énorme avantage de stocker ses données dans de simples fichiers texte. Parfait pour un adepte de Subversion comme moi.

Néanmoins quelques soucis m'ont poussé à l'abandonner, notamment le fait que celui-ci se base sur la date de dernière modification des fichiers pour déterminer la date d'une entrée de blog, ce qui ne me convient pas. Je suis certain qu'il existe un plugin (Blosxom étant particulièrement modulaire) pour remédier à cela mais je ne l'ai pas trouvé en temps voulu malheureusement.

Finalement je suis tombé ce matin même sur chronicle, qui est très simple, permet de spécifier quelques meta-informations dans le fichier de données, et gère de base les quelques fonctionnalités indispensables qu'il me fallait. Je n'ai rencontré pour l'instant que quelques petites soucis : il n'est à priori pas internationalisable (un peu génant pour les dates), et ne permet pas de spécifier un encodage pour le plugin Textile que j'utilise (et je suis totalement converti à l'UTF-8). Il ne me reste donc plus qu'à faire remonter quelques patch à l'auteur.

De toute manière rien n'est figé et il me suffira de quelques lignes de perl pour passer à un autre moteur si celui-ci ne me convient plus !

J'ai rencontré quelques soucis ces jours-ci après des mises à jour de ports FreeBSD. J'ai utilisé comme à mon habitude la commande portupgrade -arRe.

• J'avais modifié le script /usr/local/etc/rc.d/milter-greylist afin que milter-greylist s'exécute en tant qu'utilisateur postfix (et non pas mailnull comme c'est le cas par défaut). Cela permet notamment que la socket qu'il crée puisse être utilisable par postfix. J'ai été étonné de voir que la mise à jour a écrasé ce script et a donc rendu le milter indisponible (rien de bien grave, quelques spams reçus avant rétablissement de la situation). Je pensais, peut-être naïvement, qu'un fichier dans /usr/local/etc ne pouvait pas être écrasé sans avertissement.

• Dans le même genre une mise à jour de Roundcube a écrasé ses fichiers de configuration présents dans /usr/local/www/roundcube/config. Conséquences un peu plus graves : webmail indisponible.

Reste à trouver comment cela aurait pu être évité.

J'ai eu récemment à installer la bibliothèque tomcat-native à la demande d'un client d'Evolix.
N'étant pas expert Java/Tomcat je sais juste ce que la page officielle décrit : gain de performance,
une meilleure génération des ID de sessions et certaines fonctionnalités de monitoring.

De plus cela fait disparaitre le message suivant au démarrage de Tomcat :
catalina_2008-04-18.log:INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.5.0...

Voici une copie brute de mes notes d'installation sur un système Debian Etch :

 $ cd $HOME/tmp
 $ sudo aptitude install libapr1-dev autoconf
 $ wget http://tomcat.heanet.ie/native/1.1.9/source/tomcat-native-1.1.9-src.tar.gz
 $ tar zxvf tomcat-native-1.1.9-src.tar.gz
 $ cd tomcat-native-1.1.9-src/jni/native/
 $ apt-get source libapr1
 $ sh buildconf --with-apr=./apr-1.2.7/
 $ ./configure --with-apr=/usr/bin/apr-config --with-ssl=/usr/include/openssl --with-java-home=/usr/lib/jvm/java-1.5.0-sun
 $ make
 $ sudo cp .libs/libtcnative-1.so.0.1.3 /usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386/libtcnative-1.so
 $ sudo /etc/init.d/tomcat5.5 restart

Note : l'installation d'une version <1.1.4 avec la version de Tomcat de Debian Etch provoque un message d'erreur.

Il ne me reste plus qu'à en faire un package afin de pouvoir installer ça proprement.

En réponse à la faille critique DSA-1571 parue aujourd'hui :

Voici un résumé rapide de certaines opérations urgentes à effectuer ( liste non exhaustive ).
Pour plus d'informations vous pouvez consulter la page dédiée sur wiki.debian.org.

Mettre à jour le système

aptitude update && aptitude upgrade

Regénerer la clé du serveur OpenSSH

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa
/etc/init.d/ssh restart

Regénerer vos propres clés

A faire sur un système à jour bien sur.

Supprimer les clés utilisateurs impactées

Un script fourni par Debian permet de les détecter : http://security.debian.org/project/extra/dowkd.
Attention l'auteur signale que celui-ci peut donner des faux positifs ou des faux négatifs.

Ensuite vous pouvez lancer par exemple :

for i in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do perl ./dowkd.pl file $i; done

Regénerer vos certificats SSL

Pour votre serveur mail, web, VPN,...

La commande dhclient(8) dispose d'un fichier de configuration : dhclient.conf(5).

Celui-ci permet notamment de configurer la requête DHCP envoyée au serveur, par exemple la directive
send dhcp-requested-address 10.0.1.1 permet de demander cette adresse IP au serveur, qui nous
l'affectera si elle est disponible.

Autre possibilité intéressante, celle de spécifier un autre dhclient-script(8). Ce script est invoqué par dhclient
pour effectuer la configuration réseau de la machine après avoir interrogé le serveur DHCP. Il est alors
possible à des fins de débuggage de modifier la fonction add_new_address() afin d'afficher l'adresse IP qui
aurait été affecté, sans l'affecter rééllement.

Le fichier /etc/fstab après une installation standard de Debian utilise
directement des noms de partitions sous la forme /dev/sda2 par exemple.

Or, la connexion d'un périphérique (clé USB, baie de disque, etc.), peut
potentiellement décaler votre disque principal en /dev/sdb, le périphérique
fraîchement connecté utilisant /dev/sda. Ceci rend alors votre système
impossible à démarrer correctement.

Une solution est alors d'utiliser le nommage UUID fourni par udev(7).
Chaque partition dispose dans /dev/disk/by-uuid d'un lien symbolique
pointant vers elle-même :

/dev/disk/by-uuid/1351bbd0-e931-47a0-b528-be33d135d35a -> ../../sda2

Udev fourni par défaut une notation raccourcie permettant de spécifier des
entrées dans /etc/fstab de la forme :

UUID=1351bbd0-e931-47a0-b528-be33d135d35a / ext3 ...

Toutefois si vous utilisez Debian Etch et l'option user du fichier fstab,
vous allez certainement rencontrer des problèmes au démontage de vos partitions
avec un utilisateur non privilégié (#466775).
La solution est alors d'utiliser le chemin complet :

/dev/disk/by-uuid/1351bbd0-e931-47a0-b528-be33d135d35a / ext3 ...

Ce qui après tout est plus UNIX.

Note : Si les périphériques swap n'apparaissent pas dans /dev/disk/by-uuid il
faut les reformater. Par exemple pour la partition swap /dev/sda7 :

swapoff /dev/sda7
mkswap /dev/sda7
blkid /dev/sda 7   # retourne l'UUID

Le serveur dhcpd(8) d'OpenBSD dispose d'une fonctionnalitée permettant
d'alimenter des tables pf(4) lorsque certains évènements se produisent : bail
DHCP établi, adresse IP «abandonnée», changement d'adresse MAC.

Cela peut permettre par exemple de bloquer l'accès à un routeur à des machines
n'ayant pas obtenu leurs adresses IP par DHCP.

Lors d'une tentative de mettre ça en place il y a quelques mois je ne parvenais
pas du tout à le faire marcher : les tables n'étaient jamais remplies !
J'ai découvert il y a peu la réponse : cela ne fonctionne pas pour des machines
dont l'adresse IP est fixée à l'aide d'une directive fixed-address dans
dhcpd.conf. Et de plus le fichier dhcpd.leases n'est pas non plus alimenté
pour ces machines.