public:vdn:guide

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.

====== Guide d'utilisation de Virtual Didactic Network (VDN) ======

===== Présentation =====

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 [[http://fr.wikibooks.org/wiki/Administration_r%C3%A9seau_sous_Linux|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|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) :

  - [[#téléchargement_et_installation|Téléchargement et installation]] de VDN (plutôt pour l'administrateur).
  - [[#Utilisation]] de VDN (guide de démarrage pour l'étudiant).
  - [[#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.

===== Téléchargement et installation =====

<WRAP round center important 70%>
Normalement VDN fonctionnera si :
  * votre système d'exploitation est une Debian **Buster** d'architecture x86_64 (la commande ''uname -m'' doit afficher x86_64). 
  * Si votre système **n'est pas une debian buster** mais est un système GNU/Linux 64 bits consultez la section [[#portages|portages]].
  * Votre CPU possède des instructions de virtualisations et ces dernières sont activées (voir [[#mon_processeur_ne_dispose_pas_d_instructions_de_virtualisation|ici]] ),
  * Une RAM de 4 Go
  * Un espace disque libre de 20 Go.
</WRAP>

==== Téléchargement ====

<WRAP round center important 70%>
Quelque soit le cas de figure, VDN ne doit ni être installé par ''root'', ni être utilisé par ''root''. Le compte root sert éventuellement et uniquement à installer des paquets debian, à fixer les droits sur ''/dev/kvm'' et éventuellement activer les instructions de virtualisation dans le BIOS/UEFI.
</WRAP>

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
  
==== Installation ====

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.

<WRAP center round important 60%>
Le programme switchLinux est expérimental, aussi bien d'un point de vu fonctionnel que d'un point de vue sécurité !
</WRAP>

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


==== Démarrage ====

**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|VDN via chroot]] pour les mises en gardes !
==== Téléchargement des disques virtuels ====

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 :
<code>
cd vdn/networks/nomDuRéseau
export NETWORK_DIR=.
vdn-download-disks
</code>

==== Installation en réseau ====

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


===== Les réseaux =====

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 "demo" ====

{{ .:vdn.png?500 }}

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


==== Le réseau "routing-static" ====

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

==== Le réseau "routing-ospf" ====

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

==== Le réseau "routing-rip" ====

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

==== Le réseau "Firewall" ====

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 "Docker" ====

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


===== Utilisation =====

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" ;))

==== Particularités des systèmes virtuels ====

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 :

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

==== L'interface graphique ====

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 .|
|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). Cette console servira de dernier secours si les consoles ssh ne fonctionnent plus.|
|Ssh|Votre aire de jeu ;). Cet onglet vous permet d'ouvrir des connexions ssh sur les systèmes virtuels pour exécuter des commandes et lancer des applications graphiques.|


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

^Menu^Description^
|Network|Pour "ouvrir" ou "fermer" un réseau" et quitter l'application.|
|Scripts|Pour exécuter un script de préconfiguration ou de test (voir ci-dessous : [[#Scripts]]).|


==== Lancement des systèmes virtuels ====

  * 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).
==== Arrêt des systèmes virtuels ====

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

==== Menu contextuel  ====

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

|Start|Démarre la machine virtuelle.|
|Halt|Arrête la machine virtuelle (la sauvegarde des modifications sera effectuée)|
|Save|Sauvegarde immédiatement les modifications.|
|Ssh|Ouvre un nouveau terminal effectuant une connexion ssh vers le système virtuel.|
|Viewer|Ouvre un écran graphique sur la machine virtuelle (protocole Spice).
|Config|Édite le fichier de configuration de la machine virtuelle. Actif au prochain amorçage.|
|Infos|Affiche des informations sur la machine virtuelle (redirection des ports notamment).|
|Clean|Supprime le fichier de sauvegarde des modifications. A faire lorsque la machine virtuelle est "éteinte".|
|Kill|Tue le(s) processus associé(s) à la machine virtuelle. Attention, pas de sauvegarde effectuée.|

==== Scripts ====

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 !

==== Exécution d'applications graphiques ====

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. 


==== Écran graphique distant ====

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

==== Conclusion sur l'utilisation de VDN ====

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 [[guide#Foires aux questions|FAQ]] et la section [[guide#Limitations|Limitations]]. Pour installer VDN sur votre système GNU/Linux 64 bits (avec instructions de virtualisation activées) consulter "[[#telechargement_et_installation|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 [[https://fr.wikipedia.org/wiki/Trois_lois_de_la_robotique|M. Asimov]].


===== Administration =====


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.

==== Notes importantes ====

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




==== Organisation des fichiers =====

^ Chemin ^ Description ^
|bin| Répertoires des commandes VDN.|
|config.rc|Configuration par défaut de VDN.|
|config.template|Configuration par défaut d'un système virtuel.|
|files|Répertoires des fichiers communs : disques virtuels, ISO de cédéroms...|
|distribs|Répertoire spécifiques aux particularités des différents systèmes (hôtes ou virtuels). Pour la cuisine interne.|
|networks|Répertoire des réseaux.|



==== Le fichier de configuration global ====

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



==== Organisation d'un réseau ====

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

^ Fichier ^ Description ^
|build|Script de construction des machines virtuelles.|
|graph.svg|Dessin du graphique généré par la commande vdn-graph.|
|index.html|Documentation.|
|net.svg|Dessin "personnalisé" avec Inkscape.|
|network.vdn|Actuellement vide, uniquement utile comme "marqeur" pour "ouvrir" le réseau.|
|scripts|Répertoire des scripts du réseau.|

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.

===== Modifications d'un réseau =====

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.


===== Construction d'un nouveau réseau =====

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 ====

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 [[#Les redirections de ports|redirections de ports]] sont également affichées, ainsi que les services à activer.


==== Particularités des systèmes virtuels ===

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.


=== Les disques virtuels ===

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é** :

^ Type de sauvegarde ^ Système d'exploitation ^ Ordre de grandeur des modifications ^
|COW|quelconque supporté par KVM|quelconque| 
|TGZ |Debian/Kali modifiée fournie avec VDN|Limités à quelques fichiers (quelques dizaines de Mo maximum)|


=== Emulateur supportés ===

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

=== Disque auxiliaire ===

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

<note important>
Ce second disque est accédé en mode "direct" (aucun partage prévu).
</note>

=== Spécifier un CDROM ===

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.

<note important>
Les systèmes de type "TGZ" ne permettent pas l'amorçage sur cédérom.
</note>

=== Préciser un espace d'échange ===

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

=== Les réseaux ===

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

== Les réseaux virtuels entre systèmes virtuels ==

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" **

{{.:vdn.png}}

Les variables NETWORKS des différentes machines du réseau ont été configurées de la sorte :
<code>
     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
</code>
En éliminant les commentaires (#...) utilisés pour l'annotation du graphique, on obtient une description suffisante :
<code>
     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
</code>

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


== Le réseau entre hôte et machine virtuelle ==

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.

== Les redirections de ports ==

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.

<note important>
Les systèmes peuvent se voire affectés des redirections de port différentes à chaque démarrage
La commande ''vdn-infos nomSystem'' ou l'item Infos du menu contextuel d'une machine afficheront les redirections de ports en cours.
</note>


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


== La représentation graphique du réseau ==

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. 
===== Opérations classiques =====


==== Ajouter des paquets/fichiers ====

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


==== Créer un réseau ====

Copiez le répertoire d'un réseau et adaptez le. Exemple :
<code bash>
cp -a demo demo2
export NETWORK_DIR=$PWD/demo2
vdn-build-network
vdn-show
vdn-graph
</code>

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

==== Modifier un 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]]).

==== Supprimer un réseau =====

Supprimez le répertoire associé au réseau. Si des sauvegarde on été faites, supprimez les également. Exemple :
<code bash>
rm -Rf demo2
rm -Rf ~/vdn-save/demo2
</code>

Note : la commande vdn-manage-backups liste les sauvegardes
==== Gérer un disque "de base" ====

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

<note important>
Modifier un disque "de base" alors que des sauvegardes de type "COW" existent rendra ces dernières invalides !
</note>

=== Créer un disque "de base" ===

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

=== Modifier un disque de base ===

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

=== Spécialiser un disque "de base" ===

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

=== Supprimer un disque "de base" === 

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

<note important>
Si des systèmes utilisent ce disque via la technique COW, il ne fonctionneront plus.
</note>

==== Gérer un disque "vdn" ====

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

<note important>
Modifier un disque virtuel de type "VDN" alors que des sauvegardes de type "COW" existent rendra ces dernières invalides !
</note>

=== Créer un disque "vdn" ===



=== Modifier un disque "DIRECT" ===

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

<note important>
Modifier un disque virtuel de type "DIRECT" alors que des sauvegardes de type "COW" existent rendra ces dernières invalides !
</note>

<note>

Si vous installez un service et que vous ne souhaitez pas que tous les systèmes utilisant le disque ne le trouve démarré à l'initialisation pensez à le désactiver (''systemctl disable service''). Dans ce cas, à charge des systèmes souhaitant utiliser ce service de l'activer au démarrage (voir "Activation/désactivation d'un service").

</note>

=== Supprimer un disque "DIRECT" ===

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

==== Créer un système "DIRECT" préparé ====

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 

==== Gérer un disque "COW" ====

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

=== Créer un disque "COW" ===

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

=== Modifier un disque "COW" ===

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

=== Spécialiser un disque "COW" préparé ===

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.

=== Supprimer un disque "COW" ===

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

==== Gérer un système "TGZ" ====

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.

=== Créer une archive compressée "TGZ" ===

VDN le prends en charge

=== Modifier une archive compressée "TGZ" ===

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. 

<note>
Il est possible d'exclure les fichiers/répertoires de vos choix de la sauvegarde via la variable (du fichier de configuration du système) : ''SAVE_EXCLUDE''

Exemple :

SAVE_EXCLUDE="tmp var/tmp var/cache etc/systemd/system/default.target.wants"

</note>


=== Spécialiser une archive compressée "TGZ" ===

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 une archive compressée "TGZ" ===

supprimer le fichier.

==== Opération sur les systèmes virtuels VDN ====

=== Installation d'un logiciel/service ===

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.

<note warning>
  * **La modification d'un disque invalidera tous les systèmes de type "COW" utilisant ce disque !**
  * Aucune autre machine virtuelle ne devra utiliser le disque pendant que vous le modifiez !
</note>

<note>
Si le système direct du réseau zoo à pour vocation d’accueillir de nombreux services pour une spécialisation par les systèmes l'utilisant, il est conseillé de désinstaller les services supplémentaires après installation (''systemctl disable service''). Il est en effet plus efficace pour une machine d'activer un service que de le désactiver (''/etc/rc.local'').
</note>

=== Injection de fichiers de l'hôte vers un système virtuel ===

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.

=== Exécution d'un script à l'amorçage du système virtuel ===

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. 



===== Portages =====

<note warning>
En cours de mise au point.
</note>

==== Sous GNU/Linux ====

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.

==== Sous Windows ====

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

==== Autre Un*x ====

Il faudra porter switchLinux...


<note important>
Le système de conteneur utilisé par VDN est expérimental. Voir switchLinux. FIXME
</note> 

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




===== Autres solutions envisageable =====

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


==== Autres solutions envisageables ====

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








===== Performances =====

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.

^ Tests ^ Temps ^
| Avec instructions de virtualisation | <nowiki>0'15''</nowiki> |
| Sans instructions de virtualisation | <nowiki>2'20''</nowiki> |
| "nested" avec instructions de virtualisation | <nowiki>1'15''</nowiki> |
| "nested" sans instructions de virtualisation |  Pas évalué : trop long (> 60mn)|


===== Foires aux questions =====

==== Qu'est ce Virtual Didactic Network (VDN) ? ====

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 [[guide#Présentation]]).

==== Sous qu'elle Licence est distribué VDN ? ====

GPL V3 (voir [[guide#licence|Licence]]).

==== Quel est son stade de maturité ? ====

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.


==== Comment contacter l'équipe de développement ? ====

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

==== Comment obtenir une fenêtre un environnement graphique ====
 

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.


==== Comment obtenir un environnement graphique complet ====

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.

==== Perte de la connexion avec la machine virtuelle ====

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.



===== Limitations =====

==== VDN ne fonctionne pas sur mon système ====

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


==== Combien de machine virtuelles possibles ? ====

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 !

==== Échec de démarrage d'une machine virtuelle ====

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



==== Mon processeur ne dispose pas d'instructions de virtualisation ====

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


==== vdn : error : Pas de route par défaut ! ====


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


==== vdn : error : Une instance de l'interface graphique de VDN est déjà active ! ====

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. 



==== Masquages indésirables de fichiers ====

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.

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

==== Spécifier le répertoire temporaire ====

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

==== Intégration de paquets antagonistes ====

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.



===== Licence =====

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

===== Liens =====

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

  * [[http://www.debian.org/index.fr.html|Debian]]
  * [[http://www.linux-kvm.org|KVM]]
  * 
  * [[https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt|Overlay Filesystem]]

Un exemple d'utilisation de VDN

  * [[http://fr.wikibooks.org/wiki/Administration_réseau_sous_Linux|Administration réseau sous Linux (wikibook)]]

  * [[https://opale.u-clermont1.fr/vdn-files/doc/vdn-sozi-1.sozi.html|Quelques schémas]]
  * [[Quelques réflexions]]
  * [[Guide pour le concepteur de réseaux]]
  * [[Quelques notes techniques]]
===== Alternatives à VDN =====

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 :

  * [[http://www.marionnet.org/|marionnet]]
  * [[http://clownix.net|Clownix]]
  * [[http://wiki.netkit.org|Netkit]]
  * [[https://www.dit.upm.es/vnumlwiki/index.php/Main_Page|VNUML]]
Piste: • vdn-1920 • guide • quelques_notes_techniques • projet-2019-vdn • quelques_reflexions
Recherche

Boîte à outils
