Introduction

J'ai eu récemment l'occasion de mettre en oeuvre une infrastructure LAMP, reposant sur la plate-forme d'hébergement de machines virtuelles d'Amazon, nommé EC2, pour Elastic Compute Cloud.

Le principe de fonctionnement est le suivant : on créé une image AMI (Amazon Machine Image), contenant le système de fichiers du système d'exploitation à démarrer. Il est possible d'utiliser et de personnaliser des AMI fournis par Amazon, ou de la créér de zéro. Le noyau, quant à lui, est à sélectionner parmi ceux proposés par Amazon.

Ensuite, cette image est téléchargée vers l'infrastructure de stockage d'Amazon, S3 (Simple Storage Service). Après enregistrement de celle-ci, elle peut être instanciée en une ou plusieurs machines virtuelles.

Une particularité de cette solution est que les données stockées dans le système de fichiers racine des machines virtuelles ne sont pas persistantes. Une fois une instance terminée (via la commande halt par exemple, ou via l'interface d'Amazon), celles-ci sont perdues ! Il faut alors utiliser pour les données applicatives une autre fonctionnalité d'Amazon, les EBS (Elastic Block Storage). Il s'agit de disques virtuels que l'on peut ajouter à une instance, accessibles sous forme de simples block devices que l'on peut formater et monter. A noter que depuis peu il est possible d'utiliser un EBS en tant que système de fichiers racine, ce qui permet de démarrer et d'arrêter une machine à volonté, sans nécessité d'instancier à nouveau une AMI.

Mise en oeuvre

Ce premier article décrit les étapes à suivre pour créér sa propre image AMI de Debian 5.0, l'envoyer vers Amazon, et la démarrer. Il vous faudra évidemment pour cela un compte Amazon Web Services.

Création de l'image

Création d'une image d'une taille de 1 Go et montage sous /mnt/ami :

# EC2_AMI_NAME=debian50
# dd if=/dev/zero of=$EC2_AMI_NAME.img bs=1M count=1024
# mkfs.ext3 -F $EC2_AMI_NAME.img
# mkdir /mnt/ami
# mount -o loop $EC2_AMI_NAME.img /mnt/ami

Installation et exécution de l'outil debootstrap, qui permet le téléchargement et l'installation d'un système Debian de base dans le point de montage. Attention, une architecture 32 bits est requise pour pouvoir démarrer des instances de type Small.

# aptitude update
# aptitude install debootstrap
# debootstrap --arch i386 lenny /mnt/ami

Montage des pseudo systèmes de fichier :

# mount -t proc proc /mnt/ami/proc/
# mount -t devpts devpts /mnt/ami/dev/pts/

Changement du répertoire racine vers le point de montage (chroot) et installation des packages nécessaires :

# chroot /mnt/ami
# aptitude install udev libc6-xen ssh

Configuration des points de montage dans /etc/fstab tel que recommandé dans la documentation :

/dev/sda1  /         ext3    defaults        1 1
NONE       /dev/pts  devpts  gid=5,mode=620  0 0
none       /dev/shm  tmpfs   defaults        0 0
none       /proc     proc    defaults        0 0
none       /sys      sysfs   defaults        0 0
/dev/sda2  /mnt      ext3    defaults        0 0
/dev/sda3  swap      swap    defaults        0 0

Ajout des lignes suivantes au fichier /etc/network/interfaces pour configurer l'interface eth0 en DHCP :

auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp

Il est également nécessaire d'ajouter sa clé SSH dans /root/.ssh/authorized_keys, ou de définir un mot de passe pour le compte root.

Enfin, quitter le chroot, et démonter l'image :

# /etc/init.d/ssh stop
# exit
# umount /mnt/ami

Génération de l'image AMI

Pour la suite des opérations, il est nécessaire de télécharger et décompresser les Amazon EC2 API Tools et Amazon EC2 AMI Tools. On installe également les dépendances nécessaires.

