Archives de
Mois : février 2012

Faire un proxy SSL

Faire un proxy SSL

Pour ceux qui me lisent régulièrement, je fais du multisite WordPress à ma sauce. Or, une des instances que j’héberge ainsi, a une vocation privée : une sorte d’extranet. Pour y parvenir, j’utilise un dispositif simple et efficace qui repose sur des outils particulièrement éprouvés : SSL et l’authentification HTTP Basic. Seulement voilà, les navigateurs de nos jours, pour des raisons bassement mercantiles font tout pour contraindre les propriétaires de site à acquérir des certificats souvent onéreux sans quoi ils effraieront vos usagers en leur disant que votre site n’est pas protégé. Ils vous préviennent aussi que si vous voulez vraiment y accéder, il va falloir lire plein de messages incompréhensibles et cliquer à droite à gauche.

OVH en son temps, proposait des certificats SSL bon marché opérationnels sur leur serveur mutualisé, mais il semble là aussi que le côté bon marché n’ait pas vraiment séduit. J’y vois 2 raisons selon qu’on se place du côté du développeur ou du décideur (les 2 principaux intéressés) :

  • pour les développeurs, un truc bon marché, c’est déjà plus cher qu’un truc gratuit alors pourquoi payer ?
  • pour les décideurs, un truc bon marché ça ne peut pas être sûr. En effet, dans les schémas mentaux qu’on leur a inculqués en grandes écoles, il y a cette idée que quand on veut de la sécurité en informatique, il faut payer cher !

Bilan, pour pallier à l’impossibilité d’installer un certificat personnel sur un serveur mutualisé, j’ai été contraint d’utiliser mon serveur VPS comme un simple proxy mais avec un certificat valide. Voici le schéma de fonctionnement :

Internet --- HTTPS ---> family.e-gaulue.com --- HTTPS ---> family-direct.e-gaulue.com
                   (certificat conforme sur VPS)      (certificat non conforme du mutu OVH)

La suite de cet article décrit cette installation.

Lire la suite Lire la suite

Passer d’une image Debian VMware (.vmdk) à VirtualBox (.vdi)

Passer d’une image Debian VMware (.vmdk) à VirtualBox (.vdi)

On trouve un peu de documentation sur la transformation d’un fichier .vmdk en .vdi. Qui plus est, cette simple transformation n’est pas toujours suffisante. En effet, en fonction de votre installation Debian, votre système peut refuser de booter car les drivers qui lui sont présentés ne sont pas les mêmes d’une plate-forme de virtualisation à l’autre.

Dans le cas présent, cette méthode est valable pour Mac OS X Lion.

La transformation du fichier .vmdk en .vdi

Tout d’abord, il vous faut récupérer le bon fichier vmdk, celui qui contient les données. Sur des plates-formes VMware récentes, le fichier correspondant à la VM pipo est censé se nommer pipo-flat.vmdk.

Une fois récupéré le fichier, nous allons utiliser la technique de conversion QEMU, je n’ai jamais réussi à faire fonctionner celle qui consiste à demander directement à VirtualBox de faire la conversion.

Il faut donc QEMU. Personnellement, j’utilise MacPort pour récupérer ce type de programme.

> sudo port install qemu

Attention, ça peut être long. Une fois terminé, on convertit notre .vmdk en .img (une image disque classique identique à ce que nous fournirait la commande dd).

> qemu-img convert -p pipo-flat.vmdk pipo.img

Attention, c’est assez long (fonction de la taille du disque) et vous n’avez pas d’autre moyen de suivre la progression qu’en ajoutant l’option -p. Enfin, vous transformez cette image en image .vdi grâce à VirtualBox (que je suppose installé).

> VBoxManage convertfromraw --format VDI pipo.img pipo.vdi

Là encore, il va falloir attendre mais ls -l vous donnera des indications sur l’état d’avancement.

Démarrer sa machine virtuelle

Si vous êtes un fan de l’esprit « J’ai de la chance », vous pouvez y aller : vous créez votre VM que vous associez au fichier .vdi obtenu. On ne sait jamais… Des fois, sur un malentendu…

Dans mon cas, j’ai reçu ce message :

Gave up waiting for root device. Common problems:3f06f945760
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
Alert! /dev/disk/by-uuid/XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX does not exist. Dorpping to a shell!
 
BusyBox v1.13.3 (ubuntu 1:1.13.3-1ubuntu11) built-in shell (ash)
Enter 'help' for a list of built-in commands.

En gros, je l’ai traduit par : « je n’ai pas trouvé ton disque » et j’en ai déduit que certainement les drivers émulés par VMware et VirtualBox pour le SATA ne devaient pas être les mêmes.

J’ai donc décidé de faire appel à mon couteau suisse préféré : SystemRescueCD.

Après téléchargement, on crée une machine virtuelle avec un CD qui pointe vers l’iso de SystemRescueCD et un disque SATA qui pointe vers notre fichier pipo.vdi en vérifiant que l’amorce se fera sur le CD.

Une fois la machine virtuelle lancée, SystemlRescueCD vous demandera de spécifier votre langue (pratique pour le clavier) et vous fournira une invite.

fdisk -l vous fournira une liste des partitions de votre image disque. Il vous reste à identifier la partition system, à la monter (dans mon cas /dev/sda1) et à chrooter dedans.

> mkdir pipo
> mount /dev/sda1 pipo
> chroot pipo /bin/bash

On se retrouve alors dans notre système, mais attention, il exécute le noyau de SystemRescueCD. Reste à reconstruire un initramfs qui convient. Pour cela, il convient d’aller faire un tour dans /boot pour identifier votre noyau.

> ls /boot
-rw-r--r-- 1 root root  655316 Oct 17  2010 abi-2.6.32-25-generic-pae
-rw-r--r-- 1 root root  116502 Oct 17  2010 config-2.6.32-25-generic-pae
drwxr-xr-x 2 root root    4096 Nov 17  2010 grub
-rw-r--r-- 1 root root 2429568 Sep 20 20:23 initrd.img-2.6.32-25-generic-pae
-rw-r--r-- 1 root root 1730990 Oct 17  2010 System.map-2.6.32-25-generic-pae
-rw-r--r-- 1 root root    1200 Oct 17  2010 vmcoreinfo-2.6.32-25-generic-pae

Ça sent fort le noyau de version 2.6.32-35-generic-pae. Maintenant, sauvegardons l’ancien initrd et générons-en un nouveau :

> cd /boot
> mv initrd.img-2.6.32-25-generic-pae initrd.img-2.6.32-25-generic-pae.old
> update-initramfs -k 2.6.32-25-generic-pae -c
mkinitramfs: missing sda root /dev/sda1 /sys entry
mkinitramfs: workaround is MODULES=most
mkinitramfs: Error please report the bug
update-initramfs: failed for /boot/initrd.img-2.6.32-25-generic-pae

Ah oui… j’oubliais… Avec cette méthode d’exécution chroot de votre système, tous les montages n’ont pas eu lieu. Ici, il semble manquer /sys. Qu’à cela ne tienne, il suffit de le monter.

> mount /sys
> update-initramfs -k 2.6.32-25-generic-pae -c

Reste alors à éteindre la machine virtuelle, supprimer le CD correspondant à SystemRescueCD et redémarrer la machine virtuelle.

Si vous avez bien suivi, cette méthode peut aussi s’appliquer à la réalisation d’un P2V (transfert d’une machine physique vers une machine virtuelle) d’un système basé sur Debian, car on peut aller bien au-delà de la simple reconstruction de l’initramfs en installant un nouveau noyau compatible VM (pae) par exemple.