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