VDN pour les développeurs

Ce document pour éclaircir certains points liés au développement de VDN.

Remarques préalables :

• ce document est mon document de travail, il n'est pas tout le temps très bien organisé.
• dans la suite lorsque je parle de chroot il s'agit systématiquement de fakechroot.
• en ligne de commande, il faut fixer la variable d'environnement NET_DIR avec le répertoire du réseau.
• Un switch VDN n'a pas d’existence réelle ou virtuelle, c'est un simple canal multicast (IP multicast:port) véhiculant les trames Ethernet). Il se comporte comme un HUB (toutes les machines connectées au même switch “voient” tous les échanges.
• Un disque DIRECT ne doit plus être modifié si des disques COW en dépendent.

VDN devra avoir été installé pour fonctionner en mode “natif” si vous souhaitez générer un environnement chroot.

L'installation en mode natif (par opposition au mode chroot) n'est actuellement prévu que pour Debian Stretch (voir le script vdn-prepare-debian).

En mode chroot, toutes les fonctions de VDN sont accessibles à l'exception de celle permettant de modifier facilement l'environnement chroot.

La configuration des systèmes virtuels est libre du moment :

• qu'ils puissent être lancés par KVM (ou QEMU).
• qu'ils soient compatibles avec des adresses MAC et une adresse IP publiques virtuelles dynamiques, autrement dit qui changent à chaque exécution du système(*).

Ils seront tous isolés au niveau réseau par VDN.

L'intégration d'une machine virtuelle dans le réseau réel de la machine hôte est également prévue via l'interface supplémentaire automatiquement ajoutée aux systèmes virtuels (la dernière).

Cette intégration utilise le logiciel slirp présent dans KVM/QEMU et permet de joindre les services des machines virtuelles par un jeu de redirections. Le logiciel slirp permet également à un système virtuel de joindre l'hôte (à l'adresse IP : 10.0.2.2), d'utiliser le DNS de l'hôte (adresse IP : 10.0.2.3).

(*) : Cela est problématique pour un serveur DHCP ou DNS (voir Hooks)

La configuration des réseaux virtuels est libre en tenant compte des particularités suivantes :

• les machines virtuelles ont des adresses MAC et IP_PUBLIC régénérées à chaque démarrage.
• les réseaux entre machines virtuels sont constitués d'un ensemble de canaux multicasts (IP multicast,port). Un canal par switch virtuel. Ces switchs imaginaires se comportent en fait plus comme des hubs.
• toute machine virtuelle peut ouvrir un passage vers le réseau réel de l'hôte pour joindre la machine hôte et/ou bénéficier de tous ses services (cf. Les systèmes virtuels)

L'interface graphique de VDN ne fait qu'utiliser la ligne de commande, rien de plus. L'interface graphique n'est absolument pas nécessaire pour utiliser VDN, elle n'apporte qu'une ergonomie permettant la prise en main rapide des réseaux.

Elle est construite principalement en ruby/Gtk2 avec les modules rsvg2, vte. Pour la partie VNC python est utilisé.

Rassembler l'ensemble des modules utilisés peut s'avérer complexe sur certaines distributions et c'est principalement pour cette raison que VDN à du être “emballée” dans un environnement chroot pour être portable.

Les fonctionnalités de VDN sont toutes dans ses commandes.

Ce que prends en charge les commandes VDN :

• Déterminer un identificateur unique pour chaque système virtuel qui est utilisé pour l'attribution des adresses MAC et IP publique sur l'internet virtuel.
• Allouer les ressources nécessaire aux systèmes virtuels (création de fichier de swap, de fichiers COW, …)
• Prendre en charge la construction de la ligne de commande de l'émulateur en intégrant :
  • les identificateurs uniques permettant d'identifier le système virtuel.
  • les canaux multicast utilisés
• Gérer (nettoyer/démarrer/arrêter/…) les systèmes
• Gérer les réseaux (nettoyer/construire/…) les réseaux

VDN est tout petit mais utilise de nombreuses commandes Unix (bash, tar, cp, …), de nombreuses bibliothèques logicielles, une interface graphique dont certains modules ne sont pas fourni par les distributions (et qui nécessitent une recompilation).

