oobe/msoobe /a

Pour les non habitués, l’invite de commande est accessible en cliquant sur Démarrer > Exécuter….

Color Pallete Generator

Désormais vous n’aurez plus besoin de lancer The Gimp pour obtenir le code hexa du magnifique bleu de votre logo ! Color Pallete Generator permet d’extraire la palette de couleur d’une image selon deux modes : upload du fichier image ou renseignement de l’URL.

Icon Finder

Une panne d’inspiration et/ou de talent pour dessiner les visuels de son site ? Rendez-vous sur Icon Finder ! En plus d’être assez efficace, ce moteur de recherche d’icônes permet de sélectionner celles dont la licence est compatible avec un usage commercial. Méfiance tout de même avec cette fonctionnalité, il m’a semblé reconnaître des icônes issues de certains packs dont la licence n’est pas celle indiquée.

Stripe Generator

Les rayures sont à la mode, alors pourquoi s’en priver. Stripe Generator permet de créer des fond bariolés en quelques clics mais attention : trop c’est trop !

Comment accéder aux services d’un réseau privé (mail, annuaire, etc.) depuis une connexion Internet classique ?

Le tout sans accès VPN, sinon la question ne se pose pas :)

Le protocole SOCKS

SOCKS est un protocole réseau permettant de router des connexions (TCP ou UDP) initiées par des applications clientes, via un serveur proxy. On peut faire l’analogie avec un proxy HTTP, sauf qu’au lieu d’analyser les en-têtes des requêtes HTTP, un proxy SOCKS agit au niveau de la couche session (5) du modèle OSI, ce qui le rend utilisable par une multitude de protocoles.

Mise en place d’un proxy SOCKS via tunnel SSH

Il existe de nombreuses applications permettant de mettre en place un proxy SOCKS, comme l’indique la page Wikipedia dédiée au protocole. Selon les implémentations, il est possible de mettre en place des scénarios complexes d’authentification et de routage, mais dans notre cas nous allons utiliser SSH, le but étant simplement de réaliser un routage de port dynamique. Pour mieux comprendre les commandes qui vont suivre, jetons un oeil au schéma suivant :

Depuis un poste client, nous voulons accéder de façon transparente aux services du réseau private.tld et nous disposons pour cela d’un accès au bastion gate.public.tld, sur lequel se trouve un serveur SSH en écoute sur le port 9999. Le but de la manipulation consiste à établir un tunnel entre le poste client et le bastion, de façon à ce qu’il transmette toutes les requêtes à destination du réseau protégé. Comme il n’y a pas de miracles, il faut bien sûr que les accès du bastion vers le réseau interne soient autorisés. Dans ce scénario, le serveur SSH du bastion va faire office de proxy SOCKS. Cette utilisation un peu particulière nécessite de mettre en place au préalable un tunnel SSH entre le client et le proxy, via la commande :

$ ssh  -NvD 1080 user@gate.public.tld -p 9999

Ainsi, toutes les requêtes reçues sur le port 1080 de la machine cliente seront transmises au bastion via le tunnel, puis redirigées vers les services du réseau interne.

NB : L’option -v n’est pas indispensable, mais il est préférable de l’activer dans un premier temps pour visualiser le traffic passant dans le tunnel.

Ça y est, tout est en place ! Il suffit maintenant de configurer les applications clientes pour utiliser le proxy SOCKS. De nombreuses applications proposent en standard une configuration SOCKS, mais si ce n’est pas le cas il est possible de passer par les outils socat ou tsocks. Pour l’exemple, nous allons paramétrer Firefox.

Configuration de Firefox

Configuration standard

Depuis la panneau de paramétrage réseau, il faut configurer un proxy avec les paramètres suivants :

• Cocher la case Configuration manuelle du proxy
• Hôte SOCKS : localhost
• Port : 1080
• Cocher la case SOCKS v5

Mais si l’on essaie ensuite de se connecter à l’adresse http://mail.private.tld, la connexion échoue. En effet, les requêtes DNS ne passent pas par le proxy, et ne sont donc pas résolues par le serveur DNS du réseau interne. Pour y remédier, il faut afficher la fenêtre de paramétrage avancé de Firefox en tapant about:configdans la barre de navigation, et placer l’option network.proxy.socks_remote_dns sur true.

Module FoxyProxy

