Guide d'utilisation de Virtual Didactic Network (VDN)

VDN est un logiciel conçu pour permettre à des étudiants de créer, utiliser, configurer, casser et réparer, autant de réseaux virtuels de systèmes virtuels que nécessaire et cela tout au long de leur formation s'étalant sur plusieurs mois.

Cette notion de virtualisation de réseaux/systèmes à beaucoup d'avantages (permettre aux étudiants d'être administrateur d'un réseau par exemple) et peu d'inconvénients (la solution virtuelle s'écarte quelque fois, à la marge, de la réalité, cf. particularité des réseaux/systèmes dans VDN).

En étant administrateur (et propriétaire) de leurs systèmes (voir de leurs réseaux) virtuels les étudiants vont pouvoir se former :

• aux “systèmes” : l'initialisation d'un système, le partitionnement de disques, la gestion d'utilisateurs, l'écriture de scripts d'administration, la création de modules noyau, la création de systèmes embarqués…
• aux “réseaux” : la mise en oeuvre de tous types de services réseaux (NFS, DHCP, SSH, …, voir par exemple wikibook), à l'analyse de trames, …
• au développement : développer et tester des modules “noyau” sans risquer de “geler” la machine hôte.

Tous ces apprentissages nécessitent les droits administrateurs or nos étudiants :

• ne sont jamais “root” sur les machines de salles de TP
• ne disposent que de peu d'espace disque

VDN répond à ces deux contraintes en mariant la virtualisation et le principe du LiveCD (avec sauvegarde des modifications) pour les 3 types d'utilisateurs suivants :

• l'administrateur des systèmes hôtes. Son rôle est uniquement d'installer les logiciels (paquets Debian et éventuellement l'environnement d'exécution complet fourni) dont dépend VDN, configurer KVM (accès à /dev/kvm), et éventuellement l'interface réseau loopback. Idem sur une machine personnelle sous Debian.

• l'enseignant. Son rôle est de préparer le réseau virtuel et le disque virtuel utilisés par les étudiants (des réseaux virtuels et un disque virtuel Debian contenant de nombreux logiciels et services réseaux sont fournis). Ils peuvent bien évidemment être “étendus”.

• l'étudiant. Son rôle est de configurer ses systèmes virtuels. Les sujets de travaux pratiques du Wikibook Administration réseau sous Linux peuvent servir d'exercices (consultez les spécificités pour les cas particuliers comme NFS, DHCP et DNS.

En résumé, avec VDN :

• l'administrateur du système n'a qu'à préparer la machine (à faire une fois pour toutes sur toutes les machines réelles).
• l'enseignant installe VDN dans un répertoire qu'il partagera avec ses étudiants (en lecture seulement). Ensuite, soit il utilise les réseaux et disques fournis, soit il prépare les siens.
• l'étudiant, via le répertoire VDN de l'enseignant partagé en lecture seule, va pouvoir disposer des réseaux. Les modifications faites seront sauvegardée (de façon très compactes dans le cas de petites modifications des systèmes) dans son répertoire personnel.

Sur votre machine personnelle vous serez amener à jouer les trois rôles.

Chacun de ces 3 types d'utilisateurs dispose d'une partie spécifique dans ce document :

1. Téléchargement et installation de VDN (plutôt pour l'administrateur).
2. Utilisation de VDN (guide de démarrage pour l'étudiant).
3. Administration de VDN (plutôt pour les enseignants souhaitant adapter le réseau et le disque virtuel fournis).

VDN est distribuée sous licence GPL V3 en espérant qu'il puisse servir à “optimiser” l'apprentissage des “Systèmes” et des “Réseaux”. L'équipe de développement n'a malheureusement que peu de temps à consacrer à VDN.

Pour fonctionner VDN nécessite :

• que VDN soit téléchargé et installé (si si)
• que les instructions de virtualisation du processeur soient :
  • activées au niveau du BIOS/UEFI
  • accessibles à l'utilisateur
• qu'un les dépendances logicielles soient téléchargées (200 Mo)
• qu'un disque virtuel et ses fichiers (noyau) soient téléchargés (8 Go)

La commande vdn-install vous guide pas à pas dans l'enchaînement de ces commandes. Elle effectue des tests, vous propose éventuellement plusieurs types d'installation, et pour les problèmes courants vous propose (à root en général) d'effectuer des actions pour y remédier.

Si les commandes git, wget, fakeroot sont absentes, l'administrateur du système doit au préalable les installer.

exemple sous root sur Debian : apt-get install git-core wget fakeroot

Ensuite sur le compte de l'utilisateur :

• Récupérer VDN (moins de 1 Mo):

git clone http://opale.u-clermont1.fr/vdn/git/vdn.git

sur le compte de l'utilisateur :

en tant qu'utilisateur lambda, lancer l'assistant de configuration :

 vdn/bin/vdn-assistant

Des questions vous sont posées, choisissez les choix par défaut et/ou sollicitez “root” lorsque qu'indiqué.

A l'issue l'interface graphique se lance. Il vous reste à télécharger le disque virtuel utilisé par les machines des réseaux. Pour cela :

La commande suivante, à exécuter sous le compte root, vous proposera l'installation des paquets Debian nécessaires à l'utilisation de VDN. C'est la seule commande qui devra être lancé par l'administrateur du système.

vdn/bin/vdn-prepare

Si votre système n'est pas une Debian stretch VDN devra fonctionner dans un environnement chrooté contenant tous les fichiers nécessaires à VDN.

Pour cela, l'administrateur du système devra au préalable avoir installé les paquets très standard fakechroot et wget de sa distribution.

A sa première exécution par un utilisateur la commande vdn/bin/vdn propose dans le cas d'une exécution dans un environnement chrooté le téléchargement de l'environnement chroot (environ 300 Mo). Acceptez.

Dans tous les cas (environnement chrooté ou non) d'éventuelles questions supplémentaire vous seront posées. Le choix par défaut convient généralement.

A l'issue de la post installation, la fenêtre VDN s'ouvre.

Il vous reste à choisir un réseau et à télécharger ses disques comme expliqué ci-dessous.

En téléchargeant VDN vous téléchargez le logiciel lui même ainsi que la définition de quelques réseaux. Il vous reste à télécharger les disques virtuels associés au(x) réseau(x) de votre choix.

Pour cela, vous pouvez :

• via l'interface graphique, ouvrir le réseau de votre choix, sélectionner toutes les machines du réseau puis clic bouton droit → More… → Download cdrom(s) and/or disk(s)

Ou bien,

• via la ligne de commande :

cd vdn/networks/nomDuRéseau
export NET_DIR=.
vdn-download-disks

Idem mais dans un répertoire partagé (une seule installation de vdn pour une centaine d'utilisateurs). Chaque machine devra cependant posséder les dépendances logicielles; l'administrateur devra exécuter une fois la commande suivante sur chaque machine. :

sudo vdn/bin/vdn-prepare-debian

VDN est distribué avec les réseaux décrits ci-dessous. Pour éviter de multiplier les disques virtuels tous ces réseaux sont constitués de machines Debian stretch.

Le réseau “démo” propose un petit réseau d'entreprise constitué des machines suivantes :

• societe : c'est le point d'entrée du réseau via Internet. Un pare-feu pourra (devra !) être installé sur cette machine pour la gestion d'une DMZ (zone démilitarisée) et le contrôle des accès au réseau interne.
• web : machine de la DMZ hébergeant un serveur Web consultable à partir d'Internet et du réseau local.
• bigboss : machine du réseau interne hébergeant des services (NFS, Samba, …)
• tiny : Un poste de travail du réseau interne utilisant les services fournis par les autres machines.
• nomade : cette machine, bien que située physiquement à l'extérieur de l'entreprise, devra pouvoir s'insérer dans le réseau interne via un VPN (Virtual Private Network).
• lambda : cette machine n'est pas sensé faire partie du réseau de l'entreprise. Elle pourra être utilisée pour tester les accès à Internet à partir et à destination des machines du réseau de l'entreprise.

Dans ce chapitre nous précisons le minimum à savoir pour utiliser VDN (démarrage, sauvegarde et arrêt des machines virtuelles) dans le cas des réseaux “demo” et “routing”. Nous vous invitons à lire attentivement le chapitre suivant qui présente les particularités des systèmes virtuels que vous allez manipuler (ce serait dommage que vous les “explosiez” ;))

Dans la suite de ce document, nous désignons par système hôte (ou plus simplement hôte) le système sur lequel s'exécutent les systèmes virtuels.

VDN propose des systèmes virtuels Debian quelque peu modifiés pour minimiser la taille occupée sur le disque par la sauvegarde des modifications effectuées (vos quotas disque sont limités !). Les systèmes virtuels utilisent le principe des LiveCD ; ils utilisent un disque en lecture seule et les modifications sont stockées en mémoire vive jusqu'a l'arrêt “propre” du système via les commandes save, halt ou reboot.

Autrement dit, si vous “tuez” brutalement un système en cliquant sur la croix de la console associée la sauvegarde des modifications ne sera pas effectuée !

Une autre conséquence du fait que les modifications soient effectuées en mémoire vive est qu'il est très fortement déconseillé d'installer des logiciels dans vos systèmes virtuels. Vous risquez en effet de faire “exploser” votre système et/ou votre quota disque ! Normalement, tous les logiciels nécessaires aux travaux pratiques sont déjà installés.

Une dernière particularité des systèmes virtuels proposés est la présence d'une interface réseau supplémentaire (adresse IP 10.0.2.X). Cette interface est utilisée par VDN pour différents usages. L'usage le plus visible pour l'utilisateur est la capacité à se connecter par ssh, sans identification, à partir de l'hôte vers toutes les machines virtuelles. Ignorez cette interface (et évitez de la filtrer avec votre pare-feu “virtuel” !).

En lançant la commande bin/vdn vous démarrez VDN et :

1. Le chemin des éxecutables de VDN est ajouté à votre PATH dans votre fichier ~/.bashrc. Vous n'aurez donc plus besoin de précisez le chemin complet des commandes VDN dans tous les nouveaux shells.
2. Un couple de clés SSH DSA, est généré si vous n'en aviez pas déja. Votre clé publique sera ajouté au fichier /root/.ssh/authorized_keys des systèmes virtuels. Vous pourrez ainsi vous connecter par ssh sans identification sur les systèmes virtuels.

Si VDN démarre correctement vous obtenez la fenêtre principale de VDN composée des onglets suivants :

Onglet	Description
Documentation	La documentation de VDN ou, si un réseau est “ouvert”, la documentation du réseau.
Graph	La représentation graphique du réseau à partir de laquelle il est possible de sélectionner des machines et d'appliquer des actions.
Consoles	Chaque système virtuel VDN possèdera une unique console (liaison série virtuelle ou écran VNC). Une console (liaison série virtuelle) servira de dernier secours si les consoles ssh ne fonctionnent plus.
Ssh

Remarque :

Si vous débutez en administration de réseaux vous allez peut-être être surpris par toutes ces fenêtres (consoles, ssh) à gérer. Pas de panique, il suffit de changer de bureau (CTRL ALT Flèche Droite). Sur ce nouveau bureau ouvrez plusieurs terminaux et connectez-vous aux systèmes virtuels via la commande :

vdn-ssh root@nomDuSystèmeVirtuel # (exemple vdn-ssh root@bigboss).

Ouvrez autant de connexion ssh que bon vous semble (une pour la doc, une pour le fichier de config, une pour relancer le service, une pour surveiller les logs, …) mais gardez les consoles de démarrage en l'état. Elles ne vous seront utiles qu'en cas de perte de réseau.

Après les onglets voiçi une description des menus “Networks” et “Scripts”.

• Ouvrez un réseau, puis basculez sous l'onglet “Graph” et sélectionnez (à la souris) les stations que vous souhaitez démarrer.
• Cliquez sur le bouton droit de la souris pour faire apparaître le menu des “actions” et sélectionnez l'item “Start”

Au démarrage d'une machine virtuelle l'onglet “Console” devient actif et une console virtuelle (pour surveiller le processus d'amorçage est lancée). Pour rappel, cette console ne vous sera utile que dans le cas où les consoles “ssh” ne répondent plus.

Une fois les machines démarrées, basculez sur l'onglet “Ssh” et cliquez sur le bouton nommé du nom d'une machine que vous venez de démarrer. Un terminal graphique effectuant la commande ssh -X root@nomStation se lance et vous permet d'être root sur le système virtuel.

Ouvrez autant de connexions ssh que bon vous semble (une pour la doc, une pour le fichier de config, une pour relancer le service, une pour surveiller les logs, …) mais gardez les consoles de démarrage en l'état. Elles ne vous seront utiles qu'en cas de perte de réseau.

L' état “démarré” ou “arrêté” d'une machine virtuelle est observable dans l'onglet graphe via le classique code des couleurs suivant :

• rouge : la machine virtuelle n'est pas en fonctionnement.
• vert : la machine virtuelle est en fonctionnement.

L'arrêt d'un système virtuel doit s'effectuer via le menu des “Actions” (onglet “Graph”, sélection des systèmes à arrêter, bouton droit → “Halt”).

Lors de cet arrêt, la sauvegarde des fichiers modifiés du système est effectuée dans ~/vdn-save (cf. ci-dessous : Sauvegardes des différences).

Le répertoire ~/vdn-save accueil la sauvegarde des systèmes de type TGZ ou COW.

• Migrer la sauvegarde de tous les réseaux d'une machine possédant VDN à une autre (par exemple machine de TP à machine perso ou vice versa) consiste juste à copier le répertoire ~/vdn-save.

• Faire une capture d'un état des réseaux consiste à copier le répertoire ~/vdn-save en le restaurant pour retrouver l'état originel.

Le tableau suivant décrit le rôle des différentes entrées du menu “Actions” :

Attention, lisez bien les notes indiquées car aucune demande de confirmation n'est effectuée !

En ouvrant le menu scripts vous accédez aux scripts du réseau. Ces scripts permettent de préconfigurer le réseau (et/ou de tester) le réseau.

Remarque : les scripts d'un réseau sont dans vdn/networks/nomDuRéseau/scripts. Vous pouvez les consulter !

Il est possible d'exécuter une (ou plusieurs) application graphique sur un système virtuel et de recevoir ses fenêtres sur l'écran de l'hôte. Il suffit simplement d'exécuter l'application (firefox, whireshark, nautilus, …) dans un terminal de l'onglet “Ssh” ou dans un terminal de votre choix exécutant une commande du type :

vdn-ssh -X login@machine # Le -X autorisant le relai des fenêtres graphiques. 

Que vous soyez un simple amateur curieux de la configuration des systèmes d'exploitation et des réseaux ou un étudiant forcé de taper des lignes de commandes sachez que normalement vous ne pouvez rien “casser” sur l'hôte donc amusez-vous bien !

En cas de problèmes, consultez la FAQ et la section Bogues. Pour installer VDN sur votre Debian stretch (64 bits avec instructions de virtualisation activées) consulter ”Téléchargement et installation“.

Dans cette partie nous nous intéressons aux points permettant de modifier la configuration des machines virtuelles, des réseaux virtuels, des disques virtuels afin que vous puissiez adapter VDN à vos besoins : nouveaux services/logiciels, nouvelles machines virtuelles, nouvelles interconnexions des machines virtuelles, nouveaux réseaux virtuels, nouveaux disques virtuels…

Cette partie n'est pas couverte par l'interface graphique et sera réalisée par des commandes shell (ou des scripts shell) utilisant des commandes vdn ainsi que par l'édition de fichiers de configuration.

Vous trouverez dans la section ”Opérations classiques“ des exemples pratiques d'utilisation des commandes présentées ci-dessous.

Le script de configuration global exécuté par défaut au lancement de VDN (et de toutes ses commandes) est config.rc.

Si l'utilisateur à défini un script ~/.vdnrc il sera exécuté après config.rc. Toutes les variables peuvent donc être redéfinies.

Un réseau est un sous répertoire du répertoire networks. Les fichiers de ce répertoire sont :

Le réseau “courant” est le réseau dont le chemin est précisé dans la variable d'environnement NET_DIR ou, à défaut, le dernier réseau ouvert par la commande vdn (interface graphique).

La commande vdn-build-network utilisera le script build pour construire les fichiers de configuration des systèmes virtuels.

La commande vdn-show montrera les caractéristiques des systèmes virtuels.

La commande vdn-graph construira le graphique graph.svg.

Le fichier de configuration d'une machine est généré par le script build du répertoire de son réseau. Les valeurs utilisées par défaut sont celles du fichier vdn/config.template.

Plutôt que d'éditer “à la main” les fichiers nomDuSystème.conf modifiez plutôt le script de construction du réseau et régénérez les fichiers des systèmes via la commande :

vdn-build-network nomDuReséau

Pour chaque système la fonction build du script construit le fichier nomDuSystem.conf (vdn-build) à partir du fichier config.template et affecte un identificateur unique pour le système (variable IDENT).

Par la suite seules les variables qui doivent différer du fichier de configuration sont modifiées dans la fonction build.

Après avoir (re)construit le réseau (vdn-build-network) la commande vdn-show affichera une synthèse des caractéristiques du réseau afin de vérifier la cohérence de l'ensemble.

L'image du graphe du réseaux générée est graph.svgz et est visualisable par tout lecteur d'image (eog par exemple).

Les fichiers de swap des machines (de SWAP_SIZE Mo) sont stockés dans /tmp.

Le fichier utilisé pour l'union est également stocké dans /tmp.

Le tableau des affectations des variables NETWORKS montre les interconnexions des machines. Le récapitulatif GUESTS(ETH) permet également d'obtenir les connexions des machines aux différents switchs virtuels.

Les redirections de ports sont également affichées, ainsi que les services qui seront activer.

Dans cette partie nous détaillons les particularités des systèmes gérés par VDN. Si vous vous posez des questions quant aux choix faits ne perdez pas de vue que nous devions prendre en compte les contraintes fortes suivantes :

• un utilisateur (étudiant et enseignant) n'est jamais “root” sur la machine hôte.
• l'espace disque (quotas disques obligent) est très limité.

D'autres contraintes comme la simplicité d'utilisation pour l'étudiant et l'enseignant ont également guidé certains choix.

VDN est conçu pour simplifer à la fois la mise en oeuvre de travaux pratiques de “Systèmes d'exploitation” et de travaux pratiques de “Réseaux”. Ces deux types de travaux pratiques, utilisent tous deux la virtualisation mais n'ont pas les mêmes besoins en disques.

En ce qui concerne la gestion des disques virtuels (à un disque virtuel est associé un unique fichier sur le système hôte), trois techniques (ou stratégies) différentes sont possibles :

• l'accès direct. Dans ce cas, l'utilisateur possède son propre disque virtuel. Ce disque occupera généralement plusieurs Go et, quotas obligent, ne pourra être placé que dans le répertoire /tmp avec une persistance égale à la durée du TP. Cette stratégie est la plus adaptée à la mise en oeuvre de travaux pratique d'installation “à partir de rien” d'un système d'exploitation. Si le fait de perdre le système d'exploitation installé est gènant il reste possible de lui fournir un système de type “COW” (cf. ci-dessous) pour les séances suivantes.

• Le partage de disque de type “COW” . Cette technique de “Copy On Write”, permet d'enregistrer dans un fichier, appartenant à l'utilisateur, uniquement les blocs modifiés d'un disque virtuel accédé en lecture seule. Ainsi, à condition de fournir un disque virtuel préparé à l'avance et partagé en lecture seule à destination de tous les étudiants il est possible de diminuer considérablement l'espace disque occupé dans le compte de l'utilisateur. L'espace disque occupé par le fichier COW des différences dépend bien évidemment des modifications effectuées (de quelques Mo à quelques Go). Cette technique de partage d'un disque est la plus adaptée aux TP d'installation “lourdes” d'un système d'exploitation (installation d'un système en double amorçage à partir d'un disque virtuel fourni contenant déjà système, installations et tests de logiciels,…). La persistance des modifications entre deux séries de travaux pratiques pourra, si les modifications ne sont pas trop lourdes, être assuré simplement en spécifiant le chemin du fichier COW des modifications dans l'espace disque de l'utilisateur (sous son HOME). Si les quotas disques sont trop limités il est possible de pas assurer la persistance en spécifiant le chemin du fichier COW des modifications sous /tmp.

• Le partage de disque de type “LiveCD”. Cette technique utilisée pour les LiveCD a été adaptée dans VDN pour le système Debian stable (uniquement). Comme pour la technique COW, un disque virtuel préparé à l'avance et accédé en lecture seule sert de base. Cependant ce sont les fichiers modifiés qui seront enregistrés dans un fichier appartenant à l'utilisateur. Comme pour la technique COW décrite ci-dessus, la persistance des modifications dépend du chemin du fichier enregistrant les modifications. Cette technique à l'avantage d'être très économe en espace disque dans le cas de modifications minimes du système de fichiers original et est donc bien adaptée à la configuration de services réseaux (consistant à modifier quelques fichiers de configuration).

Pour aiguiller le choix d'un type de partage (COW ou LiveCD) voiçi une comparaison plus détaillée des deux :

Comme indiqué précédemment, la technique de sauvegarde des différences “COW” s'effectue au niveau des blocs du disque virtuel. Cette technique à l'avantage d'être très générique et transparente pour le système virtuel (qui n'a donc pas besoin d'être adapté).

Cependant la technique de sauvegarde des différences “COW“ ne permet pas de :

• modifier le disque virtuel une fois que des fichiers de différences sont créés. Du coup, si une série de travaux pratiques doit être effectuée à l'aide du même système virtuel il faudra avoir prévu l'ensemble des logiciels dès le premier TP sous peine de devoir faire installer le(s) logiciel(s) manquant(s) dans tous les systèmes virtuels (plusieurs centaines dans notre cas) ce qui aura pour effet de faire grossir considérablement la taille du fichier enregistant les différences de tous les systèmes, amenant des problèmes de dépassement de quotas.

• différencier l'amorçage initial des différents systèmes. Autrement dit, les services installés le seront pour tous les systèmes virtuels. A charqe à chaque système virtuel de les désinstaller ou d'empêcher de les activer à l'initialisation.

• spécifier finement les “blocs” à sauvegarder. du coup, tous les blocs inutilisés (créés notamment par les fichiers temporaires) seront sauvegardés. Les fichiers COW de sauvegarde des différences occupe de base quelques Mo et sa taille ne cessera de croitre.

La technique du LiveCD (dont s'inspire VDN) lève les contraintes précédentes en permettant :

• d'ajouter des logiciels entre deux travaux pratiques d'une même série et de façon plus générale de modifier le système de fichiers.
• de différencier l'amorçage des systèmes. En fait un système virtuel utilisant la technique du LiveCD ne démarrera que les services explicitement spécifiés (dans une variable).
• d'optimiser l'espace utiliser pour la sauvegarde des différences. En effet, la sauvegarde s'effectuant au niveau des “fichiers” et non des “blocs”, aucun bloc inutilisé n'est sauvegardé. De plus il est possible de spécifier les fichiers à ne pas sauvegarder (/tmp/* par exemple).

Cependant la technique du LiveCD à les désavantages suivants :

• Nécessite une adaptation non triviale du système virtuel (argument du noyau, initramfs, procédure d'amorçage,…) et n'est actuellement prévue que pour Debian stable.

• Est inadaptée lorsque la taille des modifications dépasse quelques Mo (sauvegarde et restauration lente).

En résumé :

L'émulateur de référence dans VDN est KVM. Cependant l'émulateur QEMU peut également être utilisé dans le cas de machines ne disposant pas de processeur doté d'instructions de virtualisation ou dans le cas ou le système virtuel est d'une architecture autre que x86_64.

L'émulateur à utiliser est à préciser dans la variable EMULATOR. Exemple :

EMULATOR=“kvm”

VDN prévoit la gestion de certaines particularités des émulateurs (modèle de disque, type d'affichage, …) et prévoit également le cas de l'usage d'une commande personnalisée quelconque via la variable KVM_CMD. Cette variable permet de personnaliser complètement la ligne de commande utilisée pour démarrer le système virtuel (et notamment de spécifier par exemple l'émulateur qemu-system-arm dans le cas d'un système sous architecture armel).

Dans certains cas il peut être intéressant qu'un système virtuel utilise un second disque virtuel (cf. le réseau ha). VDN permet de spécifié ce second disque virtuel via les variables :

HDB="filename"
HDB_SIZE="50"

Ce second disque virtuel sera créé au démarrage de la machine s'il n'existe pas. A charge au système virtuel de le partitionner.

Les systèmes de type COW ou DIRECT accepte l'emplacement d'une image ISO via la variable CDROM (un fichier spécial du genre /dev/cdrom peut également être précisé). Si vous souhaitez que le système s'amorce sur le CDROM fixez la variable BOOT_CDROM à 1. Dans l'interface graphique il est possible de démarrer sur le cédérom associé au système ou sur tout autre cédérom présent.

Dans le cas d'un réseau composé de nombreuses machines et/ou de machines devant être dotées de beaucoup de RAM il est recommandé (voir indispensable) d'utiliser un espace d'échange (swap). La variable SWAP_SIZE permet de spécifié sa taille (en Mo).

Cet espace d'échange utilise le 4ème disque dans le cas d'un système “DIRECT” ou d'un système “COW”. A charge au système de formater le disque et à ajouter le swap au système. Exemple sous GNU/Linux :

mkswap /dev/sdc
swapon /dev/sdc

Dans le cas d'un système “LiveCD” le swap précisé dans la variable SWAP_SIZE est automatiquement ajouté lors de l'initialisation du système.

Ce chapitre décrit les deux types de réseaux utilisés par VDN :

• le réseau entre les machines virtuelles
• le réseau entre l'hôte et les machines virtuelles

Dans VDN la solution retenue, pour les échanges avec l'hôte, est d'utiliser slirp, un émulateur TCP/IP ne nécessitant pas d'être root. En contrepartie le débit ne dépasse pas les 300 KB par seconde, ralentissant notamment le chargement/déchargement de la sauvegarde.

Pour les échanges entre systèmes virtuels VDN utilise ce que proposent tous les émulateurs : le multicast. La technique du multicast à l'avantage d'être très portable entre émulateurs (il sera simple d'intégrer dans un réseau un système autre que Debian, émulé éventuellement par un autre émulateur) et ne nécessite pas non plus d'être root. Enfin, contrairement à d'autres solutions de transport, la technique de la diffusion permet de se passer de switchs virtuels (vde ou autres). Intégrer des switchs virtuels (en mode utilisateur !) serait une extension possible mais compliquerait le code de VDN. La portée d'un réseau virtuel est donc la portée d'une trame multicast (le réseau local réel au moins).

Sur le schéma du réseau apparaissent les connexions entre les machines virtuelles. VDN (via la fonction computeNetworks du script bin/functions.sh) se charge de définir automatiquement un certain nombre de paramètres (comme l'adresse MAC de chaque carte notamment) mais ne prend pas en charge la configuration IP. Les adresse IP apparaissant sur le graphique ne sont là que comme de simples annotations. L'administrateur du système virtuel (vous) devra fixer les adresses IP des interfaces réseau. De même, chaque système doit explicitement fixer son nom d'hôte (sauf si la variables SET_HOSTNAME du fichier de configuration est fixé à 1).

Comment choisir les adresses IP ? Les IP sont libres à l'exception de celles utilisées sur le réseau Internet virtuel. Le réseau Internet virtuel est partagé par toutes les machines virtuelles de tous les hôtes. Pour éviter les conflits d'IP VDN réserve pour chaque machine virtuelle une unique adresse IP (variable PUBLIC_IP) qui peut être affichée via l'action “Infos” du menu ou via la commande vdn-infos. C'est cette adresse que vous devrez utiliser pour connecter la machine virtuelle sur le réseau Internet virtuel.

Le réseau initial, vierge de toute configuration, peut rapidemment obtenir une configuration de base à l'aide de scripts comme ceux présents dans le sous répertoire scripts. Notamment la prise en charge de l'IP publique et du réseau Internet virtuel pour les stations lambda, nomade et societe est effectué dans les scripts *InstallBase.

Pour VDN un réseau est composé des machines qu'il contient. Chaque machine se charge de définir les connexions de ses interfaces réseau aux différents switchs virtuels via sa variable NETWORKS.

NETWORKS contient la suite des connexions des différentes cartes de la machine sous la forme “netEth0 netEth1 … netEth7” ou chaque netEthx indique le switch virtuel sur lequel est connecté la carte ethX (“none” si la carte n'est pas connectée). Après la définition peut-être précisé un # suivi d'un commentaire (sans espace) qui servira d'annotation lors de la génération du graphique associé au réseau via la commande vdn-graph.

Pour clarifier l'ensemble le détail de la configuration du réseau “démo” est décrite ci-dessous.

Etude des connexions des machines du réseau “démo”

Les variables NETWORKS des différentes machines du réseau ont été configurées de la sorte :

     GUEST NETWORKS
    lambda $NET_G#20.X1.Y1.Z1/8
   bigboss $NET_2#192.168.30.2/24
    nomade $NET_G#20.X2.Y2.Z2/8
   societe $NET_G#20.X3.Y3.Z3/8 $NET_1#192.168.1.1/24 $NET_2#192.168.30.1/24
      tiny none $NET_2#192.168.30.16/24
       web $NET_1#192.168.1.2/24

En éliminant les commentaires (#…) utilisés pour l'annotation du graphique, on obtient une description suffisante :

     GUEST NETWORKS
    lambda $NET_G
   bigboss $NET_2
    nomade $NET_G
   societe $NET_G $NET_1 $NET_2
      tiny none $NET_2
       web $NET_1

En clair :

• La carte eth0 (première interface décrite) de lambda est connectée au switch virtuel NET_G (qui correspond à l'Internet virtuel)
• La carte eth0 de bigboss est connectée au switch virtuel privé n°2 (on rappelle que chaque réseau peut disposer de 256 switchs virtuels privés)
• La carte eth0 de nomade est connectée au switch virtuel NET_G
• Les cartes eth0, eth1 et eth2 de societé sont connectées respectivement aux switchs virtuels NET_G, NET_1 et NET_2
• La carte eth0 de tiny n'est pas connectée (none) et sa carte eth1 est connectée au switch NET_2
• La carte eth0 de web est connectée au switch virtuel NET_1

Une interface cachée (sur le schéma du réseau) permet à une machine virtuelle de sortir vers l'hôte et tout son réseau (éventuellement Internet). Cette interface est utilisée par VDN pour établir des connexion ssh de l'hôte vers le système virtuel. Dans le cas de systèmes VDN cette interface peut être utilisée par la sauvegarde par le réseau des modifications !

L'interface “cachée” peut être “vue” via un ifconfig sur le système virtuel (c'est celle qui suit la dernière utilisée). Son IP doit être 10.0.2.15 (elle est normalement fixée automatiquement). L'hôte est accessible via cette interface à l'adresse IP 10.0.2.2. Si vous souhaitez sortir sur tout le réseau de l'hôte, vous pouvez fixer 10.0.2.2 comme passerelle par défaut. Si le réseau local réel possède un DNS et si vous souhaitez l'utiliser, fixez 10.0.2.3 comme serveur DNS dans /etc/resolv.conf du système virtuel. En fait, toutes ces caractéristiques proviennent du fait que le logiciel slirp est utilisé. Vous pouvez consulter sa documentation ainsi que celles de linux et de qemu qui présentent ce type de réseaux virtuels.

L'interface “cachée” peut également être utilisée pour accéder depuis l'hôte à des services (ports TCP/UDP) d'un système virtuel. C'est implicitement le cas pour les connexions ssh entre l'hôte et les systèmes virtuels VDN. D'autres connexions peuvent être souhaitées. Par exemple, pour tester un serveur Web virtuel il est plus rapide de le tester via un navigateur exécuté par l'hôte que par un navigateur exécuté par nos “petites” machines virtuelles). Dans ce cas vous devrez rendre possible cet accès via une redirection d'un port local du système hôte vers le port 80 du système virtuel. Cette redirection sera prise en charge par VDN grace à la variable REDIRS. Ci dessous le contenu à définir dans le fichier de configuration de la machine virtuelle pour ssh et http.

 ...
 REDIRS="tcp:22:(ssh) tcp:80:(http)"
 ...

VDN cherchera à allouer les mêmes ports aux mêmes services tout en limitant les conflits entre machines virtuelles. Cependant si le port est indisponible, le premier port libre immédiatement supérieur sera utilisé. La commande vdn-infos nomSystème (ou l'item infos du menu de l'interface graphique) affichera les redirections effectuées.

Ne désactivez pas cette interface “cachée” notamment si vous installez un logiciel de type “pare feu” dans vos systèmes virtuels. Si cela arrive vous devrez la rétablir (via la console virtuelle de la station) pour débloquer les connexions ssh.

Un réseau peut être représenté soit par le graphique graph.svg généré automatiquement par la commande vdn-graph soit par le graphique net.svg créé manuellement par Inkscape. Dans ce dernier cas (Inkscape) il est indispensable pour que les systèmes soient détectés par l'interface graphique que chaque nom de système nomDuSystem soit entouré d'un rectangle dont l'étiquette (objet→propriété) sera fixée à #nomDuSystem.

Copiez le répertoire d'un réseau et adaptez le. Exemple :

cp -a demo demo2
export NET_DIR=$PWD/demo2
vdn-build-network
vdn-show
vdn-graph

Adaptez éventuellement le graphe net.svg (cf. La représentation graphique du réseau).

Modifiez le script build, reconstruisez le réseau (vdn-build-network), vérifiez sa cohérence (vdn-show), et adaptez si nécessaire le graphe (cf. La représentation graphique du réseau).

Supprimez le répertoire associé au réseau. Si des sauvegardes on été faites, supprimez les également. Exemple :

rm -Rf demo2
rm -Rf ~/vdn-save/demo2

On rappelle que dans le cas d'un disque de type “DIRECT” les opérations de lecture et d'écriture sont effectuées directement sur le disque virtuel. Ce genre de disque sert souvent de disque de base aux systèmes COW et/ou TGZ.

Le réseau “zoo” est dédié à la gestion de ces disques et sert en quelque sorte de nurserie. Nous traitons le cas de l'installation d'un système de type “direct” via un cédérom d'installation. Le système SliTaz du script build peut servir d'exemple.

Il suffit de démarrer le système virtuel et d'effectuer les modifications souhaitées.

Supprimez le fichier associé au disque virtuel dans le répertoires disks.

On rappelle que dans le cas d'un disque de type “COW” les opérations d'écritures sont faites dans le fichier de sauvegarde associé (~/vdn-save/nomDuReseau/nomDuSystème par défaut).

Le fichier COW est automatiquement créer en cas d'absence au démarrage de la machine virtuelle. Sa taille est à préciser dans la configuration de la machine via la variable HDA_SIZE.

Il suffit de démarrer le système virtuel de type “COW” et d'effectuer les modifications souhaitées (qui seront inscrites dans le fichier de sauvegarde).

Supprimez le fichier des sauvegardes (~/vdn-save/nomDuReseau/nomDuSystème par défaut).

Les opérations décrites ci-dessous ne s'appliquent qu'aux systèmes VDN.

Le réseau build contient les systèmes permettant de gérer les disques de façon “directe”.

En démarrant un systèle présent dans le réseau “build” vous pourrez ajouter/retirer/configurer les paquets de votre choix.

VDN est un petit logiciel (moins de 1 Mo) de programmes bash, ruby (GTK2) avec un peu de python (aucun programme compilé).

Sous Debian stretch ses dépendances (paquets logiciels nécessaires) sont indiquées dans les script bin/vdn-prepare. Debian Stretch est la distribution utilisée pour le développement de VDN (voir Participer au développement du code).

Pour les autres distributions GNU/Linux l'exécution de VDN s'effectue en environnement fakechroot (un peu similaire à une AppImage).

VDN est un logiciel libre sous licence disposant de son propre dépôt git que vous pouvez donc cloner.

Remarque : le fonctionnement dans un environnement fakechroot n'apporte aucune limite à l'utilisation/configuration de VDN mais impose des contraintes pour les développeurs du code source de VDN, notamment dès qu'il faut ajouter un nouveau fichier dans l'environnement fakechroot. Aussi si vous souhaitez facilement modifier VDN travailler sous une Debian stretch.

Dans les tests suivants nous démarrons simultanément les 6 machines virtuelles du réseau “demo” vierges de toute configuration et chronométrons le temps mis jusqu'à l’obtention d'un prompt sur toutes les machines. Ces tests ont été effectués sur un processeur Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz.

Virtual Didactic Network (Vdn) est un outil pédagogique permettant l'apprentissage de la configuration de systèmes d'exploitation et notamment des services réseaux sous Unix (voir Présentation).

GPL V3 (voir Licence).

VDN est en cours de développement ! tout ne marchera sûrement pas correctement !

Cependant nous l'utilisons en “production” au sein de notre département informatique. Il a été installé dans un répertoire partagé (par NFS) en lecture seule (compte Unix dédié, ou compte Unix d'un enseignant). Les quelques paquets Debian nécessaires à son fonctionnement ont été installés sur les stations des étudiants par l'administrateur via la commande : vdn-prepare-debian.

Cette configuration a été testée avec un démarrage simultané de 3 groupes de TP soit plus d'une centaine de machines virtuelles lancées simultanément et accédant toutes par NFS au même disque virtuel sans saturation notoire du réseau local Ethernet à 100 Mbits.

Nos étudiants désireux de faire ou de continuer leur TP sur leur machine personnelle sous Debian installent en général VDN sans problème particulier.

Un mail à : vdn [at] iut [dot] u-clermont1 [dot] fr.

Avec le disque virtuel Debian fourni avec VDN est installé l'environnement X11. Les programmes graphiques peuvent être exécutés via un vdn-ssh -X toto@system (toto est l'utilisateur, system est le système virtuel) ou directement dans une console ssh de VDN.

Si un gestionnaire de fenêtres est souhaité, il faut activer la mire de connexion lightdm qui permettra à l'utilisateur de se connecter (avec xfce4 comme gestionnaire de fenêtres).

systemctl start lightdm

Si la mire de connexion doit être activé au boot il faut fixer la cible (runlevel) graphical :

systemctl set-default graphical.target

Pour un retour en arrière (pas de mire de connexion par défaut):

systemctl set-default multi-user.target

L'écran graphique du système virtuel est accessible via une console VNC :

vdn-vnv-viewer system # system est a remplacé par le nom du système virtuel à contacter

L'écran graphique peut être lancé automatiquement et éventuellement intégré à la fenêtre VDN. Pour cela fixez à 1 les variables KVM_VIEWER, KVM_VIEWER_AUTOSTART et KVM_VIEWER_EMBEDDED à 1 dans le fichier de configuration du système.

Actuellement VDN n'est prévu d'être installé que sur Debian stretch 64 bits et ne permet de faire fonctionner que des réseaux de Debian stretch 64 bits (pour autres distributions voir portages).

Certaines machines nécessitent d'activer les instructions de virtualisation dans leur BIOS/UEFI.

La commande bin/vdn indique, lors de son lancement, la raison faisant que vous ne bénéficiez pas d'instructions de virtualisation et vous indique comment y remédier si votre processeur en possède.

Si votre processeur ne dispose pas d'instructions de virtualisation cela n'empêchera pas les systèmes virtuels de fonctionner mais cela sera lent, très lent…

Les réseaux virtuels utilisés par Vdn utilisent un canal de diffusion (multicast). Le fonctionnement des canaux de diffusion nécessite une route par défaut sur l'une des interfaces réseau du système hôte. Normalement cette route par défaut est fixée au moment de l'initialisation de la carte réseau du système hôte. Vérifiez sa configuration. Une fois l'interfaçe réseau activée, la commande /sbin/route -n doit afficher la route par défaut (destination 0.0.0.0). Exemple :

$ /sbin/route -n
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.1.3     0.0.0.0         UG    0      0        0 eth0

Si le système hôte ne dispose pas d'interface réseau, vous pouvez autoriser la diffusion sur l'interface lo (loopback) via les commandes (il faut être root) :

ifconfig lo multicast
route add default gw 127.0.0.1

Dans un terminal, exécutez :

export NET_DIR=vdn/networks/demo
vdn-start -d nomDeLaMachine

L' éventuel message d'erreur devrait apparaître.

L'ajout d'un service (ou d'un logiciel) dans le système souche après lancement des machines virtuelles peut entraîner des masquages indésirables. Le problème se pose par exemple dans le cas suivant.

1. le disque virtuel n'intègre pas un service quelconque créant des entrées dans /etc/{passwd,shadow,group}, comme ntp pour ne donner qu'un exemple.
2. les utilisateurs créent sur certaines machines virtuelles un utilisateur (adduser toto). Les fichiers originaux /etc/{passwd,shadow,group} sont modifiés et sont donc intégrés dans la couche haute (read/write) de l'union de systèmes de fichiers.
3. l'administrateur du système souche ajoute le service (aptitude install ntp) entrainant l'ajout d'un utilisateur (ntp dans l'exemple) et donc la mise à jour des fichiers /etc/{passwd,shadow,group} du système souche.
4. l'utilisateur redémarre ses machines virtuelles. Celles qui ont modifié leurs fichiers /etc/{passwd,shadow,group} ne connaitront pas l'utilisateur ntp puisque les fichiers du système souche intégrant l'utilisateur ntp sont masqués par les fichiers de la couche haute de l'union (ceux possédant l'utilisateur toto).

Pour pallier ce problème, les utilisateurs devront ajouter eux-même les lignes manquantes (celles relatives à l'utilisateur ntp dans l'exemple) dans les fichiers de configuration concernés.

Le plus simple pour éviter ce genre de complication est de prévoir à l'avance tous les services nécessaires à une série de TP.

Par défaut VDN utilise le répertoire temporaire classique /tmp pour les fichiers temporaires. Si ce chemin ne vous convient pas vous pouvez ajouter la ligne suivante à votre fichier ~/.vdnrc :

TMPDIR=cheminDeVotreRépertoireTemporaire

La stratégie de rassembler l'ensemble des services/logiciels dans un unique disque virtuel peut amener des problèmes d'exclusion de paquets (dépendances antagonistes).

A voir au cas par cas.

Virtual Didactic Network (VDN) est un logiciel libre ; vous pouvez le redistribuer ou le
modifier suivant les termes de la “GNU General Public License” telle que
publiée par la Free Software Foundation : soit la version 3 de cette
licence, soit (à votre gré) toute version ultérieure. 

Ce programme est distribué dans l’espoir qu’il vous sera utile, mais SANS
AUCUNE GARANTIE : sans même la garantie implicite de COMMERCIALISABILITÉ
ni d’ADÉQUATION À UN OBJECTIF PARTICULIER. Consultez la Licence Générale
Publique GNU pour plus de détails.

Vous devriez avoir reçu une copie de la Licence Générale Publique GNU avec
ce programme ; si ce n’est pas le cas, consultez :

http://www.gnu.org/licenses/.

Quelques liens vers les parties de code libre utilisées par VDN

• Debian
• KVM
• Overlay Filesystem
• Ruby-GNOME2

Un exemple d'utilisation de VDN

• Administration réseau sous Linux (wikibook)

D'autres logiciels proposent des fonctionnalités similaires à VDN. A notre connaissance aucun n'utilise la très économe sauvegarde des modifications basée sur le principe des LiveCD.

• marionnet
• Clownix
• Netkit
• VNUML