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 systèmes virtuels (Debian) que nécessaire et cela tout au long de leur formation s'étalant sur plusieurs mois.

En étant administrateur (et propriétaire) de leurs systèmes 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 tente de répondre à ces deux contraintes en mariant la virtualisation et un dérivé du principe du LiveCD afin de satisfaire les trois types d'utilisateurs suivants :

• l'administrateur des systèmes hôtes. Son rôle est :
  • d'activer si nécessaire les instructions de virtualisation dans le BIOS/UEFI du PC.
  • de fixer les droits rw sur /dev/kvm. Le plus simple est d'ajouter les utilisateurs au groupe kvm.
  • d'installer les logiciels (paquets Debian) dont dépend VDN (une seule commande à exécuter sur l'ensemble du parc composant les salles de TP). 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 (un réseau virtuel 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.

VDN peut-être installé théoriquement sur tout système GNU/Linux 64 bits sur une machine personnelle sur lequel il est possible d'être root (voir “VDN via chroot”).

Les étudiants, tout au long de leur formation, disposeront de leur propres systèmes et réseaux virtuels qu'ils pourront transférer et utiliser sur leurs systèmes personnels GNU/Linux.

Chacun de ces types d'utilisateurs dispose d'une partie spécifique dans ce document (sur votre machine personnelle vous serez sans doute amené à jouer les trois rôles) :

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 à simplifier l'apprentissage des “Systèmes” et des “Réseaux”. L'équipe de développement n'a malheureusement que peu de temps à consacrer à VDN.

Pour récupérer VDN (environ 10 Mo), PAS SOUS ROOT :

git clone http://opale.u-clermont1.fr/vdn/git/vdn.git # PAS SOUS ROOT mais sous votre compte utilisateur

Si la commande git est absente installez là (sous root) :

apt-get install git-core

Sous root :

vdn/​bin/​vdn-prepare 

Cette commande cherche a déterminer le type du système hôte pour adapter la procédure d'installation au différents cas suivants :

• debian : Le système hôte est une Debian sur laquelle VDN a été portée. Dans ce cas l'installation consiste à installer quelques paquets Debian.
• derivate : Le système hôte est une Debian (ou dérivée) sur laquelle VDN n'a pas été explicitement portée. Dans certains cas (versions de logiciels compatibles) l'installation et le fonctionnement de VDN ne pose pas de problème. Ci dessous un paragraphe synthétisant les expériences positives/négatives sous Debian et dérivées. Vous pouvez rapporter votre expérience pour que ce tableau soit mis à jour. Si votre expérience reste négative vous pouvez vous rabattre sur les solution ci-dessous.
• switchLinux :Le système hôte n'est pas une Debian ou dérivée, ou est incompatible. Dans ce cas un environnement Debian devra être construit pour l'utilisateur au démarrage de VDN. La construction de l'environnement est instantanée et transparente pour l'utilisateur, mais nécessite l'accès au compte root.
• switchLinux-setuid : Même cas que précédemment mais l'utilisateur n'accède pas au compte root. Dans ce cas il est possible d'installer le programme construisant l'environnement en fixant son bit setuid, évitant que l'utilisateur ait explicitement besoin de s'identifier root.
• unknown : Système incompatible avec VDN.

La commande vdn/​bin/​vdn-prepare -u désinstallera les paquets installés par VDN ou le programme setuid.

Sur une machine personnelle, ou le compte root est accessible par l'utilisateur, la solution “switchLinux” est sans doute à privilégier.

Sur un réseau hétérogène (ou comportant des systèmes GNU/Linux ne permettant pas de faire fonctionner VDN), où les utilisateurs n'ont pas de droit privilégié, la solution switchLinux-setuid est la plus performante. Sous la responsabilité de l'administrateur qui doit intégrer un programme setuid au système.

Sous votre login d'utilisateur habituel : ← c'est important pour la suite

vdn/bin/vdn # PAS SOUS root

D'éventuelles questions vous seront posées. Le choix par défaut convient généralement.

Dans le cas d'un environnement chroot, vdn proposera de basculer dans l'environnement chroot et vous demandera le mot de passe root. Les actions réalisées sous root préparent les montages et le basculement. Ensuite VDN s'exécute sous votre identité. Voir VDN via chroot pour les mises en gardes !

En téléchargeant VDN vous téléchargez le logiciel lui même ainsi que la définition de quelques réseaux et éventuellement un disque dur virtuel dans le cas d'un chroot. Il vous reste à télécharger les fichiers spécifiques aux réseaux de votre choix (disques virtuels, intramfs, noyaux, …) 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 NETWORK_DIR=.
vdn-download-disks

La procédure est identique dans un répertoire partagé (une seule installation de vdn pour des centaines d'utilisateurs).

Chaque machine Debian Buster devra cependant posséder les dépendances logicielles; l'administrateur devra exécuter une fois la commande suivante sur chaque machine. :

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

Avec un réseau est fourni :

• la définition des machines et leur interconnexions
• un lien vers les disques virtuels à télécharger
• des scripts (shell bash)

Les scripts (accessibles via le menu Scripts (et via le menu Tests en mode Preferences → Tests mode)).

Pour ceux fournis avec VDN ils sont organisés ainsi :

• Menu scripts :
  • config* : configuration initiale des machines.
  • test* : divers tests

En activant l'option Preferences → Test mode, un menu Test apparaît permettant d'accéder :

• test* des scripts de tests supplémentaires.
• repair* des scripts “réparant” (répondant par exemple aux questions des TP).

Contrairement aux scripts config* et repair*, les scripts test* ne sont pas censés effectuer des modifications, juste des tests…

Les scripts config* permettent de placer les machines dans un certain état. Les scripts configBase* s'occupent notamment fixer le nom d'hôte, le fichier /etc/hosts et le fichier /etc/network/interfaces.

Les scripts repair* sont pratiques ils permettent :

• de garder une trace des solutions :
• de valider les changements de distributions

Les scripts error* génèrent une erreur. La signification des erreurs est reportée dans un fichiers errors.txt pour que le nom ne donne pas d'indice.

exemple :

error01: déconfigure l'interface eth1 de tiny

Les scripts repairError* sont là pour réparer les erreurs.

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 et/ou réaliser des attaques.

Les scripts proposés dans le réseau “demo” sont orientés “services” faisant intervenir exclusivement les 2 machines bigboss (hébergeant les services) et tiny (hébergeant les clients).

Avec ces simples deux machines il est possible de configurer/tester :

• les interfaces réseaux et les fichiers de bases (/etc/hostname, /etc/hosts, /etc/networks/interfaces).

• Les service services/protocoles qu'il est possible de configurer :
• NFS, ssh, ftp, http, https, …

L'objectif est de configurer les routes statiques sur R2 (le script configWithoutR2 configure les routes statiques de tous les autres routeurs).

L'objectif est de configurer le démon OSPF de quagga de R2 (le script configWithoutR2 configure les démon OSPF de tous les autres routeurs).

Idem le réseau précédent mais cette fois-ci avec le protocole RIP.

Le réseau Firewall, dérivant du réseau démo, exploite toutes les machines du réseau démo pour illustrer la configuration d'un parefeu (NetFilter via iptables).

Le réseau est simple mais la machine plus complexe : un disque dur virtuel (/dev/vdb) lui est adjoint. Au démarrage ce disque est automatiquement partitionné, formaté si nécessaire puis sa première et unique partition est montée dans /var/lib/docker, le répertoire des images docker. Ce répertoire sera vierge au premier démarrage, à l'utilisateur de télécharger ses images de son choix, dans la limite de l'espace du disque /dev/vdb (commande mount pour voir l'espace utilisé/libre).

L'utilisateur test a été ajouté au groupe docker.

Pour tester (sous le compte test de la machine virtuelle) :

docker run -it busybox sh

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”, “routing”, “fixme” et “secure”. 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 pour vous 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 saturer la RAM de 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.15). 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 à partir de l'hôte vers toutes ses machines virtuelles. Ignorez cette interface (et évitez de la filtrer avec votre pare-feu “virtuel” !). Si cependant vous perdez le ssh avec votre machine virtuelle tout n'est peut être pas perdu : Perte de la connexion avec la machine virtuelle.

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

1. Le chemin des exécutables 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 RSA, est généré si vous n'en aviez pas déjà. Votre clé publique sera ajouté au fichier /root/.ssh/authorized_keys des systèmes virtuels. Vous pourrez ainsi vous connecter sans avoir à taper de mot de passe. D'ailleurs les mots de passe des différents comptes utilisateur sont au départ aléatoires, mais comme vous êtes root il vous sera simple de les changer (passwd(1)).

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

Après les onglets voici une description rapide des menus “Network” et “Scripts”.

• Ouvrez un réseau, puis basculez sous l'onglet “Graph” et sélectionnez (à la souris) les stations que vous souhaitez démarrer.
• Sur le nom d'une station sélectionnée à l'étape précédente, 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.

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 Bas). 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).

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 sous votre HOME (~/vdn-save).