FoxyProxy est un module Firefox très utile permettant de gérer différentes configurations proxy. Après l’avoir installé, on peut saisir une configuration similaire à celle décrite précédemment. L’intérêt de ce module réside surtout dans le fait qu’il est possible d’affecter un proxy particulier en fonction de l’url cible. Dans notre cas, nous voulons restreindre l’utilisation du proxy SOCKS aux URLs du domaine private.tld. Après avoir sélectionné le mode Utiliser les proxies basés sur leurs motifs et propriétés prédéfinis, on ajoute le motif suivant à l’instance correspondant au proxy SOCKS :

• Motif d’URL : .*://.*\.private\.tld(:[0-9]*)?/.*
• Format du motif : Expression régulière

Pour résoudre le problème de résolution DNS, il faut cocher la case Utiliser un proxy SOCKS pour les résolutions DNS de l’onglet Paramètres généraux.

C’est terminé, vous avez maintenant accès aux services du réseau interne !

RabbitVCS is a set of graphical tools written to provide simple and straightforward access to the version control systems you use. Currently, it is integrated into the Nautilus file manager and only supports Subversion, but our goal is to incorporate other version control systems as well as other file managers.

Je ne l’ai pas encore testé, mais ça ne saurait tarder. En attendant, rendez-vous sur le site officiel.

Côté client

Ici, le but des opérations est de mettre en oeuvre un mécanisme permettant d’attester l’identité du client auprès du serveur. Le séquence de données échangée dans ce but porte le nom de SSH Identity et met en jeu une paire de clés privée/publique.

La clé privée permet d’identifier le client auprès du serveur lors de l’établissement d’une connexion. Gardez bien à l’idée que cette clé privée est le seul moyen d’attester au serveur que la connexion est bien initée par vous (on peut faire l’analogie avec votre carte d’identité) ! Il est donc impératif de la garder secrète car tout individu l’ayant en sa possession pourra endosser votre identité et accéder aux ressources protégées (ici vos comptes utilisateurs) aussi simplement que vous. Nous verrons cependant qu’il existe une protection supplémentaire.

La clé publique, quant-à-elle, est utilisée par le serveur lors d’une connexion SSH entrante, afin de vérifier que la clé privée utilisée par le client correspond bien à celle attendue pour le compte utilisateur spécifié. Dans une paire de clé privée/publique, il existe en effet une procédure de test permettant de s’assurer de la correspondance entre les deux éléments. En cas de réussite (on parle de match), l’authentification est assurée et la connexion suit son cours.

Génération d’une paire de clés

La version 2 du protocole SSH supporte les algorithmes asymétriques DSA et RSA, utilisés pour la partie authentification (le reste des échanges est assuré par un chiffrement symétrique). Dans la suite de ce billet j’utiliserai DSA, mais libre à vous de me suivre ou non. Quel que soit votre choix, la première étape consiste à générer une paire de clés via la commande ssh-keygen :

$ ssh-keygen -t dsa -b 1024 -f sebastien-chevallier

Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in sebastien-chevallier.
Your public key has been saved in sebastien-chevallier.pub.
The key fingerprint is:
e7:a2:00:a2:ec:e7:0c:b9:01:12:ac:7f:76:18:ef:67 tuxp@MacBook-de-Sebastien.local
The key's randomart image is:
+--[ DSA 1024]----+
|                 |
|.                |
|..               |
|..               |
|= . .   S .      |
|=o.. +   o       |
|.=. = o . .      |
|. =+ + .E.       |
| ooo  oo         |
+-----------------+

NB : il est vivement recommandé de renseigner une passphrase pour protéger l’accès à sa clé privée car c’est la seule protection (celle dont je parlais plus haut) qu’il vous reste en cas de vol de votre clé privée.

Restriction des permissions

Par convention (mais cela n’est pas une obligation), nous allons placer la clé privée (ici le fichier sebastien-chevallier) dans le répertoire ~/.ssh. Pour des raisons de confidentialité évidentes, nous en restreignons l’accès à son seul propriétaire :

$ chmod -R 700  ~/.ssh

Il ne reste alors plus qu’à diffuser la clé publique (fichier sebastien-chevallier.pub) aux administrateurs des serveurs SSH auxquels on souhaite pouvoir se connecter.

Diffusion de la clé publique

Pour qu’un serveur SSH puisse valider l’identité d’un utilisateur, il doit avoir connaissance de sa clé publique. Se pose alors la question de la diffusion de celle-ci. Bien souvent vous aller envoyer le fichier contenant votre clé publique par mail à l’administrateur du serveur auquel vous souhaitez accéder en SSH. Mais qui vous dit que votre mail ne sera pas intercepté par une personne malintentionnée qui remplacera votre clé-publique par la sienne ? Il ne s’agit pas ici de lancer le débat sur la signature des mails, mais de pointer du doigt les dangers liés à certains canaux de diffusion. Lorsque cela est possible, il vaut mieux privilégier un transfert de type sftp (scp), même si le risque d’interception n’est pas nul.