# aptitude install ruby libopenssl-ruby unzip sun-java6-jre
# EC2_AMI_TOOLS=ec2-ami-tools-1.3-XXXXX
# EC2_API_TOOLS=ec2-api-tools-1.3-XXXXX

Il faut également générer une clé et un certificat X.509, et faire pointer les variables d'environnements ci-dessous vers les fichiers téléchargés. Ceux-ci seront utilisés pour effectuer des requêtes vers les web services d'Amazon.

# EC2_PRIVATE_KEY=pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem
# EC2_CERT=cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem

Enfin, noter son EC2 user ID, généralement visible en haut à droite des pages d'AWS.

# EC2_USER_ID=XXXX-XXXX-XXXX

Création de l'image AMI :

# export EC2_HOME=$EC2_AMI_TOOLS
# $EC2_AMI_TOOLS/bin/ec2-bundle-image -i $EC2_AMI_NAME.img \
    -k $EC2_PRIVATE_KEY -c $EC2_CERT -u $EC2_USER_ID -r i386

Upload sur S3

Il faut maintenant télécharger l'image vers Amazon S3. Pour cela, il est nécessaire de récupérer son Access Key ID et sa Secret Access Key sur la page Security Credentials. Il faut également sélectionner la région où sera localisée l'instance (US ou EU), ainsi que la bucket S3 où sera stockée l'AMI.

# EC2_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXX
# EC2_SECRET_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
# EC2_REGION=EU
# EC2_BUCKET=XXXXXXXX
# $EC2_AMI_TOOLS/bin/ec2-upload-bundle -m /tmp/$EC2_AMI_NAME.img.manifest.xml \
    -a $EC2_ACCESS_KEY -s $EC2_SECRET_KEY -b $EC2_BUCKET \
    --location $EC2_REGION

Enregistrement de l'instance

Il est nécessaire de déclarer l'image à Amazon pour pouvoir l'instancier. L'option --url est nécessaire pour préciser que l'on s'adresse à la région Europe d'EC2.

# export EC2_HOME=$EC2_API_TOOLS
# export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.12
# $EC2_API_TOOLS/bin/ec2-register \
     --url http://eu-west-1.ec2.amazonaws.com \
     -n $EC2_AMI_NAME \
     $EC2_BUCKET/$EC2_AMI_NAME.img.manifest.xml

La commande retourne l'ID de l'AMI qui vient d'être enregistrée.

Instanciation

L'instanciation peut également se faire via une requête sur AWS :

# EC2_AMI_INSTANCE_ID=ami-XXXXXXXX
# EC2_AKI=aki-7e0d250a
# EC2_RAMDISK=ari-7d0d2509
# $EC2_API_TOOLS/bin/ec2-run-instances $EC2_AMI_INSTANCE_ID \
     -K $EC2_PRIVATE_KEY \
     -C $EC2_CERT \
     --kernel $EC2_AKI --ramdisk $EC2_RAMDISK \
     --region eu-west-1

Le noyau utilisé (aki-7e0d250a) est un 2.6.21.7-2.fc8xen, suffisamment récent pour l'utilisation de udev. Ce n'est pas le cas du noyau par défaut.

Connexion à la machine

Les instances créées peuvent être listées à l'aide de la commande suivante :

# $EC2_API_TOOLS/bin/ec2-describe-instances -K $EC2_PRIVATE_KEY \
  -C $EC2_CERT --url http://eu-west-1.ec2.amazonaws.com

Parmi les informations obtenues, on peut notamment connaître le nom DNS public de l'instance créé, de la forme ec2-XXX-XXX-XXX-XXX.eu-west-1.compute.amazonaws.com. A noter que ces informations sont également disponibles via l'interface web.

Enfin, il ne reste plus qu'à se connecter avec le compte root à sa nouvelle machine !

Utiliser PHP en tant que module Apache est la façon classique de faire. Une autre solution est de l'utiliser en tant que simple programme CGI. Cela peut permettre d'utiliser une version différente de PHP que celle chargée en tant que module, ou alors de limiter l'utilisation mémoire d'Apache. Pour cela, une méthode intéressante est d'utiliser le module mod_actions, qui permet entre autre d'associer un script CGI à un type MIME.