Dans l'onglet “Graph” un clic droit permet d'obtenir le menu contextuel relatif aux machines sélectionnées.

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. 

Onglet “Consoles” → cliquer sur la machine, ou en ligne de commande :

vdn-viewer machine

Aussi dans l'onglet “Graph” → Sélectionner la machine → clic droit → Viewer

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 Limitations. Pour installer VDN sur votre système GNU/Linux 64 bits (avec instructions de virtualisation activées) consulter ”Téléchargement et installation“.

Sinon, Quelques trucs et astuces.

Règle n°1 : un système virtuel VDN ne peut porter atteinte à un système hôte, ni, en restant passif, permettre qu'un système hôte ne soit exposé au danger; ( un système virtuel de VDN est un processus de l'utilisateur)

Règle n°2 : un système virtuel VDN doit obéir aux ordres qui lui sont donnés par un système hôte, sauf si de tels ordres entrent en conflit avec la première loi; ( pas d'escalade de privilèges connue avec /dev/kvm ).

Règle n°3 : un système virtuel VDN doit protéger son existence tant que cette protection n'entre pas en conflit avec la première ou la deuxième loi. ( Ce n'est pas pour rien qu'on a choisi Debian Mais BSD c'est bien aussi )

Merci M. Asimov.

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 totalement couverte par l'interface graphique. Dans quelques cas quelques commandes seront à exécuter dans un shell (cp, mv, rm, …).