Pour garantir l’intégrité de la clé publique reçue, nous allons utiliser son fingerprint. Il s’agit d’une sorte de checksum, permettant de vérifier la non altération du contenu d’un fichier lors de sa copie. À la reception d’une clé publique, l’administrateur du serveur SSH va taper la commande suivante pour afficher son fingerprint et le valider par téléphone (ou en personne, c’est encore le plus sûr) auprès de son émetteur :

$ ssh-keygen  -l  -f sebastien-chevallier.pub 
1024 e7:a2:00:a2:ec:e7:0c:b9:01:12:ac:7f:76:18:ef:67 sebastien-chevallier.pub (DSA)

NB : les plus courageux (ou paranoïaques) pourront aussi procéder à la comparaison caractère-à-caractère de la clé publique mais c’est un peu plus long :).

Côté serveur

Une fois assuré de l’authenticité de la clé publique reçue, il faut ajouter son contenu au fichier authorized_keys du compte utilisateur concerné (ici sebchevallier) :

$ cat /path/to/sebastien-chevallier.pub >> /home/sebchevallier/.ssh/authorized_keys

Certaines configurations de serveurs SSH (fichier /etc/ssh_config) sont sensibles aux permissions sur le répertoire ~/.ssh et le fichier authorized_keys qu’il contient. C’est le cas par exemple lorsque le mode StrictModes est activé. Par précaution, nous allons leur affecter les permissions suivantes :

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Sur la plupart des distributions linux, la commande ssh-copy-id permet de simplifier les étapes de diffusion et d’ajout de la clé sur le serveur SSH. Il suffit pour cela d’exécuter la commande suivante depuis le poste client :

$ ssh-copy-id -i ~/.ssh/sebastien-chevallier.pub sebchevallier@demo.domain.tld

NB : Il est fortement déconseillé de faire usage de cette méthode sur des serveurs de production car l’étape de vérification du fingerprint de la clé publique par l’administrateur du serveur n’est pas réalisée. Elle convient par contre très bien à un usage interne, sur des machines de développement par exemple.

Connexion au serveur

La connexion au serveur depuis le poste client s’effectue à l’aide de la commande suivante :

$ ssh -i ~/.ssh/sebastien-chevallier sebchevallier@demo.domain.tld

Aller plus loin

Personnaliser ses connexions SSH

Lors de la génération de la paire de clé, l’option -f a remplacé le nom par defaut de la clé publique (id_dsa) par celui passé en paramètre (sebastien-chevallier), c’est pourquoi il nous faut utiliser l’option -i lors de l’établissement d’une connexion. De plus, il est fastidieux de renseigner à chaque fois le nom d’utilisateur et le serveur auquel on souhaite se connecter. Nous allons donc faire d’une pierre deux coups et remplacer la commande

$ ssh -i ~/.ssh/sebastien-chevallier sebchevallier@demo.domain.tld

par

$ ssh demo

Pour ce faire, il faut éditer le fichier ~/.ssh/config du client et y renseigner la configuration suivante :

Host demo
  HostName demo.domain.tld
  User sebchevallier
  IdentityFile ~/.ssh/sebastien-chevallier

Utiliser le ssh-agent

Vous l’aurez compris, la passphrase joue un rôle essentiel dans le processus l’authentification par clé publique. Le problème c’est que dans l’état actuel, l’utilisateur doit la renseigner à chaque connexion SSH, ce qui est pour le moins pénible. C’est précisémment pour cela que le processus ssh-agent est fait ! Associé à la commande ssh-add, il charge en mémoire la partie privée de la paire de clée et la restitue tout au long de la session lorsque cela est nécessaire. Sous Mac OS, l’agent est intégré avec Keychain donc aucune manipulation supplémentaire n’est requise. Sous Linux, il faut lancer le processus ssh-agent à l’aide de la commande

$ eval `ssh-agent`

si l’on souhaite associer l’agent au shell courant, ou

$ ssh-agent /bin/bash

pour l’exécuter dans un nouveau shell. L’ajout d’une clé privée à la session se fait via la commande ssh-add :

ssh-add  ~/.ssh/sebastien-chevallier
Enter passphrase for /home/sebchevallier/.ssh/sebastien-chevallier:
Identity added: /home/sebchevallier/.ssh/sebastien-chevallier (/home/sebchevallier/.ssh/sebastien-chevallier)