Voici les étapes à effectuer, sur un système Debian :

Installation du CGI PHP5 :

# aptitude install php5-cgi

Activation de mod_actions :

# a2enmod actions

Utiliser enfin les directives suivantes au sein d'un virtualhost, d'un fichier .htaccess ou d'un bloc <directory>, pour utiliser le CGI PHP5 avec les fichiers dotés d'une extension .php :

AddHandler cgi-php5 .php
Action cgi-php5 /cgi-bin/php5

Voici un récapitulatif de la mise en place des protocoles d'authentification SMTP DKIM et DomainKeys sous Debian Lenny. Le serveur de mail utilisé est Postfix, mais tout MTA sachant communiquer avec les milter de Sendmail peut normalement être utilisé. La signature et la vérification des messages sera effectuée pour le domaine <domain>. Voici les étapes :

Installation de dkim-filter et dk-filter :

# aptitude install dkim-filter dk-filter

Ajouter dans le fichier /etc/dkim-filter.conf un ensemble de directives indiquant le nom du domaine qui va utiliser DKIM, un nom de selector (exemple : 2009), et le nom du fichier qui contiendra la clé privée utilisée pour la signature. L'utilisation des selector permet notamment de changer et/ou révoquer facilement une clé, ou d'utiliser des clés différentes sur des serveurs de mails différents.

Domain      <domain>
KeyFile     /etc/ssl/dkim_<domain>_<selector>.key
Selector    <selector>

Générer la clé :

# openssl genrsa -out /etc/ssl/private/dkim_<domain>_<selector>.key

Et en extraire la partie publique :

# openssl rsa -in /etc/ssl/private/dkim_<domain>_<selector>.key \
          -pubout -outform PEM

Dans la zone DNS du domaine <domain>, ajouter l'enregistrement suivant. La valeur de <key> correspond à la sortie de la commande précédente, contenue entre les lignes _BEGIN PUBLIC KEY_ et _END PUBLIC KEY_ :

<selector>._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=<key>"

Ajouter les paramètres de démarrage de dkim_filter dans /etc/default/dkim-filter. Le fichier /etc/dkim.hosts contient la liste des serveurs dont les mails sortants seront chiffrés :

SOCKET="inet:2505@localhost"
DAEMON_OPTIONS="-l -i /etc/dkim.hosts"

Les paramètres de dk-filter, dans /etc/default/dk-filter, sont similaires, à l'exception que tout est passé via les options, celui-ci n'utilise pas de fichier de configuration.

DAEMON_OPTS="$DAEMON_OPTS -d <domain>  -S <selector> -i /etc/dkim.hosts \
             -s /etc/ssl/private/dkim_<domain>_<selector>.key"
SOCKET="inet:2506@localhost"

Puis les redémarrer :

# /etc/init.d/dkim-filter start
# /etc/init.d/dk-filter start

Reste enfin à utiliser ces milter au niveau de Postfix, pour cela ajouter les directives suivantes au fichier /etc/postfix/main.cf :

milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:2505 inet:localhost:2506

Et redémarrer Postfix :

# /etc/init.d/postfix restart

Un test basique de fonctionnement est alors d'envoyer un mail à destination d'un domaine effectuant des vérifications DKIM, yahoo.com par exemple.

# nc 127.0.0.1 25 <<EOT
HELO localhost
MAIL FROM: root@<domain>
RCPT TO: <account>@yahoo.com
DATA
Subject: Test DKIM
.
QUIT
EOT

Les signatures DKIM et DomainKeys sont correctement vérifiées si l'en-tête Authentication-Results contient dkim=pass et domainkeys=pass.

On peut également envoyer un mail à destination de son domaine, et vérifier que l'en-tête Authentication-Results est bien ajoutée, et valide.

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

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

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.