L'interface graphique s'appuie sur une couche de commandes de la forme vdn-*. L'interface graphique n'est pas nécessaire à VDN (tout est script donc fichiers simples avec vdn).

Les disques de sauvegardes des utilisateurs peuvent individuellement être placés au choix :

• dans son home (choix par défaut)
• dans /tmp. Sauvegardes ou disques virtuels volumineux le temps de la séance de TP (jusqu'au prochain reboot, attention au coupures électriques !)
• dans un répertoire autre. Il peut en effet être intéressant de localiser l'ensemble des sauvegardes dans une partition autre que le home des utilisateurs, soumise à ses propres quotas.

L'utilisateur accède à ses sauvegardes en ligne de commande via la commande vdn-manage-backups et via Network → backups dans l'interface graphique.

L'administrateur des systèmes souches devra placer ses disques dans le sous répertoire vdn/files. Le réseau zoo est dédié à la gestion de ces systèmes souches. Il accédera a ses disques dans ce même sous répertoire (vdn/files).

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

• VDN est capable de gérer tout système compatible KVM/QEMU.
• Mais seuls les systèmes Debian/Kali peuvent être “préparés” pour une sauvegarde des modifications sous forme TGZ (très optimisée).
• Avec VDN sont fournis des réseaux et des disques Debian/Kali “préparés” (et donc compatible avec le mode de sauvegarde de type TGZ).
• Le script de préparation de ces disques est fourni (distrib/guests/direct/…)

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

Évitez de modifier directement ce fichier, faites en une copie avec l'extension .local afin d'éviter les conflits avec les nouvelles versions distribuées.

cp vdn/config.rc vdn/config.rc.local

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

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 NETWORK_DIR ou, à défaut, le dernier réseau ouvert par la commande vdn (interface graphique), et mémorisée dans la variable NETWORK_DIR du fichier ~/.vdnrc.

Avec l'interface graphique (après avoir coché la préférence “Tests”) vous trouverez dans le menu “Configuration” l'item Edit network script…. Si vous faites des modifications dans ce fichier le réseau sera reconstruit (ainsi que son graphe graph.svg) lorsque vous quitterez l'éditeur.

Vous pouvez modifier/ajouter/retirer des machines.

Sinon, en ligne de commandes tout se passe dans le répertoire du réseau (vdn/networks/nomDuRéseau) :

• Éditez le script build du réseau

• vdn-build-network utilise le script build pour construire les fichiers de configuration des systèmes virtuels et le graphe graph.svg.

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

Cloner un réseau existant puis ouvrez le pour le modifier (cf. ci-dessus)

Avec l'interface graphique (après avoir coché la préférence “Tests”) vous trouverez dans le menu “Configuration” l'item Edit network script….

Avec la ligne de commande

vdn-clone -n newName 

Le fichier de configuration d'une machine est généré par le script build de son répertoire de réseau à partir du fichier de configuration par défaut config.template.suivant :

Plutôt que d'éditer “à la main” les fichiers nomDuSystème.conf modifiez plutôt le script de construction du réseau et regé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.

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, de même que la représentation ASCII du graphe. 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 à 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 simplifier à 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 modes différents sont possibles :

• 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. Ce mode 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.

• 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,…). Si les quotas disques sont trop limités il est possible de ne pas assurer la persistance en spécifiant le chemin du fichier COW des modifications sous /tmp.