Il est également possible de lister les identités en mémoire et de les supprimer :

$ ssh-add -l
2048 7e:86:0e:89:25:6e:5a:8e:d0:c2:53:0c:4f:a8:23:fb /home/sebchevallier/.ssh/sebastien-chevallier (RSA)
 
$ ssh-add -d ~/.ssh/sebastien-chevallier
Identity removed: /home/sebchevallier/.ssh/sebastien-chevallier (/home/sebchevallier/.ssh/sebastien-chevallier.pub)
 
$ ssh-add -D
All identities removed.

À noter tout de même qu’il est préférable de limiter la durée de la session du ssh-agent (en le relançant à l’aide d’une tâche cron par exemple, ou en indiquant une durée de validité avec l’option -t lors de l’ajout d’une clé avec ssh-add), surtout si vous avez l’habitude d’aller prendre votre café sans verrouiller votre poste de travail ;).

C’est fini pour ce tuto ! Rien de bien compliqué, mais ces quelques manipulations permettent de gagner un temps considérable dans les tâches d’administration courantes. Cependant, si vous souhaitez mettre en oeuvre le processus d’authentification par clé publique pour gérer des plateformes de production, il me semble judicieux de standardiser et/ou automatiser un certains nombre de ces opérations (diffusion des clés publiques, invalidation de passphrase au bout d’une durée déterminée, etc.) et de déporter toute l’infrastructure sur un ou plusieurs serveurs dédiés (on parle alors de bastions). Il peut être alors intéressant d’utiliser la fonctionnalité Agent Forwarding de SSH pour chaîner les authentifications.

Clonage du disque dur

Les quelques aventuriers ayant tenté le passage en force en copiant le fichier image du master ont certainement été confontés à un message de ce type lors de l’import du disque nouvellement créé :

Cannot register the hard disk [...] with UUID [...] because a hard disk [...] with UUID [...] already exists in the media registry [...].

L’UUID (Universal Unique IDentifier), auquel le message fait référence, est en fait une chaîne de caractères alphanumériques permettant d’identifier des périphériques de stockage (plus d’info ici). Cet identifiant étant inscrit dans les métadonnées du disque dur virtuel (fichier .vdi), il est copié en même temps que ce dernier. Lors de l’import de la nouvelle copie, l’unicité des identifiants de périphériques n’est plus respectée, d’où le message d’erreur retourné par VirtualBox.

Heureusement, les développeurs ont pensé à nous ! Plutôt que de modifier l’UUID du nouveau disque à la main, nous allons utiliser la commande VBoxManage associée à l’option clonehd :

VBoxManage clonehd          <uuid>|<filename> <outputfile>
                            [--format VDI|VMDK|VHD|RAW|<other>]
                            [--variant Standard,Fixed,Split2G,Stream,ESX]
                            [--type normal|writethrough|immutable]
                            [--remember] [--existing]

La commande que j’utilise le plus couramment est la plus simple :

$ VBoxManage clonehd /path/to/master.vdi /path/to/clone.vdi

NB : Il est important de spécifier les chemins absolus des disques source et distant.

Une fois la procédure de clonage terminée, le nouveau disque est prêt à l’emploi et peut être utilisé en choisissant l’option « Utiliser un disque existant » lors de la création d’une nouvelle VM. Il ne reste alors plus qu’à démarrer la machine pour la suite des opérations.

Modification du hostname

Le nom d’hôte de la machine est utilisé par certaines opérations réseau et s’affiche sur le prompt d’un utilisateur connecté (bien que ce comportement soit configurable). Vous l’aurez compris, au premier démarrage, le nom d’hôte de la nouvelle VM est celui du master. Pour le modifier il faut éditer le fichier /etc/hostname :

$ echo newhostname > /etc/hostname

NB : on évitera les caractères trop exotiques pour la définition du hostname ;)

L’une des erreurs les plus couramment commises est de s’arrêter là ! En effet, il faut également propager cette modification dans le fichier /etc/hosts de façon à avoir au minimum les déclarations suivantes (en plus de celles pour IPv6) :

127.0.0.1    localhost
127.0.0.1    newhostname.localdomain newhostname

NB : Cette mise à jour est vraiment importante, tant son oubli peut faire perdre du temps. Un exemple typique est l’impossibilité de démarrer le serveur applicatif JBoss. Inutile de dire que le lien de cause à effet n’est pas immédiat et que les erreurs causées par l’omission de cette configuration sont assez difficiles à diagnostiquer (surtout lorsqu’elles surgissent 15 jours plus tard ! ).