Le casse tête de la portabilité de VDN à été résolue par une isolation la plus légère possible d'un environnement d'exécution complet de VDN généré sur la machine de développement et proposé au téléchargement avec le logiciel VDN.

La solution développée est basée sur la commande fakechroot (qui elle est packagée par toutes les grandes distributions GNU/Linux).

Le script vdn-tests-build-chroot construit l'environnement chroot en exécutant un scénario d'exécution de VDN sollicitant les principales fonctionnalités de la ligne de commande et de l'interface graphique. Le scénario est exécuté sous strace afin de capter les appels systèmes relatifs aux fichiers. La liste des fichiers obtenue constitue le répertoire chroot.

Avantage d'une exécution en chroot

• toutes les fonctionnalités de VDN fonctionneront sur tous les GNU/Linux possédant fakechroot et wget.
• peu insensible aux évolutions du système (si l'environnement chroot fonctionne, il fonctionnera jusqu'à une évolution majeure de fakechoot, du formats des exécutables et/ou bibliothèques ou bien encore si des appels systèmes disparaissent de noyau ce qui n'est pas fréquent).

Inconvénients :

• Occupe 200 Mo sur le disque.
• Ajouter des fichiers compilés à l'environnement chroot sans devoir le régénérer est complexe en raison de ses éventuelles dépendances à inclure.

Cette commande ne peut être exécutée que si VDN est installé pour fonctionner “nativement”.

Dans le répertoire vdn/tests exécutez :

vdn-test-build-chroot

Patientez 5mn. Ne soyez pas surpris, après quelques tests préliminaire des fenêtres de l'interface graphique s'ouvrent afin de tracer leurs appels systèmes.

Les tests ne modifient en rien les réseaux de l'utilisateur (des réseaux temporaires sont utilisés).

Le résultat est un répertoire vdn/chroot et une archive vdn/chroot.tgz.

Un système souche est construit par l'enseignant sur ses quotas disques. Un ou plusieurs systèmes COW pourront être construit “au dessus” par les étudiants.

Dans le cas de systèmes TGZ, le système souche doit en plus être adapté et pour l'instant la procédure n'est définie que pour Debian.

Le réseaux zoo regroupe les systèmes souches. En ajouter un est simple, il suffit d'adapter le script de construction du réseau et de reconstruire le réseau.

Avec l'interface graphique :

Onglet Graph → More… → Edit netowrk script… Onglet Graph → More… → (Re)build network…

En ligne de commande (cf. remarque)

vi $NET_DIR/build
vdn-build-network

Avec l'interface graphique :

Onglet Graph, sélectionner la machine, bouton droit → Start

En ligne de commande (cf. remarque)

vdn-start nomDuSystem
vdn-vnc-viewer nomDuSystem

Il vous faut un système souche (il suffit qu'il soit accessible en lecture seule)

Le système COW avec sa variable MODE à “cow”

Ce système souche est un système souche Debian sur lequel on effectue les modifications nécessaires. Ces modifications ne l'empêcheront aucunement de se comporter comme un système DIRECT ou COW. Elles permettent juste à des systèmes TGZ de l'utiliser comme système souche.

Démarrer le système souche Debian et une fois connecté root effectuer manuellement les opérations suivantes :

• Autoriser la connexion, à partir de l'hôte, vers le compte root avec authentification clés.

A effectuer sous le compte root du système souche

sed -i -re 's/^.*PermitRootLogin.*$/PermitRootLogin yes/' /tmp/d/etc/ssh/sshd_config
systemctl restart sshd

Puis sous le compte utilisateur sur l'hôte :

cd vdn/networks/zoo
export NET_DIR=.
vdn/distrib/debian/stretch/prepare.sh

Le mot de passe root sur la machine virtuel vous sera demandé pour la dernière fois.

Vérifiez que ./prepare.sh se termine en affichant la ligne “done” car il s'arrête à la moindre erreur rencontrée.

La Debian minimaliste acceptant les systèmes de type TGZ doit maintenant posséder les paquets nécessaire aux TP.

vdn/distrib/debian/stretch/apt-get.sh

Les machines du réseau “demo” fournis avec VDN peuvent maintenant être démarrées