• Le partage de disque de type “TGZ”. Cette technique utilisée par exemple par certains LiveCD a été adaptée dans VDN pour les systèmes Debian/Kali. 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 (archive tar compressée donc tgz). 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). De plus il est possible d'exclure une liste de fichiers des sauvegardes (/tmp, /var/cache, …).

Pour aiguiller le choix d'un type de partage (COW ou TGZ) 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 du mode “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 enregistrant 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 charge à 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 croître.

La technique du mode TGZ 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 le mode TGZ 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 le mode TGZ à les désavantages suivants :

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

• Est inadaptée lorsque la taille des modifications dépasse quelques dizaines de 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, formater, remplir….

Les systèmes acceptent 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).

Remarque : dans le cas d'un disque distant, il est plus efficace de définir SWAP_SIZE puisque dans ce cas la partition de swap est située en local (/tmp).

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.

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 adresses 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). Vous pouvez vous inspirer des scripts baseConfig* du réseau demo par exemple pour avoir des exemple de configurations complètes de stations (IP, …).

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 connexions ssh de l'hôte vers le système virtuel. Dans le cas de systèmes VDN cette interface peut être utilisée pour 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.

Dans VDN, le contenu d'un disque virtuel est géré par une machine virtuelle dédiée dans le réseau zoo. Toutes les machines virtuelles du réseau zoo utilisent le disque en mode “direct”.

• Tout ce que vous installerez dans ce système sera disponible dans les systèmes de type tgz

• Ne modifiez JAMAIS un disque déjà utilisé par des systèmes de type COW, cela invaliderai définitivement leur disque.
• Avant toute modification il est conseillé de faire une copie du disque.
• Ne modifiez pas un disque en cours d'utilisation par des machines virtuelles, au risque de détruire leur système de fichiers.

Ensuite,

• 1. démarrer le système (dans le réseau zoo)
• 2. ouvrir un shell ssh sur le système, faire les installations/modifications, arrêter le système.
• 3. (facultatif) pour des besoins de reproductibilité nous enregistrons les modifications dans le script prepareXXX (XXX est le nom du système “direct”).

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

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

L'interface graphique propose “Config” → “Clone network…”.

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

L'interface graphique propose “Config” → “Edit network graph…”

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 sauvegarde on été faites, supprimez les également. Exemple :

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

Note : la commande vdn-manage-backups liste les sauvegardes

Un disque de base contient un système d'exploitation. Un tel disque est le résultat d'une installation classique du système et n'a ce stade aucune particularité liée à VDN.

Un disque “de base” peut être associé à un système intégré à VDN, de préférence via la technique COW s'il doit être utilisés par de nombreux utilisateurs (c'est transparent).

Le réseau “zoo” est dédié à la gestion de ces disques et sert en quelque sorte de nurserie.