Mise à jour des rules udev pour les interfaces réseau

Les distributions basées sur Debian disposent d’une règle udev permettant d’associer de façon pérenne le nom d’une interface réseau logique (ethX) avec l’adresse MAC de la carte correspondante. L’enregistrement des couples ethX/@MAC dans le fichier /etc/udev/rules.d/70-persistent-net.rules permet d’effectuer des opérations physiques sur les interfaces réseaux (ajout, retrait, interversions) sans pertrber la configuration réseau. La règle udev responsable de l’écriture de ces associations est située dans le script /etc/udev/rules.d/75-persistent-net-generator.rules. Les adresses MAC figurant dans le fichier 70-persistent-net.rules étant celles du master, il faut mettre le fichier à jour pour les faire correspondre avec celles de la nouvelle machine. On peut également tout bonnement supprimer ces 2 fichiers, mais cela n’est pas conseillé.

Changez vos mots de passe !

Et oui, les comptes utilisateurs étant les mêmes que ceux configurés sur le master, il est vivement conseillé de modifier au minimum le pass root !!!

Le code

Sans plus attendre, voici le code source de la classe d’accès à la base de données :

package resources;
 
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.logging.Logger;
 
/**
 * Singleton permettant d'accéder à la base de données DerbyDB embarquée.
 * @author Sébastien Chevallier
 */
public class DerbyDB {
 
    public static Logger logger = Logger.getLogger("resources.DerbyDB");
 
    private Connection connection;
    public static DerbyDB resource;
    public static String path;
 
    private DerbyDB() {
        try {
            Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
            String dbUrl = "jdbc:derby:"+path+"FStoSolrDB;create=true";
            Connection tmp = DriverManager.getConnection(dbUrl, "APP", "APP");
            tmp.setAutoCommit(false);
            this.setConnection(tmp);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
 
    public static DerbyDB getResource() {
        if (DerbyDB.resource == null) {
            DerbyDB.resource = new DerbyDB();
        }
        return DerbyDB.resource;
    }
 
    public Connection getConnection() {
        return connection;
    }
 
    public void setConnection(Connection connection) {
        this.connection = connection;
    }
}

Quelques explications

Le projet ne nécessitant pas l’utilisation d’une couche de persistance évoluée, les interactions avec la base de données sont effectuées via l’API JDBC. Le design pattern singleton permet ici d’éviter la multiplication des connexions vers la base tout en rendant la connexion active accessible depuis les différentes classes du projet. J’ai également volontairement désactivé le mode auto-commit via la méthode setAutoCommit() pour des besoins propres à l’application. Dans ce cas, les modifications ne sont effectives qu’après appel à la méthode commit().

Utilisation de la classe DerbyDB

Avant toute chose, il est nécessaire de préciser l’emplacement de la base de données sur le disque dur en renseignant le variable statique DerbyDB.path. L’accès à la ressource est ensuite obtenu en appelant la méthode statique DerbyDB.getResource().

Pour couper court à toute remarque non constructive, je précise que cette classe est un exemple d’utilisation et ne constitue en rien un modèle de développement. Je la met tout de même à disposition en espérant que certains d’entre vous gagneront quelques précieuses minutes !

Le cahier des charges

Ancien utilisateur de Revelation sous Ubuntu, j’ai besoin d’un logiciel qui assure les fonctionnalités suivantes :

• Verrouillage automatique et/ou manuel de la session courante
• Catégorisation des mots de passe
• Copie du mot de passe dans le clipboard en un (double) clic

Pourquoi ne pas continuer avec Revelation ? Tout simplement parce que je souhaite pouvoir accéder à ma base de mots de passe depuis Mac OS, Linux et Windows, pour des raisons de confort assez évidentes. La solution idéale devra donc être déclinée sur ces trois OS (sans parler pour autant de binaire portable).

Inutile de préciser que le logiciel doit également être gratuit et, si possible, Open Source car bizarrement je n’ai pas trop envie de jeter mes mots de passe dans une boîte noire, aussi jolie soit-elle.

Avant de présenter l’heureuse gagnante, je précise que j’ai écarté d’office les solutions en ligne ainsi que les modules Firefox. En effet, si je cherche une solution crossplatform, ce n’est pas pour me limiter à l’utilisation d’un seul navigateur, d’autant plus que je ne l’apprécie pas.

La solution : KeePassX

A l’origine, KeePassX est un portage Linux de KeePass, mais le projet semble voler de ses propres ailes depuis un certain temps. Le logiciel correspond tout à fait à ce que je recherche mais, avant de me lancer, je jette un rapide coup d’oeil sur la dernière news du site, histoire de me rassurer sur la pérennité du projet : 16 Septembre 2009, vendu !

Au passage, voici quelques fonctionnalités supplémentaires du logiciel qui me plaisent bien :

• Authentification par mot de passe principal et/ou clé privée
• Fonction de recherche dans la liste des entrées
• Génération paramétrable de mots de passe
• Drag & Drop des champs champs d’une entrée dans d’autres applications (Linux et Mac OS)
• Possibilité de renseigner la date d’expiration d’un mot de passe
• Jeu d’icônes assez complet
• Effacement du presse papier au bout d’une durée déterminée

Côté interface, rien d’exceptionnel mais cela reste largement utilisable :

Alors, convaincu(e)s ? Et vous, quelles sont les solutions que utilisez pour gérez vos mots de passe ?

Personnellement j’utilise l’application VirtualBox, qui répond parfaitement à mes attentes, ne serait-ce que parce qu’elle est disponible gratuitement pour les 3 plateformes Mac OS X, Linux et Windows. Elle possède cependant quelques lacunes, notamment dans la prise en charge des communications réseau de l’OS hôte vers l’OS invité, qui fait l’objet de ce billet. Les manipulations sont effectuées avec une machine invitée Ubuntu et un hôte Mac OS X, mais s’adaptent (presque) sans problème à des configurations différentes.

Les différents modes d’accès réseau

Comme la plupart des logiciels de virtualisation, VirtualBox propose quatre modes d’accès réseau pour ses machines invitées :

• NAT : le plus courant, il permet à l’OS invité d’accéder au réseau externe de façon transparente. Techniquement, les connexions initiées par la machine guest sont relayées par l’interface réseau de la machine hôte, qui possède une addresse IP sur le réseau externe, selon le principe du NAT (Network Address Translation).
• Accès par pont (bridge) : la carte réseau de l’OS invité possède sa propre addresse IP sur le réseau externe.
• Réseau interne (internal network) : utilisé pour créer un sous-réseau de plusieurs machines virtuelles.
• Accès privé hôte (host-only) : les seules connexions possibles sont celles établies entre la machine hôte et la machine invitée.

Focus sur le mode NAT

Il est souvent nécessaire de pouvoir accéder à Internet depuis la machine invitée, ce qui exclue les deux derniers modes. Le réglage par défaut de la carte réseau étant positionné sur NAT, mettons nous dans la peau de l’utilisateur lambda. Une fois la machine invitée démarrée, on se connecte sur notre site préféré et… ça fonctionne !

Maintenant, supposons que notre utilisateur, qui n’est pas si lambda que ça, dispose d’un serveur Web sur sa machine virtuelle. Comme faire pour s’y connecter avec un navigateur installé sur la machine hôte ? Un ifconfig nous indique que l’adresse IP de la machine virtuelle est 10.0.2.15, mais cette fois-ci la connexion échoue. Hé oui, nous voilà face à un comportement assez pénible de VirtualBox : le NAT ne fonctionne que dans un sens (contrairement aux solutions VMware) ! Le contournement le plus simple consiste à passer en mode bridge car la machine virtuelle possèdera alors sa propre IP sur le réseau, et sera donc considérée comme un client à part entière, au même titre que son hôte. Notons quand même, pour les plus étourdis, que TOUT le traffic réseau passe par la carte physique de la machine hôte, le mode bridge consistant simplement en un dédoublement logiciel de celle-ci (un alias de l’interface réseau en quelque sorte).

Si cette solution répond tout à fait au besoin, elle possède un inconvénient de taille : la machine hôte doit être connectée à un réseau IP. Impossible donc de travailler dans le train, ou tout autre environnement déconnecté. Heureusement pour nous il existe encore deux solutions !

NB : Avant de continuer, un petit point sur l’addressage IP utilisé par le mode NAT s’impose. Toutes les machines configurées pour l’utiliser se voient attribuer l’adresse 10.0.2.15, et peuvent communiquer avec la machine hôte addressée en 10.0.2.2. On se rend compte ici que chacune d’elles est isolée et ne peut donc pas communiquer directement avec ses voisines, à moins de configurer une deuxième interface réseau uilisant le mode internal-network.

L’utilitaire VBoxManage

Si vous utilisez régulièrement VirtualBox vous avez forcémment rencontré cette commande, véritable couteau-suisse de l’application. Le « déblocage » de l’accès au port 80 (http) de la machine invitée depuis la machine hôte s’effectue à l’aide de trois lignes de commande du type :

vboxmanage setextradata "{nom de machine virtuelle}" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/{nom du mapping}/Protocol" TCP
vboxmanage setextradata "{nom de machine virtuelle}" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/{nom du mapping}/GuestPort" 80
vboxmanage setextradata "{nom de machine virtuelle}" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/{nom du mapping}/HostPort" 8080

Je ne vais pas plus loin dans les explications car je n’aime vraiment cette façon de procéder, pour les raisons suivantes :

• La commande est trop difficile à mémoriser et donc peu propice à des interventions d’urgence ;
• En fonction du paramétrage de la carte réseau de la VM, le type de driver passe de pcnet à e1000 ;
• lors de mes tests elle ne fonctionnait plus à partir de 3 ports ouverts (ce qui n’a peut être rien à voir, je n’ai pas investigué davantage).

Si vous souhaitez tout de même utiliser cette commande, toute la documentation nécessaire est disponible sur Internet. De mon côté j’ai opté pour une autre solution, un peu plus geek par contre.

Le retour du tunnel SSH

Ayant prévu de faire un billet dédié au tunneling SSH, je passe directement à la phase pratique. Pour reprendre l’exemple abordé précédemment, voici la procédure de connexion au port 80 de la VM :

1. Sur la VM, on tape la commande suivante en console

   ssh -NfR 8080:localhost:80 username@10.0.2.2

   avec username un compte existant sur la machine hôte. Notez que si cet utilisateur ne dispose pas des privilèges d’administrateur, le premier port indiqué dans la commande doit être >1024.

2. Puis on se connecte, depuis la machine hôte, à l’adresse http://localhost:8080 à l’aide d’un navigateur web :
   

Et… c’est tout ! Vous admettrez que c’est quand même plus simple :) Mais comme rien n’est jamais parfait :

• La méthode présentée ne fonctionne que pour le protocole TCP. Même si cela comprend la grande majorité des cas d’utilisation, cela peut s’évérer insuffisant et il est préférable dans ce cas d’employer la commande VboxManage. Sachez tout de même qu’il existe un contournement pour faire transiter des paquets UDP au travers d’un tunnel SSH, mais il ne sera pas abordé ici. Je n’ai fait aucun test pour ICMP car il semble être mal implémenté au niveau des drivers de VirtualBox, mais suis preneur de toute information intéressante.
• La machine hôte doit disposer d’un serveur SSH. Si cela ne pose pas de problème sur Linux et Mac OS X (Préférences Système > Partage > Session à distance) , les Windowsiens devront s’amuser un peu avec Cygwin.

Le problème c’est que depuis quelques mois je travaille sous Mac OS X et le moins que l’on puisse dire c’est que le support du NTFS n’est pas sa plus grande force. Je récupère donc la dernière version du driver NTFS-3G et en moins de deux minutes me voilà en train d’écrire des données sur mon disque externe. J’ai pourtant oublié un détail, qui m’a valu la perte de deux machines virtuelles hier (inutile de préciser qu’elles n’étaient pas sauvegardées ailleurs).

Rappel des faits

Dans la cadre de mes projets informatiques personnels, je travaille sur un petit parc de machines virtuelles. Faute de place sur mon portable, les images disque de ces machines sont entreposées sur mon fameux disque externe. Tout allait pour le mieux jusqu’à ce qu’une micro-coupure vienne interrompre mon travail en provoquant la déconnexion du disque. Et là c’est le drame ! Une fois le disque reconnecté, impossible de mettre la main sur les images disque des machines virtuelles en activité avant l’incident. Mais comment une si petite coupure a-t-elle pu avaler près de 8Go de données ?

Petit rappel du fonctionnement d’un disque dur

Je n’entrerai pas dans les détails, mais il faut savoir que les disques durs disposent d’un espace servant d’interface entre le mécanisme d’écriture des données sur les plateaux et le système d’exploitation : il s’agit du cache (ou tampon). Lorsqu’il est utilisé en mode write-back il fonctionne un peu à la manière du tapis roulant d’une caisse de supermarché : l’hôte(sse) de caisse, que l’on assimilera au mécanisme d’écriture, prend plus de temps à enregistrer un article que le client n’en met pour le lui tendre. Si la caisse ne dispose pas de tapis roulant, ce dernier doit donc attendre que chaque article soit enregistré avant de passer au suivant. Le temps d’attente est certes très court (quelques secondes tout au plus), mais cela reste du temps perdu et le client aurait bien aimé pouvoir déposer ses articles par lots de façon à profiter du temps d’attente cumulé pour aller chercher le lait oublié à l’autre bout du magasin ou passer un coup de fil (les connaisseurs verront ici une allusion plus ou moins correcte au Time Sharing). C’est précisément le rôle que joue le tapis roulant et donc, par analogie, le cache d’un disque dur. Il s’intercale entre deux processus évoluant à des vitesses différentes de façon à ce que le plus rapide des deux ne soit pas bloqué (il y a des limites quand même car la taille du tampon n’est pas infinie). Lors de l’écriture d’un fichier sur un disque, la vitesse est conditionnée par le déplacement des parties mécaniques (changement de plateau, rotation, etc.). Pour éviter de consommer du temps processeur inutilement, le disque indique au système que les données ont été écrites dès leur réception, mais en réalité il les met en cache pour les traiter plus tard. Du point de vue du système d’exploitation, les données sont donc présentes sur le disque dur. Leur enregistrement ne sera cependant effectif qu’une fois le dernier octet traité par le disque. Si celui-ci est déconnecté avant la fin du processus d’écriture les données seront altérées ou perdues.

Les systèmes de fichiers journalisés et le cache

Il ne faut pas confondre le journal tenu par le système de fichier journalisé et le cache disque. L’objectif d’un système de fichier journalisé (NTFS, Ext3, etc.) est de tenir à jour un journal des opérations à effectuer sur le disque. Ainsi l’écriture d’un document doit se faire selon la séquence :

• inscription dans le journal des actions à effectuer sur les métadonnées et les données (suivant le système de fichiers utilisé),
• écriture sur le disque,
• validation des opérations dans le journal.

La tenue du journal se faisant au moyen d’écritures sur le disque, au même titre que les opérations de la deuxième étape, l’utilisation d’un cache d’écriture ne garantie absolument pas l’ordre d’exécution de la séquence décrite. Les écritures seront effectuées selon des mécanismes d’optimisation, indépendamment de leur ordre d’entrée dans le cache. Pour éviter ce genre de désagrément, le concept de barrière a été introduit dans la couche de gestion des entrées/sorties des disques. Pour plus d’infos je vous laisse consulter la bibliographie à la fin de l’article.

Et la solution dans tout ça ?

Il est effectivement temps de revenir à nos moutons ! Nous avons vu que la méthode d’écriture write-back est la cause de cette perte de données, il suffit donc de la désactiver. La construction des disques imposant l’utilisation du cache, pour simuler sa désactivation il faut utiliser la méthode write-through qui consiste à attendre la fin (réelle cette fois) de l’écriture d’un octet avant de passer à l’envoi du suivant.

Sous Mac OS, ce réglage s’effectue en cliquant sur l’icône NTFS-3G des préférences système. Il est alors possible d’activer ou désactiver le cache via les options « File system caching enabled » pour un réglage global, ou « Disable file system caching » pour une configuration spécifique à un volume.

Enseignements à tirer de cette expérience

On ne le dira jamais assez, il faut sauvegarder régulièrement ses données ! Mais malgré cela on ne peut pas se prémunir de tous les risques alors autant prendre quelques précautions en

• évitant au maximum de travailler directement sur des sources externes susceptibles d’être déconnectées par inadvertance (clés USB, disques externes, etc.) et en préférant les périphériques de stockage réseau (NAS, partage Samba, etc.). A noter quand même qu’un bon ordinateur fixe n’est pas à l’abri de ce genre d’incident et pourrait de la même façon perdre des données en cas de coupure de courant.
• débranchant correctement ses périphériques ! De cette façon on s’assure que toutes les données sont écrites sur le disque de façon pérenne. Sur les versions de Windows à partir d’XP le cache est automatiquement passé en mode write-through pour tous les périphériques externes, mais ce n’est pas une raison pour prendre de mauvaises habitudes et les déconnecter n’importe comment !

Et voilà c’est fini ! Je vais maintenant pouvoir reprendre mon travail sans peur de perdre à nouveau mes machines virtuelles (ouf !).

Bookmarks

Quelques liens qui m’ont permis de me documenter un peu plus sur le sujet. Attention c’est assez technique !

• Write caching improves server performance
• Journal File Systems in Linux
• Write cache horrors
• Discussion about disk caching and journalised filesystems
• Barriers and journaling filesystems