Utiliser les outils du système pour ajouter/retirer des logiciels/services.

• Toute adaptation doit être faite avant de “donner” le disque aux utilisateurs.
• Ensuite à chaque utilisateur de faire ses adaptations.
• Pas de spécialisation (adaptation automatique du système au démarrage) possible.

Supprimez le fichier associé au disque dans le répertoires files.

Un disque “VDN” est un disque “de base” modifié (préparé) de telle sorte qu'il puisse se spécialiser à l'amorçage.

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

Un système “DIRECT” préparé est un système “DIRECT/DE BASE” modifié pour qu'il puisse se spécialisé dynamiquement en fonction du système qui le démarre.

D'un système

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.cow par défaut).

Même si possible aucun intérêt, VDN le créera automatiquement !

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

Au démarrage, un disque COW “préparé” peut récupérer des fichiers de l'hôte et donc des scripts de démarrage personnalisés activant/désactivant des services.

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

Un système “TGZ” utilise une archive compressée des fichiers modifiés, qu'il charge à chaque démarrage et crée à chaque arrêt.

VDN le prends en charge

C'est le point délicat. Du fait de son chargement à chaque démarrage et de sa création à chaque arrêt du système les grosses archives associées à de grosses modifications ralentissent les séquences de démarrage et d'arrêt de la machine virtuelle. Si le volume des modifications compressées dépasse quelques dizaine de Mo, les systèmes TGZ deviennent inadaptés.

L'idée est que tous les logiciels utiles soient installés sur le système souche avant le démarrage des systèmes virtuels.

Comme un système “COW” un système “TGZ” récupère des fichiers de l'hôte, et donc éventuellement des scripts de configuration exécutés au démarrage du système.

Cependant, l'activation/désactivation des services est pris en charge très tôt dans la phase d'amorçage du système (initramfs) et est contrôlée par les variables :

• EXTRA_SERVICES : les services non activés de base à activer
• EXCLUDE_SERVICES : les services activés de base à désactiver

Après un script, ou l'utilisateur, peut dynamiquement, en fonction d'un besoin temporaire, activer/désactiver les services de son choix.

supprimer le fichier.

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

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

Seulement pour les systèmes VDN “préparés”.

3 possibilités pour injecter des fichiers. Ces trois possibilités peuvent être utilisées simultanément.

• 1. : via la variable HOSTS_FILES du système (fichier de configuration). Les fichiers dont le nom est précisé dans cette variable sont copiés. Exemple d'utilisation : importation automatique de /etc/bash.bashrc de l'hôte.
• 2. : via le répertoire all du répertoire du réseau. Ce répertoire, s'il existe, est importé à la racine du système virtuel. Exemple d'utilisation : injection d'un script de préparation ou de fichiers de configuration des machines du réseau.
• 3. : via le répertoire du répertoire du réseau portant le nom du système. Ce répertoire, s'il existe, est importé à la racine du système virtuel. Exemple d'utilisation : idem précédemment mais pour une machine spécifique.

Ces trois étapes sont exécutées dans l'ordre ci-dessus en début de /etc/rc.local afin de rendre la spécialisation possible.

Seulement pour les systèmes VDN “préparés”.

A la fin de /etc/rc.local les scripts de la forme /etc/vdn/XX-* (ou XX et un couple de chiffres permettant d'ordonner leur exécution) sont exécutés.

Il suffit de les définir et de les injecter comme décrit plus haut.

Remarque : actuellement il n'est pas aisé d'injecter un script de son choix pour tous les systèmes, ni même pour ceux d'une distribution donnée. Nous n'en avons pas eu (encore ?) le besoin.

VDN, de part ses nombreuses dépendances logicielles aux versions précises, est complexe à porter sur d'autres distributions que Debian. Aucun portage sous d'autres distributions que Debian n'est prévu.

Cependant, VDN intègre switchLinux, qui vous permettra, de basculer sous la Debian fourni avec VDN. L'utilisation de switchLinux nécessite les droits root.

Si vous n'êtes pas “root” sur votre machine (cas d'un réseau pédagogique sous GNU/Linux autre que Debian) il faudra convaincre l'administrateur du systèmes de fixer le droit SETUID sur switchLinux.

Devrait fonctionner avec WSL2 mais avec baisse de performance due à la double virtualisation… A tester.

Il faudra porter switchLinux…

Le système de conteneur utilisé par VDN est expérimental. Voir switchLinux.

Lors de la phase d'installation, l'installeur cherche à différencier 3 cas :

• debian supportée par VDN
• debian (ou dérivée) non supportée officiellement (mais cela ne coûte pas cher d'essayer).
• autres : dans ce cas
  • installation classique de switchLinux
  • installation avec bit setuid fixé pour switchLinux

• A tout moment vous pouvez relancez, sous root, vdn-prepare pour changer le type d'installation

Si vous rechigner à utiliser le système de conteneur utilisé par VDN (nécessitant les droits root ou le bit SETUID sur un exécutable) sachez que nous avons aussi chercher à nous en passer, mais ce n'est pas si simple :

• Utilisez VDN dans une machine virtuelle Debian. L'inconvénient avec cette solution est qu'elle entraînera une double virtualisation puisque VDN virtualisé lancera lui même des machines virtuelles. Les performances, sans optimisation, sont dégradées d'un facteur 5 ou plus.

• Utiliser un conteneur docker basé sur Debian. Cette solution nécessite l'installation de docker et d'ajouter l'utilisateur au groupe docker. Cette solution sera performante mais n'est généralement pas disponible sur un réseau pédagogique.

• Construire un environnement uniquement à l'aide de commandes non root (à l'aide guestmount + proot par exemple) est possible mais les performance sont catastrophiques, rendant cette solution actuellement inexploitable.

Bref, en attendant mieux (*), on continue avec switchLinux.

(*) : performant, sans droit root.

Vous n'avez rien a faire de particulier pour activer le chroot, la détection d'un système autre que Debian par VDN vous proposera la mise en place et le basculement automatique dans l'environnement chroot.

• L'option -c de vdn permet d'accepter par défaut le basculement
• L'option -s de vdn permet de passer root via sudo (su par défaut).

Si absent, le disque utilisé pour l'environnement Debian (utilisé également par les systèmes virtuels VDN) est téléchargé.

D'autres solutions ne nécessitant pas d'être root ont été testées (ou simplement envisagées) mais présentent des dégradations de performances. Nous les listons ci-dessous et expliquons pourquoi elle ne fonctionnent pas (ou mal). Si vous avez des bons retours pour d'autres solutions nous sommes preneurs.

• A l'heure de la virtualisation accessible facilement on pourrait penser que lancer VDN dans une Debian virtuelle est un bonne solution, malheureusement non. Cela fonctionnera mais avec des dégradations de performances importantes voire très importantes (facteur 5 ou plus) en raison de la double virtualisation engendrée (un système virtuel lançant lui même des systèmes virtuels…).

• L'utilisation de solution à base de conteneur, ou de paquet flatpak, ou d'une AppImage est peut-être envisageable mais les contraintes (gestion des différentes versions, impact sur le code, …) n'est pas trivial pour la maintenance.

• L'utilisation d'environnements “chrootés” par l'utilisateur (proot, fakechroot) échoue à faire fonctionner efficacement VDN (plantage et ou goulet d'étranglement). En effet démarrer simultanément de nombreux systèmes virtuels est assez extrême en nombre d'appels systèmes engendrées.

• L'installation de VDN dans Windows Subsystem for Linux version 1, si cela peut éventuellement fonctionner (pas testé), entraînera sans doute une baisse des performances en raison de l'absence de portage de KVM (hyperviseur utilisé par VDN) sous Windows.

• L'installation de VDN dans Windows Subsystem for Linux version 2, si cela peut éventuellement fonctionner (pas testé), entraînera sans doute une baisse des performances en raison de la double virtualisation engendrée.

• L'installation d'une Debian sur clé USB / disque externe reste une solution envisageable et les performances sont très proches de l'optimal avec un media rapide.

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 (depuis, mais pour d'autres raisons que l'usage de VDN , le réseau a évolué en Gbits).

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

Remarque : Si le système hôte n'est pas une Debian de la bonne version un basculement sous environnement Debian système GNU/Linux 64 bits vous sera proposé. Ce basculement nécessite, pour les montages et le chroot, les droits administrateurs.

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.

Le disque virtuel Debian fourni avec VDN contient le gestionnaire de fenêtre XFCE4 et la mire de connexion graphique lightdm. Une vue de l'écran de la machine virtuelle est accessible via la commande vdn-viewer system ou via le bouton du nom de la machine virtuelle dans l'onglet “Consoles”.

Si vous obtenez un écran noir c'est sans doute que le système n'a pas activé sa mire graphique.

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 Spice :

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

L'écran graphique peut être lancé automatiquement au démarrage de la machine virtuelle. Pour cela fixez la variable KVM_VIEWER_AUTOSTART à 1 dans le fichier de configuration du système.

Chaque système virtuel possède une interface réseau supplémentaire pour permettre l'accès au système virtuel à partir de l'hôte (notamment via ssh). Cette interface ethX est la dernière interface réseau affichée par la commande ip a.

Si vous déconfigurez cette interface ou si vous la bloquer par un pare-feu virtuel vos fenêtres ssh ne répondront plus.

Pour récupérer la connexion, il vous faut basculer sur l'onglet console pour, si nécessaire :

• reconfigurer l'interface : ip addr replace 10.0.2.15/24 dev ethX # ethX est la dernière interface réseau.
• Retirer la règle de filtrage que vous avez ajouté. Les commandes iptables -F et iptables -F -t nat videront les règles du pare feu.

Si votre machine répond au caractéristique décrites dans Téléchargement et installation, ce n'est pas normal !

Merci d’envoyer un Envoyez un rapport de bug.

Le principal facteur limitant au nombre de machines virtuelles qu'il est possible de démarrer est la quantité de RAM de l'hôte.

La mémoire doit être partagée entre l'hôte et les machines virtuelles. Une machine virtuelle Debian sans interface graphique peut fonctionner avec 256 Mo de RAM.

Exemple : si l'hôte (avec environnement graphique) dispose de 4 Go de RAM et que l'on souhaite démarrer 8 “petites” Debian (256 Mo de RAM) cela laissera 2G de RAM à l'hôte et son environnement graphique. Cela passe. Au dela, de forts ralentissements (swap) seront observés !

La raison est affichée dans les derniers messages de la console utilisée pour démarrer la machine virtuelle. Pour accéder à ces messages activez le mode “Debug” (Preferences → Debug).

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 plus lent d'un facteur 5 voir 10…

En résumé : pour que VDN fonctionne il faut que l'hôte soit connecté (ait une interface réseau). Si ce n'est pas le cas il faut activer le multicast sur l'interface loopback (127.0.0.1 en général) et la définir comme route par défaut : sous root (su -) :

ip link set dev lo multicast on; ip route add default via 127.0.0.1

Version longue :

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) ainsi que sont rôle de passerelle par défaut via les commandes (il faut être root) :

ifconfig lo multicast
route add default gw 127.0.0.1

Ou bien encore avec la commande ip :

ip link set dev lo multicast on
ip route add default via 127.0.0.1

Une seule instance de l'interface graphique n'est autorisé sur un même hôte. Il est en effet impossible de travailler simultanément avec plusieurs réseaux virtuels sur un même hôte (un même utilisateur voulant travailler avec 2 réseaux ou bien 2 utilisateurs travaillant avec un même réseau).

Intégrer cette fonctionnalité complique à la fois le code de VDN (gestion plus complexe de la politique d'allocation des adresses IP publiques virtuelles, des adresses MAC virtuelles, …) et à la fois son utilisation puisque chaque commande devient relative à un des réseaux.

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 dans le cas de systèmes de types “overlay” ou “tgz”. 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 dans le système de base.

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

Un exemple d'utilisation de VDN

• Administration réseau sous Linux (wikibook)

• Quelques schémas
• Quelques réflexions
• Guide pour le concepteur de réseaux
• Quelques notes techniques

D'autres logiciels libres proposent des fonctionnalités similaires à VDN. A notre connaissance aucun n'utilise la très économe sauvegarde des modifications basée sur une archive compressée des fichiers modifiés. Liste non exhaustive :

• marionnet
• Clownix
• Netkit
• VNUML