Virtualisation de Reseau Rapport

BUCHER Aurélie
FRITZ Jean-Nicolas
LAMBERT Florian
LAMBERT Gaël
Projet tutoré 2008-2009
Virtualisation de réseau et supervision
Licence Pro ASRALL

Administration de systèmes, réseaux et applications à base de logiciels libres
Objectif : Mettre en place un réseau virtuel et réaliser sa supervision.

Sommaire
1. Introduction............................................................................................................. 2
1.1. Intérêt de la virtualisation ................................................................................. 2
1.2. Objectifs du projet ............................................................................................ 2
2. VirtualBox ............................................................................................................... 3
2.1. Fonctionnement global..................................................................................... 3
2.2. Commandes..................................................................................................... 3
2.2. Réseau............................................................................................................. 4
3. Installation de VirtualNet......................................................................................... 5
3.1. Modifications .................................................................................................... 5
3.3. Configuration.................................................................................................... 6
4. Création des images............................................................................................... 8
4.1. Choix des distributions utilisées ....................................................................... 8
4.2. Modification des iso de type squashfs.............................................................. 8
4.3. Modification des iso de type Posix script........................................................ 11
4.4. Scripts de démarrage..................................................................................... 14
5. Configuration des outils utilisés sur le serveur de supervision.............................. 15
5.1. Nagios2.......................................................................................................... 15
5.2. MRTG ............................................................................................................ 18
5.3. Apache........................................................................................................... 25
6. Scénario de réseau............................................................................................... 26
6.1. Trafic http ....................................................................................................... 26
6.2. Problème d’interface réseau .......................................................................... 26
7. Réseau final.......................................................................................................... 27
7.1. Test de charge ............................................................................................... 27
7.2. Schéma.......................................................................................................... 28
7.3. Fichier de topologie........................................................................................ 28
7.4. Suppléments pour le serveur de supervision ................................................. 29
8. Conclusion............................................................................................................ 31
9. Annexes................................................................................................................ 32
9.1. host-gateway_nagios2.cfg ............................................................................. 32
9.2. /etc/nagios2/conf.d/hostgroups_nagios2.cfg .................................................. 33
9.3. /etc/nagios2/conf.d/localhost_nagios2.cfg...................................................... 34
9.4. Mrtg.cfg .......................................................................................................... 35
9.5. Mrtg_serveur.cfg ............................................................................................ 40
9.6. Vie réseau.sh ................................................................................................. 42
9.7. Error_script_serveur.sh.................................................................................. 43
9.8. Error_script.sh................................................................................................ 44
9.9. error_script_modAutoCorrect.sh .................................................................... 45
9.10. error_script_serveur_modAutoCorrect.sh .................................................... 46
9.11. Feuilles d’heures .......................................................................................... 47
1. Introduction
1.1. Intérêt de la virtualisation
La virtualisation correspond à l’ensemble des techniques matérielles et/ou logicielles qui

permettent de faire fonctionner sur une seule machine plusieurs systèmes d’exploitation et/ou
plusieurs applications, séparément les uns des autres, comme s’ils fonctionnaient sur des
machines distinctes.
Pour que ceci soit possible, il faut que les capacités matérielles de la machine hôte soient
assez importantes (en processeur et mémoire vive notamment).
Les outils de virtualisation permettent de faire fonctionner ce que l’on appelle des
environnements virtuels. Les entreprises y ont de plus en plus recours à car elle leur permet
de gagner de la place dans les salles serveurs, de faciliter les installations et les redémarrages
après incidents, et de sécuriser les systèmes.
Chaque outil de virtualisation implémente une ou plusieurs de ces notions :

o couche d’abstraction matérielle et/ou logicielle ;
o systèmes d’exploitations (ou applications) « virtualisé(s) » ou « invité(s) » ;
o partitionnement, isolation et/ou partage des ressources physiques et/ou logicielles ;
o images manipulables : démarrage, arrêt, clonage, sauvegarde et restauration,
migration d’une machine physique à une autre ;
o réseau virtuel : réseau purement logiciel, interne, à la machine hôte, entre hôte et/ou
invité.
La virtualisation présente un grand nombre d’intérêts pour les entreprises :

o utilisation optimale des ressources d’un parc de machines (répartition des machines
virtuelles sur des machines physique en fonction des charges respectives) ;
o installation, déploiement et migration facile des machines virtuelles d’une machine
physique à une autre ;
o économie sur le matériel par mutualisation (consommation électrique, entretient
physique, monitoring, support…) ;
o sécurisation et/ou isolation d’un réseau (cassage des systèmes d’exploitation virtuels,
mais pas des systèmes d’exploitation hôtes qui sont invisibles pour l’attaquant) ;
o diminution des risques liés au dimensionnement des serveurs lors de la définition de
l’architecture d’une application, l’ajout de puissance (nouveau serveur par exemple)
étant alors transparente.
La virtualisation possède également des intérêts pédagogiques :

o simplicité : pouvoir simuler un réseau sur une machine sans avoir besoin d’autant de
machines qu’il y a d’hôtes sur le réseau simulé ;
o possibilité de simuler le fonctionnement de réseaux complexes (sous réserve de
ressources matérielles suffisantes) ;
1.2. Objectifs du projet
L’objectif de notre projet était de simuler un réseau via la virtualisation en utilisant une solution
existante. Sur ce réseau, nous devions mettre en place des solutions de supervision (MRTG,
SNMP, Nagios) permettant notamment de détecter des pannes sur les différents éléments.
Virtualisation de réseau et supervision 2/49

2. VirtualBox
2.1. Fonctionnement global
Sous VirtualBox, la manipulation des machines virtuelles nécessite plusieurs étapes :

o création d’un disque dur virtuel (VDI). Nous pouvons soit créer un disque virtuel de
taille fixe, soit utiliser un live-cd. Cette deuxième solution permet d’obtenir un disque
virtuel n’occupant que peu de place ;
o créer une nouvelle machine virtuelle. Un fichier de description de la machine,
comportant des différents paramètres de configuration, est crée ;
o rattacher le disque VDI et l’image ISO du système d’exploitation invité à la machine
virtuelle ;
o configurer le réseau de la machine virtuelle
o Lancer la machine virtuelle.
Pour exécuter ces actions, il existe plusieurs possibilités :

o grâce à l'interface graphique, on peut réaliser ses actions sans difficultés. On peut
également manipuler les disques VDI et les images ISO rattachées aux machines
virtuelles via le gestionnaire de disque virtuel ;
o on peut aussi utiliser la commande VboxManage.
2.2. Commandes
Installation de VirtualBox
sudo apt-get install virtualbox
Création d'une machine virtuelle

VBoxManage createvdi -filename lenomdudisque -size 2000
A ce moment, le système nous renvoi

UUID: 17fad189-9155-4e52-bd9b-596a666beec5
Création d'une image disque virtuelle

VBoxManage registerimage dvd /home/…/Bureau/Projet_tut/Finnix-92.1.iso
Création d'une machine virtuelle

BoxManage createvm -name nom_de_machine -register
Le système répond
Virtual machine 'nom_de_machine' is created and registered.
UUID: fdde2f5c-2e96-4a33-a820-7538b6fae9f0
Settings file: '/home/…/.VirtualBox/Machines/nom_de_machine/nom_de_machine.xml'
Attribution de la mémoire vive à la machine
VBoxManage modifyvm nom_de_machine -memory "128MB"
Association du disque avec la machine

VBoxManage modifyvm nom_de_machine -hda lenomdudisque
Association de l'iso du système (de la distribution)

VBoxManage modifyvm nom_de_machine -dvd /home/…/Bureau/Projet_tut/Finnix-92.1.iso
Nous obtenons ainsi une machine virtuelle.

Pour la lancer, nous utilisons la commande
BoxManage startvm nom_de_machine

Si tout se déroule comme prévu, on obtient le message :
VirtualBox Command Line Management Interface Version 2.0.4_OSE
(C) 2005-2008 Sun Microsystems, Inc.
All rights reserved.
Waiting for the remote session to open...
Remote session has been successfully opened.
2.2. Réseau
Virtualbox possède 3 modes de fonctionnement réseau :
o Réseau interne : les machines virtuelles sont confinées entre elles dans un réseau virtuel.
o NAT : Les machines virtuelles peuvent accéder à internet via une connexion NAT.
o Adaptateur réseau hôte : Les machines virtuelles utilisent une interface de l’ordinateur hôte
pour accéder au réseau.
Le projet Virtualnet utilise les adaptateurs réseau hôtes pour connecter les machines virtuelles au
réseau. C’est pour cette raison que nous allons voir plus précisément son fonctionnement.
10.0.X.X 10.0.X.X
192.168.0.X
Tap1 Tap2 eth0 eth0 Tap2 Tap1
Bridge Bridge
Explication : Sur notre ordinateur hôte, nous pouvons voir des machines virtuelles (réseau 10.0.X.X).
Ces machines virtuelles sont connectées sur des interfaces virtuelles appellées Tap. Les Tap sont
elles-même connectées sur un pont virtuel (bridge).
Le Bridge virtuel joue le rôle de switch et pont réseau, via ce bridge les interfaces Tap peuvent
communiquer entre elles. Mais il est possible d’y attacher aussi une interface physique de l’ordinateur
hôte (eth0). Dans le but d’atteindre un autre ordinateur physique qui possède lui aussi des machines
virtuelles.
Il est donc possible de créer un réseau de machines virtuelles reliées par un réseau physique. Cette
technique peut étre utile si nous voulons ajouter plusieurs machines virtuelles sur des ordinateurs qui
n’en supportent qu’un nombre limité.

3. Installation de VirtualNet
3.1. Modifications
Lors du premier essai, nous avons constaté que le logiciel VirtualNet contenait une erreur au
lancement de la commande
virtualnet –r <Fichier_topologie>
Cette erreur empêchait le bon fonctionnement du logiciel. Nous avons donc étudié le code
source. Il s’est avéré que l’erreur apparaissait lors de la spécification d’une image iso pour les
hôtes et les routeurs.
Cette erreur était due à une taille trop petite du tableau machine_temp→machine→affichage.
case 6:
if(fscanf(network, "%s %s %s %s %s %s\n",
machine_temp->machine->nom,
machine_temp->machine->iface.mac,
machine_temp->machine->iface.ip,
machine_temp->machine->iface.mask,
machine_temp->machine->iface.def_route,
machine_temp->machine->affichage)==0)
printf("echec lecture2, indice de boucle %d\n",i);
if(strcmp(machine_temp->machine->affichage,"masquer_ecran")==0){
strcpy(machine_temp->machine->affichage,"0");
strcpy(machine_temp->machine->iso,_ISO_MACHINE);
}else{
strcpy(machine_temp->machine->iso,machine_temp->machine->affichage);
strcpy(machine_temp->machine->affichage,"1");
}
Extrait du code du fichier parser.c
Le sixième paramètre optionnel est stocké en premier lieu dans machine_temp → machine →
affichage. Une comparaison est ensuite réalisée pour déduire si ce paramètre définit
l'emplacement de l'iso où le paramètre d'affichage.
On peut ainsi constater que affichage est limité à 25 octets, ce qui est, dans certains cas, trop
petit pour indiquer l'url de l'iso.
De ce fait, nous avons modifié, dans le fichier parser.h, à la ligne 81

char affichage[25]
En
char affichage[150];
Ce problème est également présent pour l'emplacement de l'image du routeur. Nous avons
donc modifié de la même manière le fichier parser.h, à la ligne 119
char affichage[150];
De plus, lors des tests du serveur de supervision, nous avons constaté que le navigateur
IceWeasel se fermait toutes les cinq minutes. Après quelques tests, nous nous sommes aperçu
que ce problème apparaissait lors du lancement de la commande mrtg par le démon cron. Il
s’est avéré que la mémoire virtuelle attribuée au serveur au lancement de VirtualNet était
insuffisante.
La solution consistait à modifier le code source de VirtualNet de façon à allouer plus de
mémoire virtuelle au serveur.
Nous avons pour cela modifié le script de lancement des machines virtuelles,
virtualnet/src/vm.sh.

Les modifications se réalisent à partir de la ligne 51. Il faut remplacer
echo -e "----------------------------------------------------\nAllocation de 128MB de

VBoxManage modifyvm $1 -memory "128MB" >> /var/log/log_vm.log
Par
if [ `echo $3 | grep serveur_knoppix.iso` ]; then

echo -e "----------------------------------------------------\nAllocation de 200MB de RAM" >>
/var/log/log_vm.log
else
echo -e "----------------------------------------------------\nAllocation de 128MB de RAM" >>
/var/log/log_vm.log
fi
Ceci permet de détecter le nom de l’image. S’il correspond à serveur_knoppix.iso, la

commande VBoxManage –memory alouera 200mb de mémoire virtuelle.
3.2. Pré requis

Afin de faire fonctionner VirtualNet, nous avons tout d’abord installé les packages :
o automake : permet d’installer VirtualNet (génère des makefiles);
o bridge-utils : permet de créer des ponts virtuels afin de relier entre elles différentes
interfaces réseau ;
o uml_utilities ;
o iproute ;
o dhcp3-server : permet d’utiliser un serveur DHCP.
Nous avons également du générer nos images systèmes :

o une image pour les hôtes, à partir d’une distribution Finnix. Nous avons modifié le
menu de boot de départ, afin que le système démarre en mode texte. De plus, nous
avons mis le clavier en français. Pour finir, nous avons intégré un agent SNMP et
installé ab et lynx.
o une image pour le routeur, également à partir d’une distribution Finnix. Comme pour
l’hôte, nous avons modifié le boot de départ, modifié le clavier, et intégré un agent
SNMP ;
o une image pour le serveur de supervision, basée sur Knoppix. Nous avons de
nouveau intégré un agent SNMP ainsi que des outils de supervision, et modifié le
boot de départ ;
o une image pour un serveur Apache, basée sur Finnix. Comme pour toutes les
machines, nous avons intégré un agent SNMP, modifié le clavier et le boot prompt.
3.3. Configuration
VirtualNet se base sur un fichier de description du réseau.

Ce dernier peut-être, par exemple :
#--------------------------------
#Fichier de Topologie d'exemple
#--------------------------------
#H
#|
# SSS SSS
# H--SSS-----R----SSS--H
#
#-------------------------

#Adresse du reseau et mask
10.0.0.0 255.0.0.0
#
#--------------------------------------------------------------------
#Ici on liste les machines en commençant par 'h: '
#<nom> <@MAC> <@IP> <@mask> <routepardef> (option_ecran) (chemin_ISO)
#option_ecran : masquer_ecran
#chemin_ISO : chemin absolu vers une iso particuliere
h: hote1 00:08:0E:5E:5B:5A 10.1.0.5 255.255.0.0 10.1.0.254
h: hote2 00:08:0E:5E:5B:5B 10.2.0.5 255.255.0.0 10.2.0.254
h: hote3 00:08:0E:5E:5B:5C 10.2.0.6 255.255.0.0 10.2.0.254
#
#-------------------------------------------------
#Ici on liste les routeurs en commençant par 'r: '
#<nom> <nbr_interface> (option_ecran) (chemin_ISO)
r: router1 masquer_ecran
1 00:08:0E:5E:5B:62 10.1.0.254 255.255.0.0
2 00:08:0E:5E:5B:63 10.2.0.254 255.255.0.0
#
#------------------------------------------------
#Ici on liste les bridges en commençant par 'b: '
#<nom> <@ip> <@mask> <nb_machines> <nb_routeurs>
b: switch1 10.1.0.1 255.255.0.0
hote1
router1 1
b: switch2 10.2.0.1 255.255.0.0
router1 2
hote2
hote3
#
#----------------------------
#Finir le fichier par end :-)
end
On commence par définir le réseau à utiliser : 10.0.0.0 avec un masque 255.0.0.0

Puis, on liste les hôtes que l’on veut démarrer. Ici, nous avons trois hôtes
Ensuite, on liste les routeurs, avec leurs interfaces. Pour ce fichier, il y a un seul routeur avec
deux interfaces.
Pour finir, on indique les switchs, les hôtes connectés dessus, ainsi que le routeur (avec son
numéro d’interface) sur lequel les hôtes sont connectés.
Ici, Nous avons l’hôte1 connecté au switch1 (10.1.0.1), lui-même connecté à l’interface 1 du
routeur 1 (router1 1). Les hôtes 2 et 3 sont connectés au switch2 (10.2.0.1) lui-même relié à
l’interface 2 du routeur 2.
VirtualNet fonctionne avec la commande

virtualnet –option <FICHIER_TOPOLOGIE>
Les options possibles sont les suivantes :
o -r, -reseau : crée un réseau virtuel à partir du fichier de topologie ;
o -n, -nettoyage : nettoie le réseau virtuel en fonction du fichier de topologie ;
o -d, -debug : affiche le fichier de topologie tel qu’il est construit en mémoire.
Les switchs sont représentés par des interfaces TUN/TAP. Ces derniers permettent de créer
une interface réseau virtuelle.

4. Création des images
4.1. Choix des distributions utilisées
Pour nos images hôtes et routeur, nous avons choisi une

distribution Finnix. En effet, cette distribution, basée sur
Debian, a pour avantage d’être très légère et de posséder des
outils de base tels que tcpdump, dont nous avons besoin.
L’image du serveur Apache quant à elle, est basée sur une
distribution Finnix.
Pour finir, l’image du serveur de supervision est Evinux,

basée sur Knoppix. Cette distribution, en plus d’être légère,
possède plusieurs outils nécessaires à notre projet, et
dispose également d'une interface graphique. C'est donc une
image idéale pour notre serveur.
4.2. Modification des iso de type squashfs
Pour modifier une distribution Linux, nous devons commencer par organiser un répertoire de
travail. Ce répertoire contiendra des dossiers où nous placerons les fichiers de l’image iso ainsi
que son système de fichiers compressé.
o Création d’un dossier de travail

mkdir ~/image
cd ~/image
mkdir iso
mkdir extract
mkdir squashfs
Ensuite nous allons monter l’image iso de la distribution que nous voulons modifier, et copier
son contenu dans le dossier extract :
o Montage et copie de l’iso

mount -o loop finnix.iso iso
cp -a iso/. extract/
umount iso
Une fois l’iso copiée, nous allons extraire le système de fichier compressé afin d’y installer les
applications souhaitées :

o Montage et extraction du squashfs
mount -t squashfs -o loop extract/FINNIX/FINNIX iso
cp -a iso/. squashfs
umount iso
Note : dans le système de fichier compressé, on retrouve une arborescence linux standard.
Avant d’installer des applications dans notre distribution, nous allons préparer ce dont nous
aurons besoin pour effectuer le chroot.
o Préparation du chroot
On commence par rajouter notre sources.list et désactiver certains dépôts

cat /etc/apt/sources.list | tee squashfs/etc/apt/sources.list
gedit squashfs/etc/apt/sources.list
Nous allons ensuite copier notre fichier resolv.conf pour permettre la résolution d’adresse à
l’environnement chrooter. De plus, nous allons monter les répertoires /proc et /sys permettant
d’avoir accès à Internet.
cp /etc/resolv.conf squashfs/etc/resolv.conf
mount -t proc -o bind /proc squashfs/proc
mount -t sys -o bind /sys squashfs/sys
Nous pouvons à présent utiliser chroot pour installer les paquets nécessaires. (Exemple dans la
partie 5. Configuration des outils utilisés)
o Passage en CHROOT
chroot squashfs /bin/bash
chroot:/# apt-get update
Une fois dans le chroot nous pouvons installer des paquets avec la commande suivante :
chroot:/# apt-get install ...
Avant de quitter le chroot, ne pas oublier de démonter les interfaces /proc et /sys
chroot:/# umount /sys
chroot:/# umount /proc
chroot:/# rm /etc/resolv.conf
chroot:/# exit
Nous pouvons ensuite effacer l’ancien système de fichier compressé.

rm extract/FINNIX/FINNIX
Il est possible de faire un backup à cette étape pour pouvoir modifier par la suite cette image
sans repartir de zéro
o Sauvegarde
mkdir squashfs.backup
mkdir extract.backup

cp -a squashfs/. squashfs.backup
cp -a extract/. extract.backup
Nous pouvons alors reconstruire notre système de fichiers compressé (en squashfs)
o Reconstruction du système de fichiers

cd squashfs
mksquashfs . ../extract/FINNIX/FINNIX
Une fois le système de fichiers compressé généré, nous pouvons créer notre image iso
bootable :
o Création de l’iso bootable

cd ..
mkisofs -r -V "Finnix Live CD" -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-
emul-boot -boot-load-size 4 -boot-info-table -o finnix.iso extract

4.3. Modification des iso de type Posix script
Modifier une image Knoppix ou Evinux de type Posix script ressemble de très près à la
modification des images de squashfs, cependant, certaines étapes importantes varient.
Comme pour la modification d’image Finnix, nous devons commencer par organiser un
répertoire de travail. Ce répertoire contiendra des dossiers où nous allons extraire les fichiers
de l’image iso.
o Création d’un dossier de travail

mkdir ~/image
cd ~/image
mkdir iso
mkdir extract
mkdir squashfs
Pour extraire nos fichiers, nous allons monter notre iso puis copier son contenu dans le dossier
extract.
o Montage et copie de l'iso

mount -o loop Evinux.iso iso
cp -a iso/. extract/
umount iso
En tapant la commande file, on peut constater que c’est ici que réside la principale différence
entre les systèmes de fichiers compressés en squashfs, et ceux compressés en Posix script.
file KNOPPIX
KNOPPIX: POSIX shell script text executable
Nous allons extraire le système de fichier. Le principe est le même que précédemment, seule la
commande est différente.
Note : dans le système de fichier compressé, on retrouve une arborescence linux standard.
Pour l’étape suivante le paquet cloop-utils est nécessaire

apt-get install cloop-utils

Nous allons convertir le système de fichiers compressés en format .iso.
o Extraction du système de fichier compressé vers une iso

extract_compressed_fs extract/KNOPPIX/KNOPPIX > cimage.iso
Nous devons maintenant monter l’image
o Monter l’iso
mount -o loop cimage.iso iso
Enfin, nous allons copier le contenu de cette image en utilisant la commande rsync afin d’éviter
la duplication des liens forts.
o Copie du système de fichier compressé

rsync -Hav iso/. squashfs
umount iso
Avant d’installer des applications dans notre distribution, nous allons préparer ce dont nous
aurons besoin pour effectuer le chroot.
o Préparation du chroot
Nous allons copier notre fichier resolv.conf pour permettre l’accès à Internet en chroot. De
plus, nous allons monter les répertoires /proc et /sys.
cp /etc/resolv.conf squashfs/etc/resolv.conf
mount -t proc -o bind /proc squashfs/proc
mount -t sys -o bind /sys squashfs/sys
Nous pouvons à présent utiliser chroot pour installer les paquets nécessaires. (Exemple dans la
partie 5. Configuration des outils utilisés)
o Passage en CHROOT
chroot squashfs /bin/bash

chroot:/# apt-get update
Une fois dans le chroot nous pouvons installer des paquets avec la commande suivante :
chroot:/# apt-get install ...
Avant de quitter le chroot, ne pas oublier de démonter les interfaces /proc et /sys
chroot:/# umount /sys
chroot:/# umount /proc
chroot:/# rm /etc/resolv.conf
chroot:/# exit

Nous pouvons dés lors reconstruire notre système de fichiers compressé.
o Reconstruction du squashfs
mkisofs -pad -D -l -R -U squashfs | create_compressed_fs - 65536 > KNOPPIX.new
Nous allons effacer l’ancien système de fichiers compressé et le remplacer par le nouveau
o Effacer le système compressé

rm extract/KNOPPIX/KNOPPIX
mv KNOPPIX.new extract/KNOPPIX/KNOPPIX
Une fois le système de fichiers compressé généré, nous pouvons créer notre image iso
bootable.
o Génération du live cd modifié

mkisofs -no-emul-boot -boot-load-size 4 -boot-info-table -pad -l -r -J -v -b \
exécution/isolinux/isolinux.bin -c exécution/isolinux/boot.cat extract > knoppix_remastered.iso

4.4. Scripts de démarrage
A - Boot prompt
Pour enlever le choix des différents modes de boot et forcer par défaut le mode « text », il faut
modifier le fichier isolinux/isolinux.cfg contenu dans l’iso, puis régénérer l’image avec la
méthode décrite ci-dessus.
Pour cela, nous avons remplacé
DEFAULT vesamenu.c32
Par
DEFAULT text
B - Paquets installés
Nous avons installés sur les images des hôtes, du routeur et du serveur Apache un agent
SNMP. Pour cela, nous avons utilisé la méthode décrite dans le paragraphe précédent, traitant
de la modification des images de type squashfs.
Nous avons ensuite configuré les agents SNMP comme suit :
Pour rendre les agents accessibles par le réseau, il faut remplacer, dans le fichier
/etc/default/snmp la ligne :
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'
Par
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid'
Pour permettre de lire toute la MIB, dans le fichier /etc/snmp/snmpd.conf, il faut remplacer
# sec.name source community
com2sec paranoid default public
#com2sec readonly default public
Par
# sec.name source community
#com2sec paranoid default public
com2sec readonly default public
Pour vérifier si l’agent SNMP fonctionne, on peut, par exemple, utiliser la commande :
snmpwalk -c public -v1 127.0.0.1 .1.3
C - Script de démarrage du routeur

Pour qu’une machine virtuelle puisse servir de routeur, elle doit être capable de transmettre les
paquets IP d’une interface à une autre. Sur les images Finnix, cette fonction est désactivée par
défaut.
De ce fait, il faut créer un script qui sera exécuté au démarrage de la machine.
#script de parametrage de Finnix en routeur
#activer IP forwarding sur la machine
echo 1 > /proc/sys/net/ipv4/ip_forward
#redemarrer le service reseau
/etc/init.d/networking restart
echo "IP forwarding actif !"
#clavier en francais
loadkeys fr
Ce script, placé dans /etc/init.d/script_r.sh, permet d’activer l’ip forwarding, de redémarrer le

service réseau, d’afficher un message de confirmation, et pour finir, de mettre le clavier en
français.
Pour que ce script se lance au démarrage, il faut créer un lien symbolique :
ln -s /etc/init.d/script_r.sh /etc/rc2.d/S02script_r
D - Script de démarrage des hôtes

Pour mettre le clavier en français sur les hôtes, il faut réaliser la même procédure que
précédemment, avec le script suivant :
#clavier en francais
loadkeys fr

5. Configuration des outils utilisés sur le serveur de supervision
5.1. Nagios2
Pour commencer, il faut modifier une ligne du fichier /etc/default/apache2 sur le serveur de
supervision, afin que Apache se lance au démarrage de la machine.
# 0 = start on boot; 1 = don't start on boot
NO_START=0
La première configuration à réaliser concerne l’authentification de Nagios. Nous pouvons soit

configurer le mot de passe, soit le supprimer complètement.
Configuration de bases
A - Configuration du mot de passe

Sur Nagios2, l’authentification se réalise via un fichier .htaccess. De ce fait, il nous suffit de
configurer un nouveau fichier avec la commande :
htpasswd -c /etc/nagios2/htpasswd.users nagios
B - Suppression du mot de passe

Pour désactiver l’authentification par .htaccess, il faut commenter la balise DirectoryMatch dans
le fichier de configuration de Nagios2 (/nagios2/apache2.conf).
vim etc/nagios2/apache2.conf
Puis modifier comme suit :

<DirectoryMatch (/usr/share/nagios2/htdocs|/usr/lib/cgi-bin/nagios2)>
Options FollowSymLinks
DirectoryIndex index.html
AllowOverride AuthConfig
Order Allow,Deny
Allow From All
#AuthName "Nagios Access"
#AuthType Basic
#AuthUserFile /etc/nagios2/htpasswd.users
#require valid-user
</DirectoryMatch>
Pour des raisons pratiques, nous avons préféré la deuxième solution.
C - Les scripts cgi

Sur les pages de Nagios2 il arrive d’avoir des messages informant d’un problème
d’authentification des scripts cgi. Pour corriger ce problème il faut commencer par éditer le
fichier /etc/nagios2/cgi.cfg
vim /etc/nagios2/cgi.cfg
Puis mettre la valeur use_authentification à 0

use_authentication=0
Concernant la configuration de Nagios, nous allons commencer par configurer la définition des
hosts via le fichier /etc/nagios2/conf.d/host-gateway_nagios2.cfg
Nous déclarons tous les hosts ainsi que leurs parents
define host {
host_name routeur_1
alias routeur interface 0
address 10.1.0.254
use generic-host
}
define host {

host_name switch_1
alias switch 1
address 10.1.0.1
use generic-host
parents routeur_1
}
define host {
host_name hote1
alias hote 1
address 10.1.0.5
use generic-host
parents switch_1
}
Chaque define host contient la définition d’une machine du réseau, le champ important pour
construire la topologie du réseau est le champ parents. Dans cet exemple nous constatons bien
que l’hote1 est relié au switch_1, qui est lui-même relié au routeur_1.
Hote 1 Switch 1 Routeur 1

10.1.0.5 10.1.0.1 10.1.0.254

Nous avons ensuite modifié le fichier /etc/nagios2/conf.d/hostgroups_nagios2.cfg. Ce
dernier contient les configurations des groupes. Chaque groupe correspond à la définition d’un
service, qui lui-même utilise une commande. Nagios contient des commandes qui lui sont
propres et qui sont semblables aux commandes système.
Par exemple, nous trouvons une commande check_ping, qui est un script exécutable qui réalise
un ping et qui peut être utilisé par Nagios.
Cette commande, avec ses paramètres est définie dans le fichier de configuration commande
de Nagios2.
Ensuite des services utilisant ces commandes sont définis dans le fichier services qui pourra
être utilisé par un groupe d’host. C’est ce que nous avons fait ci-dessous.
...
# A list of your web servers
define hostgroup {
hostgroup_name http-servers
alias HTTP servers
members apache
}
# A list of your ssh-accessible servers

#define hostgroup {
# hostgroup_name ssh-servers
# alias SSH servers
# members localhost
# }
define hostgroup {
hostgroup_name ping-servers
alias Pingable servers
members *
}
...
Globalement nous avons ajouté les hosts au services qui leurs correspondent. Le serveur
apache pour http etc…
Nous avons aussi supprimé le service ssh car nos hosts ne le possèdent pas.
Pour finir, nous avons modifié le fichier /etc/nagios2/conf.d/localhost_nagios2.cfg

Ce fichier contient la définition du localhost ainsi que différent services qui lui sont accessibles.
Dans ce fichier nous avons simplement définit que l’host serveur était parent de localhost et
nous avons laissé quelques services disponible tel que l’espace disque, …
define host{
use generic-host ; Name of host template to use
host_name localhost
alias localhost
address 127.0.0.1
parents serveur
}
# Define a service to check the disk space of the root partition

# on the local machine. Warning if < 20% free, critical if
# < 10% free space on partition.
define service{
use generic-service ; Name of service template to use
host_name localhost
service_description Disk Space
check_command check_all_disks!20%!10%
}
...

5.2. MRTG
A - Installation
L’installation de MRTG se réalise en plusieurs étapes :
Installation :
apt-get install mrtg
Création du dossier qui contiendra les scripts de génération des graphiques :

mkdir /etc/mrtg
Création du dossier qui contiendra l’affichage web de MRTG :

mkdir /var/www/mrtg
Pour que les graphiques de MRTG soient rafraîchit toutes les cinq minutes, il fait ajouter la ligne
suivante dans /etc/crontab
0-59/5 * * * * root env LANG=C /usr/bin/mrtg /etc/mrtg.cfg
B - Configuration
La commande cfgmaker va nous permettre de générer une configuration de base :
cfgmaker --global 'WorkDir: /var/www/mrtg' --global 'Language: french' --global 'Options[_]:
bits,growright' --ifdesc=descr public@localhost --output /etc/mrtg.cfg
Fichier de configuration /etc/mrtg.cfg obtenu :

Target[localhost_2]: 2:public@localhost:
SetEnv[localhost_2]: MRTG_INT_IP="10.3.0.5" MRTG_INT_DESCR="eth0"
MaxBytes[localhost_2]: 1250000
Title[localhost_2]: eth0 -- serveur
PageTop[localhost_2]: <H1>eth0 -- serveur</H1>
<div id="sysdetails">
<table>
<TR>
<TD>System:</TD>
<TD>serveur in Unknown (edit /etc/snmp/snmpd.conf)</TD>
</TR>
<TR>
<TD>Maintainer:</TD>
<TD>Root <root@localhost> (configure /etc/snmp/snmp.conf)</TD>
</TR>
<TR>

<TD>Description:</TD>
<TD>eth0 </TD>
</TR>
<TR>
<TD>ifType:</TD>
<TD>ethernetCsmacd (6)</TD>
</TR>
<TR>
<TD>ifName:</TD>
<TD></TD>
</TR>
<TR>
<TD>Max Speed:</TD>
<TD>1250.0 kBytes/s</TD>
</TR>
<TR>
<TD>Ip:</TD>
<TD>10.3.0.5 (serveur)</TD>
</TR>
</TABLE>
</div>
La commande indexmaker permet de générer la page web contenant les graphiques MRTG.
Cette page est basée sur le fichier /etc/mrtg.cfg
indexmaker --columns=1 --sort=descr --sidebyside /etc/mrtg.cfg --
output=/var/www/mrtg/index.html
C - Ajout des graphiques eth0

Nous avons ajouté, pour chaque hôte, et pour le serveur Apache, un graphique retraçant le
trafic de leur interface eth0.
Pour cela, il faut ajouter les lignes suivantes dans le fichier /etc/mrtg.cfg :
Target[10.3.0.6_eth0]: 2:public@10.3.0.6:
SetEnv[10.3.0.6_eth0]: MRTG_INT_IP="10.3.0.6" MRTG_INT_DESCR="eth0"
MaxBytes[10.3.0.6_eth0]: 1250000
Title[10.3.0.6_eth0]: eth0 -- apache
PageTop[10.3.0.6_eth0]: <h1>eth0 -- apache</h1>
<table>
<tr>
<td>System:</td>
<td>apache in Unknown (configure /etc/snmp/snmpd.conf)</td>
</tr>
<tr>
<td>Maintainer:</td>
<td>Root <root@localhost> (configure
/etc/snmp/snmpd.conf)</td>
</tr>
<tr>
<td>Description:</td>
<td>eth0 </td>
</tr>
<tr>
<td>ifType:</td>
<td>ethernetCsmacd (6)</td>
</tr>
<tr>
<td>ifName:</td>
<td>eth0</td>
</tr>
<tr>

<td>Max Speed:</td>
<td>100.0 Mbits/s</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.3.0.6 (apache)</td>
</tr>
</table>
</div>
D - Ajout de graphiques de trafic pour Apache

Le package lynx est nécessaire pour le bon fonctionnement du script suivant.
Ce dernier génère deux graphiques :
o le premier va compter le nombre de requêtes que reçoit notre serveur Apache
o le second est un graphique de trafic
Il doit être placé dans le répertoire /etc/mrtg/apache2

#!/usr/bin/perl
# can return hits or bytes (counters)
@res = `lynx -dump http://10.3.0.6:80/server-status`;
foreach $res (@res) {
if ($res =~ /Server uptime: (.*)$/) { $up = $1; last } else { next }
if ($res =~ /Server at/) { $server = $res; last } else { next }
}
@res = `lynx -dump http://10.3.0.6:80/server-status?auto`;
foreach $res (@res) {

if ($res =~ /Total Accesses: (\d+)/) { $d1 = $1; next }
if ($res =~ /Total kBytes: (\d+)/) { $d2 = $1 * 1024; next }
}
$d1 = int($d1);
$d2 = int($d2);
if ($ARGV[0] eq "hits") {
print "$d1\n";
print "$d1\n";
} elsif ($ARGV[0] eq "bytes") {
print "$d2\n";
print "$d2\n";
}
print "$up\n";
print "$server";

Il faut lui associer des droits rwx------ pour que les graphiques puissent être générés :
chmod 700 /etc/mrtg/apache2
Afin que les graphiques soient affichés sur la page Web, il faut rajouter les lignes suivantes au fichier
/etc/mrtg.cfg :
#---------Apache2 hits-----------------------
Target[apache2_hits]: `/etc/mrtg/apache2 hits`
Options[apache2_hits]: perhour, nopercent, growright, noinfo, nobanner, noi
PageTop[apache2_hits]: <h1>Hits Apache2</h1>
MaxBytes[apache2_hits]: 1000000
YLegend[apache2_hits]: hits/heure
ShortLegend[apache2_hits]: par heure
LegendO[apache2_hits]: Hits:
Legend2[apache2_hits]: Hits horaires
Legend4[apache2_hits]: Hits Horaires max
Title[apache2_hits]: Hits horaires du serveur Apache
WithPeak[apache2_hits]: wmy
#------------End Apache2 Hits------------------
#---------Apache2 Traffic-----------------------
Target[apache2_traffic]: `/etc/mrtg/apache2 bytes`
Options[apache2_traffic]: nopercent, growright, noinfo, nobanner, noi
PageTop[apache2_traffic]: <h1>Traffic Apache</h1>
MaxBytes[apache2_traffic]:16000
AbsMax[apache2_traffic]:20000
YLegend[apache2_traffic]: octets/s
ShortLegend[apache2_traffic]: o/s
LegendO[apache2_traffic]: Traffic Apache:
Legend2[apache2_traffic]: Traffic Apache
Title[apache2_traffic]: Traffic du serveur Apache
WithPeak[apache2_traffic]: wmy
Legend4[apache2_traffic]: Traffic max Apache
#------------End Apache2 Traffic------------------

Pour finir, il faut régénérer la page Web à l’aide de la commande
indexmaker --columns=1 --sort=descr --sidebyside /etc/mrtg.cfg --
output=/var/www/mrtg/index.html
Graphiques MRTG du serveur de supervision

E - Ajout des interfaces du routeur
Pour ajouter un graphique permettant le suivi du trafic des interfaces du routeur, il suffit de
rajouter, à la fin du fichier /etc/mrtg.cfg, les lignes suivantes.
MaxBytes[10.1.0.254_eth0]: 1250000
Title[10.1.0.254_eth0]: eth0 -- routeur1
PageTop[10.1.0.254_eth0]: <h1>eth0 -- routeur1</h1>
<table>
<tr>
<td>System:</td>
<td>routeur in Unknown (configure
</tr>
<tr>
</tr>
<tr>
<td>eth0 </td>
</tr>
<tr>
<td>ifType:</td>
</tr>
<tr>
<td>ifName:</td>
<td>eth0</td>
</tr>
<tr>
<td>Max Speed:</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.1.0.254 (routeur1)</td>
</tr>
</table>
</div>

D – Implantation de mrtg sur le réseau
/serveur
Serveur
10.3.0.5
/mrtg
Apache
10.3.0.6
Switch 3
10.3.0.1
.254
.254 .254
Switch 1
10.1.0.1 Switch 2
10.2.0.1
Routeur
Hote 2
Hote 1 10.2.0.5
10.1.0.5
Ce schéma représente une vision globale du réseau ainsi que les différents points surveillés par mrtg
qui est intégré sur le serveur de supervision réseau.
Chaque Correspond aux statistiques relevées par snmp (trafique réseau …) puis affichées sous forme de
graphiques par mrtg.
Les graphiques mrtg sont séparés sur 2 pages :
http://localhost/mrtg : statistiques sur le fonctionnement général du réseau
http://localhost/serveur : informations du serveur de supervision (espace disque, charge cpu …)

5.3. Apache
Notre serveur Apache se base sur l’image que nous avons générée pour les hôtes Finnix.
Il faut installer le package Apache2, avec la procédure décrite dans la partie précédente.
Il faut ensuite ajouter les lignes suivantes dans le fichier /etc/apache2/apache2.conf, qui
permettront d’accéder aux statistiques du serveur apache par tous les hosts et le serveur :
<Location /server-status>
SetHandler server-status
Order deny,allow
#Deny from all
Allow from all
</Location>
ExtendedStatus On
Nous avons ensuite créé quelques pages Web dans /var/www sur le thème de notre projet.
Ce site sera utilisé pour simuler un trafic sur le réseau.
Index :
Virtualnet :

6. Scénario de réseau
6.1. Trafic http
Le trafic réseau est simulé grâce au script vie_reseau.sh présent sur tous les clients.
Ce script est lancé au démarrage de la machine et exécute diverses requêtes à destination du
serveur où d'autres clients.
Chaque requête est exécutée immédiatement durant l'exécution du script.
Celui-ci se relancera toutes les minutes, via l'utilisation de la commande at.
Un fichier de log (/tmp/log_vie) contient les numéros des requêtes que le client a envoyées.
Le script de vie du réseau suit la description d’algorithme suivante :
o choix éventuel de l'ip du client à tester ;
o sélection aléatoire de la requête à exécuter ;
o exécution de la requête ;
o génération de la durée avant ré exécution du script ;
o programmation de la ré exécution du script.
6.2. Problème d’interface réseau
Il est simple de couper un ordinateur du réseau, et de nombreuses possibilités existent pour

nous permettre de tester les outils de supervision.
Tout comme pour la simulation d'un trafic réseau, les erreurs sont provoquées par le script
error_script.sh qui est exécuté lors du démarrage d'un client. Ce script choisit un type d'erreur
et programme son apparition pour entre 5 à 10 minutes après le choix de celle ci. Le script en
lui-même sera ré exécuté 1 à 20 minutes après la fin de sa dernière exécution, si cela est
possible, pour provoquer de nouvelles erreurs.
Il existe quatre versions de ce script, l'une error_script.sh étant destinée aux machines client
et une autre, error_script_serveur.sh spécifiquement créé pour le serveur web du réseau.
Les deux versions sont modifiées pour auto-corriger la plupart des erreurs au bout d'un certain
temps (5 ou 10 minutes), le script pour client est error_script_modAutoCorrect.sh et celui
dédié au serveur, error_script_serveur_modAutoCorrect.sh.
Un fichier de log est créé durant l'exécution du script à l'emplacement suivant: /tmp/log Il
contient les numéros des erreurs créées.

Le script provoquant des erreurs dans le réseau suit la description d’algorithme suivante :
o génération du temps aléatoire avant relance du script ;
o programmation de la ré exécution du script via la commande at ;
o choix aléatoire du type d'erreur à effectuer ;
o génération d'un temps variable avant l'exécution de l'erreur ;
o programmation de l'erreur via la commande at ;
o fin de l'exécution du script.
7. Réseau final
7.1. Test de charge
Nous avons réalisé un test de charge, afin de déterminer par la suite un fichier de topologie
optimal.
Notre idée de base était d’avoir 10 machines, 1 routeur, 4 switchs, un serveur apache et un
serveur graphique de supervision. Cette configuration nous aurait permis d’obtenir des résultats
très complets et précis.
Nous avons rapidement réalisé qu’au vu des performances de l’ordinateur qui nous était fourni,
cet objectif ne pourrait pas être atteint.
Nous sommes donc parti sur un système dégressif, en réduisant progressivement le nombre de
machines.
Au final, nous sommes arrivés à un fichier minimaliste, mais nous permettant tout de même des
résultats très intéressants.
Notre fichier final comporte :
o deux hôtes ;
o un routeur ;
o trois switchs ;
o un serveur Apache ;
o un serveur graphique de supervision.

7.2. Schéma
7.3. Fichier de topologie
Notre fichier de topologie final est le suivant :
#--------------------------------
#Fichier de Topologie d'exemple
#
#--------------------------------
# serveur
# |
# SSS
# apache--SSS
# |
# H1--SSS-----R----SSS--H2
# SSS SSS
#
#-------------------------
#Adresse du réseau et du masque
10.0.0.0 255.0.0.0
#
#--------------------------------------------------------------------

#Ici on liste les machines en commençant par 'h: '
#<nom> <@MAC> <@IP> <@mask> <routepardef> (option_ecran) (chemin_ISO)
#option_ecran : masquer_ecran
#chemin_ISO : chemin absolu vers une iso particuliere
h: hote1 00:08:0E:5E:5B:5A 10.1.0.5 255.255.0.0 10.1.0.254 ~/host_finnix.iso
h: hote2 00:08:0E:5E:5B:6A 10.2.0.5 255.255.0.0 10.2.0.254 ~/host_finnix.iso
h: apache 00:08:0E:5E:5B:7A 10.3.0.6 255.255.0.0 10.3.0.254 ~/apache_finnix.iso
h: serveur 00:08:0E:5E:5B:7B 10.3.0.5 255.255.0.0 10.3.0.254 ~/serveur_knoppix.iso
#
#
#-------------------------------------------------
#Ici on liste les routeurs en commençant par 'r: '
#<nom> <nbr_interface> (option_ecran) (chemin_ISO)
r: router1 ~/routeur_finnix.iso
1 00:08:0E:5E:5B:62 10.1.0.254 255.255.0.0
2 00:08:0E:5E:5B:63 10.2.0.254 255.255.0.0
3 00:08:0E:5E:5B:64 10.3.0.254 255.255.0.0
#
#------------------------------------------------
#Ici on liste les bridges en commençant par 'b: '
#<nom> <@ip> <@mask> <nb_machines> <nb_routeurs>
b: switch1 10.1.0.1 255.255.0.0
hote1
router1 1
b: switch2 10.2.0.1 255.255.0.0
hote2
router1 2
b: switch3 10.3.0.1 255.255.0.0
apache
serveur
router1 3
#
#----------------------------
end
Nous travaillons sur le réseau 10.0.0.0 de masque 255.0.0.0.

Nous avons donc deux hôtes ayant pour adresse IP 10.1.0.5/16 et 10.2.0.5/16.
Le serveur Apache a pour adresse IP 10.3.0.6/16.
Pour finir, le serveur de supervision a pour adresse 10.3.0.5/16.
On remarque que les machines sont sur des sous réseaux différents.
Le routeur (appelé router1) possède trois interfaces : 10.1.0.254/16 ; 10.2.0.254/16 et
10.3.0.254/16. Ces interfaces correspondent aux trois sous réseaux qui seront connectés
dessus.
Pour finir, nous avons les switchs.
On voit que le premier switch d’adresse IP 10.1.0.1/16 est relié à la machine hote1. Ce switch
est également relié à l’interface 1 du routeur router1.
L’hôte2 est relié au switch2, qui est lui-même relié à l’interface 3 du routeur router3.
Le serveur Apache et le serveur de supervision sont connectés au switch3, qui est lui-même
relié à l’interface 3 du routeur router3.
7.4. Suppléments pour le serveur de supervision
A - Création d’une page d’index
Nous avons créé une page d’index sur le serveur de supervision permettant d’accéder
facilement aux pages de Nagios, à celles de MRTG pour les clients, et à celle de MRTG pour le
serveur Apache.
Pour cela, dans le fichier /var/www/index.php, nous avons mis les lignes suivantes :

<style type="text/css">
.text2 a, a:visited{font-family: Arial, Helvetica, sans-serif;font-size: 18px;color: Silver;text-align :
left; text-decoration: none;}
.text2 a:hover {text-decoration: underline;}
.titre1 {font-family: Arial, Helvetica, sans-serif;font-size: 18px;font-weight: bold;color:
#FFFFFF;}
</style>
<body bgcolor="#525A73">
<div align="center" class="titre1"> Liens : </div>
<div align="center" class="titre1">
<table border="0" class="text2" >

<tr>
<td>
<a href="/nagios2">-- Nagios2</a>
<td>
</tr>
<tr>
<td>
<a href="/serveur" >-- Mrtg (serveur)</a>
<td>
</tr>
<tr>
<td>
<a href="/mrtg" >-- Mrtg</a>
<td>
</tr>
<tr>
<td>
<a href="http://10.3.0.6 " >-- Serveur Apache</a>
<td>
</tr>
</table>
</div>
Aperçu du resultat :

B - Paramétrage de la page par défaut
Nous avons configuré la page par défaut du navigateur IceWeasel sur le serveur de supervision
afin qu’à l’ouverture nous tombions directement sur la page d’index créée précédemment.
Pour cela, dans le fichier /etc/iceweasel/profile/prefs.js, nous avons modifié la valeur
suivante :
user_pref("browser.startup.homepage", "http://localhost/");
C – Modification du Boot Prompt
Pour finir, nous avons enlevé le boot prompt en modifiant, au moment de la création de l’image,
dans le fichier /extract/boot/isolinux.cfg, la valeur suivante :
TIMEOUT 1
8. Conclusion
Ce projet tutoré nous a permis d’approfondir nos connaissances en virtualisation. Il nous a
également permis de mettre en pratique et de compléter nos connaissances en supervision.
Nous avons également appris à modifier une distribution Linux ainsi que les contraintes que
cela apporte.
Pour conclure, nous pouvons dire que ce que nous avons mis en œuvre peut s’avérer pratique
pour faire des démonstrations d’un réseau « réel ». Par contre l’inconvénient de l’utilisation de
live CD restreint son utilisation car avec cette méthode il n’est pas possible de sauvegarder son
travail puis, relancer les machines virtuelles comme elles étaient à leur dernier état. De plus, la
modification de ces live CD demande un minimum de compétences et rend plus difficile
certaines installations et configurations de logiciels.
Nous pouvons tout de même reconnaître que ce projet nous a réellement intéressé car, il nous
a fait travailler sur plusieurs domaines différents (réseau, programmation, supervision, …). De
plus, une fois pris en mains, il est possible pour toute personne de réaliser son propre scénario
réseau. Et ainsi perfectionner ses compétences dans ce domaine sans avoir besoin d’une
multitude d’ordinateurs à disposition.
Nous tenons à remercier M. NATAF, qui nous a accompagné et aiguillé tout au long de ce
projet.

9. Annexes
9.1. host-gateway_nagios2.cfg
# a host definition for the gateway of the default route

define host {
host_name serveur
alias Serveur
address 10.3.0.5
use generic-host
parents switch_3
}
define host {
host_name apache
alias Apacher serveur
address 10.3.0.6
use generic-host
parents switch_3
}
define host {
host_name hote1
alias hote 1
address 10.1.0.5
use generic-host
parents switch_1
}
define host {
host_name hoste2
alias hoste 2
address 10.2.0.5
use generic-host
parents switch_2
}
define host {
host_name routeur_1
address 10.1.0.254
use generic-host
}
define host {
host_name routeur_2
address 10.2.0.254
use generic-host
}
define host {
host_name routeur_3
address 10.3.0.254
use generic-host
}

define host {
host_name switch_2
alias switch 2
address 10.2.0.1
use generic-host
parents routeur_2
}
define host {
host_name switch_3
alias switch 3
address 10.3.0.1
use generic-host
parents routeur_3
}
define host {
host_name switch_1
alias switch 1
address 10.1.0.1
use generic-host
parents routeur_1
}
9.2. /etc/nagios2/conf.d/hostgroups_nagios2.cfg
# Some generic hostgroup definitions
# A simple wildcard hostgroup

define hostgroup {
hostgroup_name all
alias All Servers
members apache, hoste2, hote1, localhost, serveur
}
# A list of your Debian GNU/Linux servers

define hostgroup {
hostgroup_name debian-servers
alias Debian GNU/Linux Servers
members localhost
}
# A list of your web servers

define hostgroup {
hostgroup_name http-servers
alias HTTP servers
members apache
}
# A list of your ssh-accessible servers

#define hostgroup {
# hostgroup_name ssh-servers
# alias SSH servers
# members localhost
# }
# nagios doesn't like monitoring hosts without services, so this is

# a group for devices that have no other "services" monitorable
# (like routers w/out snmp for example)
define hostgroup {

hostgroup_name ping-servers
alias Pingable servers
members *
}
9.3. /etc/nagios2/conf.d/localhost_nagios2.cfg
# A simple configuration file for monitoring the local host

# This can serve as an example for configuring other servers;
# Custom services specific to this host are added here, but services
# defined in nagios2-common_services.cfg may also apply.
#
define host{
use generic-host ; Name of host template to use
host_name localhost
alias localhost
address 127.0.0.1
parents serveur
}
# Define a service to check the disk space of the root partition

# on the local machine. Warning if < 20% free, critical if
# < 10% free space on partition.
define service{
host_name localhost
service_description Disk Space
check_command check_all_disks!20%!10%
}
# Define a service to check the number of currently logged in

# users on the local machine. Warning if > 20 users, critical
# if > 50 users.
define service{
host_name localhost
service_description Current Users
check_command check_users!20!50
}
# Define a service to check the number of currently running procs

# on the local machine. Warning if > 250 processes, critical if
# > 400 users.
define service{
host_name localhost
service_description Total Processes
check_command check_procs!250!400
}
# Define a service to check the load on the local machine.

define service{
host_name localhost
service_description Current Load
check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0
}
9.4. Mrtg.cfg
# Created by
# /usr/bin/cfgmaker --global 'WorkDir: /var/www/mrtg' --global 'Language: french' --global
'Options[_]: bits,growright' --ifdesc=descr public@localhost --output /etc/mrtg.cfg
### Global Config Options
# for UNIX
# WorkDir: /home/http/mrtg
# for Debian
WorkDir: /var/www/mrtg
# or for NT
# WorkDir: c:\mrtgdata
### Global Defaults
# to get bits instead of bytes and graphs growing to the right

# Options[_]: growright, bits
EnableIPv6: no
WorkDir: /var/www/mrtg
Language: french
Options[_]: bits,growright
Target[localhost_2]: 2:public@localhost:
SetEnv[localhost_2]: MRTG_INT_IP="10.3.0.5" MRTG_INT_DESCR="eth0"
MaxBytes[localhost_2]: 1250000
Title[localhost_2]: eth0 -- serveur
PageTop[localhost_2]: <H1>eth0 -- serveur</H1>
<table>
<TR>
<TD>System:</TD>
<TD>serveur in Unknown (edit /etc/snmp/snmpd.conf)</TD>
</TR>
<TR>
<TD>Maintainer:</TD>
<TD>
Root <root@localhost> (configure /etc/snmp/snmp.conf)
</TD>
</TR>
<TR>
<TD>Description:</TD>
<TD>eth0 </TD>
</TR>
<TR>
<TD>ifType:</TD>
<TD>ethernetCsmacd (6)</TD>

</TR>
<TR>
<TD>ifName:</TD>
<TD></TD>
</TR>
<TR>
<TD>Max Speed:</TD>
<TD>1250.0 kBytes/s</TD>
</TR>
<TR>
<TD>Ip:</TD>
<TD>10.3.0.5 (serveur)</TD>
</TR>
</TABLE>
</div>
MaxBytes[10.1.0.5_eth0]: 1250000
Title[10.1.0.5_eth0]: eth0 -- host1
PageTop[10.1.0.5_eth0]: <h1>eth0 -- host1</h1>
<table>
<tr>
<td>System:</td>
</tr>
<tr>
</tr>
<tr>
<td>eth0 </td>
</tr>
<tr>
<td>ifType:</td>
</tr>
<tr>
<td>ifName:</td>
<td>eth0</td>
</tr>
<tr>
<td>Max Speed:</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.1.0.5 (host1)</td>
</tr>
</table>
</div>
MaxBytes[10.2.0.5_eth0]: 1250000
Title[10.2.0.5_eth0]: eth0 -- host2
PageTop[10.2.0.5_eth0]: <h1>eth0 -- host2</h1>
<table>

<tr>
<td>System:</td>
</tr>
<tr>
</tr>
<tr>
<td>eth0 </td>
</tr>
<tr>
<td>ifType:</td>
</tr>
<tr>
<td>ifName:</td>
<td>eth0</td>
</tr>
<tr>
<td>Max Speed:</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.2.0.5 (host2)</td>
</tr>
</table>
</div>
MaxBytes[10.3.0.6_eth0]: 1250000
Title[10.3.0.6_eth0]: eth0 -- apache
PageTop[10.3.0.6_eth0]: <h1>eth0 -- apache</h1>
<table>
<tr>
<td>System:</td>
</tr>
<tr>
<td>
Root <root@localhost> (configure /etc/snmp/snmpd.conf)
</td>
</tr>
<tr>
<td>eth0 </td>
</tr>
<tr>
<td>ifType:</td>
</tr>
<tr>
<td>ifName:</td>
<td>eth0</td>
</tr>
<tr>

<td>Max Speed:</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.3.0.6 (apache)</td>
</tr>
</table>
</div>
#---------Apache2 hits-----------------------
Target[apache2_hits]: `/etc/mrtg/apache2 hits`
Options[apache2_hits]: perhour, nopercent, growright, noinfo, nobanner, noi
PageTop[apache2_hits]: <h1>Hits Apache2</h1>
MaxBytes[apache2_hits]: 1000000
YLegend[apache2_hits]: hits/heure
ShortLegend[apache2_hits]: par heure
LegendO[apache2_hits]: Hits:
Legend2[apache2_hits]: Hits horaires
Legend4[apache2_hits]: Hits Horaires max
Title[apache2_hits]: Hits horaires du serveur Apache
WithPeak[apache2_hits]: wmy
#------------End Apache2 Hits------------------
#---------Apache2 Traffic-----------------------
Target[apache2_traffic]: `/etc/mrtg/apache2 bytes`
Options[apache2_traffic]: nopercent, growright, noinfo, nobanner, noi
PageTop[apache2_traffic]: <h1>Traffic Apache</h1>
MaxBytes[apache2_traffic]:16000
AbsMax[apache2_traffic]:20000
YLegend[apache2_traffic]: octets/s
ShortLegend[apache2_traffic]: o/s
LegendO[apache2_traffic]: Traffic Apache:
Legend2[apache2_traffic]: Traffic Apache
Title[apache2_traffic]: Traffic du serveur Apache
WithPeak[apache2_traffic]: wmy
Legend4[apache2_traffic]: Traffic max Apache
#------------End Apache2 Traffic------------------
MaxBytes[10.1.0.254_eth0]: 1250000
<table>
<tr>
<td>System:</td>
<td>routeur in Unknown (configure /etc/snmp/snmpd.conf)</td>
</tr>
<tr>
</tr>
<tr>
<td>eth0 </td>
</tr>
<tr>
<td>ifType:</td>

</tr>
<tr>
<td>ifName:</td>
<td>eth0</td>
</tr>
<tr>
<td>Max Speed:</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.1.0.254 (routeur1)</td>
</tr>
</table>
</div>
MaxBytes[10.2.0.254_eth1]: 1250000
<table>
<tr>
<td>System:</td>
</tr>
<tr>
</tr>
<tr>
<td>eth1 </td>
</tr>
<tr>
<td>ifType:</td>
</tr>
<tr>
<td>ifName:</td>
<td>eth1</td>
</tr>
<tr>
<td>Max Speed:</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.2.0.254 (routeur2)</td>
</tr>
</table>
</div>
MaxBytes[10.3.0.254_eth2]: 1250000
<table>

<tr>
<td>System:</td>
</tr>
<tr>
</tr>
<tr>
<td>eth2 </td>
</tr>
<tr>
<td>ifType:</td>
</tr>
<tr>
<td>ifName:</td>
<td>eth2</td>
</tr>
<tr>
<td>Max Speed:</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.3.0.254 (routeur3)</td>
</tr>
</table>
</div>
9.5. Mrtg_serveur.cfg
WorkDir: /var/www/serveur
Language: french
IconDir: images/
Target[serveur_charge]: `/var/www/serveur/mrtg-sys/charge.pl`
PageTop[serveur_charge]: <h1>charge moyenne de serveur x 100</h1>
Options[serveur_charge]: growright, gauge
MaxBytes[serveur_charge]: 10000
Title[serveur_charge]: charge de serveur x 100
Ylegend[serveur_charge]: charge x 100
Legend1[serveur_charge]: charge moyenne a 1 minute
Legend2[serveur_charge]: charge moyenne a 5 minutes
LegendI[serveur_charge]: 1 minute
LegendO[serveur_charge]: 5 minutes
ShortLegend[serveur_charge]: jobs
Target[serveur_proc]: `/var/www/serveur/mrtg-sys/proc.pl`
PageTop[serveur_proc]: <h1>nb de process de serveur</h1>
Options[serveur_proc]: absolute, growright, gauge
MaxBytes[serveur_proc]: 1000000
Title[serveur_proc]: process de serveur
Ylegend[serveur_proc]: nb
Legend1[serveur_proc]: nb de process
Legend2[serveur_proc]: nb de process
LegendI[serveur_proc]: nb
LegendO[serveur_proc]: nb

ShortLegend[serveur_proc]: process
Target[serveur_cpu]: `/var/www/serveur/mrtg-sys/cpu.pl`
PageTop[serveur_cpu]: <h1>CPU usage de serveur en %</h1>
Options[serveur_cpu]: growright
MaxBytes[serveur_cpu]: 100000000
Title[serveur_cpu]: espace disponible de serveur en %
Ylegend[serveur_cpu]: %
Legend1[serveur_cpu]: user
Legend2[serveur_cpu]: system + nice
LegendI[serveur_cpu]: user
LegendO[serveur_cpu]: system + nice
ShortLegend[serveur_cpu]: %
Target[serveur_tcp]: `/var/www/serveur/mrtg-sys/tcp.pl`
PageTop[serveur_tcp]: <h1>Nombre de connexion TCP simu</h1>
Options[serveur_tcp]: absolute, growright, gauge
MaxBytes[serveur_tcp]: 100000000
Title[serveur_tcp]: nombre de connexion TCP simu
Ylegend[serveur_tcp]: nombre
Legend1[serveur_tcp]: total
Legend2[serveur_tcp]: ESTABLISHED
LegendI[serveur_tcp]: total
LegendO[serveur_tcp]: ESTABLISHED
ShortLegend[serveur_tcp]: nombre
Target[serveur_inter]: `/var/www/serveur/mrtg-sys/interrupt.pl`
PageTop[serveur_inter]: <h1>interrupts reseau et HD de serveur</h1>
Options[serveur_inter]: growright
MaxBytes[serveur_inter]: 1000000000000
Title[serveur_inter]: interrupts reseau et HD de serveur
Ylegend[serveur_inter]: interrupts
Legend1[serveur_inter]: reseau
Legend2[serveur_inter]: HD
LegendI[serveur_inter]: reseau
LegendO[serveur_inter]: HD
ShortLegend[serveur_inter]: interrupts
Target[serveur_mem]: `/var/www/serveur/mrtg-sys/mem.pl`
PageTop[serveur_mem]: <h1>memoire physique libre de serveur en %</h1>
Options[serveur_mem]: growright, gauge
MaxBytes[serveur_mem]: 1000000
Title[serveur_mem]: memoire physique libre de serveur en %
Ylegend[serveur_mem]: memoire
Legend1[serveur_mem]: shared/total
Legend2[serveur_mem]: mem utilise
LegendI[serveur_mem]: shared/total
LegendO[serveur_mem]: mem utilise
ShortLegend[serveur_mem]: %
Target[serveur_ctxt]: `/var/www/serveur/mrtg-sys/ctxt.pl`
PageTop[serveur_ctxt]: <h1>ctxt/processes de serveur</h1>
Options[serveur_ctxt]: growright
MaxBytes[serveur_ctxt]: 1000000000
Title[serveur_ctxt]: ctxt/processes de serveur
Ylegend[serveur_ctxt]: ctxt/processes
Legend1[serveur_ctxt]: ctxt
Legend2[serveur_ctxt]: processes
LegendI[serveur_ctxt]: ctxt
LegendO[serveur_ctxt]: processes
ShortLegend[serveur_ctxt]: nb

Target[serveur_eth0]: `/var/www/serveur/mrtg-sys/eth0.pl`
PageTop[serveur_eth0]: <h1>bits recu/emis de serveur</h1>
Options[serveur_eth0]: growright
MaxBytes[serveur_eth0]: 1000000000000000000000
Title[serveur_eth0]: packets recu/emis de serveur
Ylegend[serveur_eth0]: packets recu/emis
Legend1[serveur_eth0]: bit recu
Legend2[serveur_eth0]: bit emis
LegendI[serveur_eth0]: bit recu
LegendO[serveur_eth0]: bit emis
ShortLegend[serveur_eth0]: bits
Target[serveur_lo]: `/var/www/serveur/mrtg-sys/lo.pl`
PageTop[serveur_lo]: <h1>bits recu/emis de serveur</h1>
Options[serveur_lo]: growright
MaxBytes[serveur_lo]: 1000000000000000000000
Title[serveur_lo]: packets recu/emis de serveur
Ylegend[serveur_lo]: packets recu/emis
Legend1[serveur_lo]: bit recu
Legend2[serveur_lo]: bit emis
LegendI[serveur_lo]: bit recu
LegendO[serveur_lo]: bit emis
ShortLegend[serveur_lo]: bits
Target[serveur_espace]: `/var/www/serveur/mrtg-sys/espace.pl`
PageTop[serveur_espace]: <h1>espace disponible sur / et /home de serveur en %</h1>
Options[serveur_espace]: absolute, growright, gauge
MaxBytes[serveur_espace]: 1000
Title[serveur_espace]: espace disponible de serveur en %
Ylegend[serveur_espace]: %
Legend1[serveur_espace]: /home
Legend2[serveur_espace]: /
LegendI[serveur_espace]: /home
LegendO[serveur_espace]: /
ShortLegend[serveur_espace]: %
9.6. Vie réseau.sh
#!/bin/bash
#Script père, choix du type d'action auto-appel via at

#Valable pour clients et routeurs
# il sera ré-exécuté toutes les minutes
ip1="10.1.0.5"
ip2="10.2.0.5"
serveur_web="10.3.0.6"
#choix de l'ip à tester

test=$(($RANDOM%1+1))
case $test in
1)
ip=$ip1
;;
2)
ip=$ip2
;;
esac

rand=$(($RANDOM%5+1))
echo $rand
case $rand in
1) ping -a -c 3 -b -q $ip
at now + 1 minute <<< "ping -a -c 3 -b -q "$ip
echo "on ping une machine"
;;
2) ab -n 100 $serveur_web."/index.php"
echo "larguage de ab"
;;
3) echo "data1=blabla&data2=blabla2" | lynx -dump -post_data $serveur_web/index.php
echo "data1=blabla&data2=blabla2" | lynx -dump -post_data $serveur_web/index.php
echo "envoi requête web"
;;
4) nmap -sP 10.1-3.0.5-6
echo "mapping du réseau"
;;
5) netstat $ip
echo "test d'un client"
;;
6) netstat $serveur_web
echo "test du serveur"
;;
esac
time=$(($RANDOM%20+20))
at now + time minute <<< "./vie_script.sh >> /tmp/log_vie"
9.7. Error_script_serveur.sh
#!/bin/bash
#Script père, choix du type d'erreur et auto-appel via at

#Valable pour les serveurs
# il sera ré-exécuté entre 1 et 20 minutes
#L'erreur sera mise en place 5 à 10 minutes après le déclanchement du script
at now + $time minutes «< ”./error_script.sh » /tmp/log”
time2=$(($RANDOM%5+5))
case $rand in
1) #changement de l'adresse IP
at now + $time2 minutes «< “ifconfig eth0 127.0.99.5”
echo “1”
;;
2) #extinction brutale de la machine sans reboot
at now + $time2 minutes «< “shutdown -h now”
echo “2”
;;
3) #extinction brutale de la machine puis reboot
at now + $time2 minutes «< “shutdown -r now”
echo “3”
;;

4) #down d'une carte réseau
at now + $time2 minutes «< “ifconfig eth0 down”
echo “4”
;;
5) #interdiction de répondre au ping
at now + $time2 minutes «< “echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all”
echo “5”
;;
6) #extinction de snmp
at now + $time2 minutes «< ”/etc/init.d/snmpd stop”
echo “6”
;;
7) #changement de l'adresse de broadcast sur localhost = création d'une boucle
at now + $time2 minutes «< “ifconfig -broadcast localhost”
echo “7”
;;
8) #extinction d'apache
at now + $time2 minutes «< ”/etc/init.d/apache2 stop”
echo “8”
;;
esac
9.8. Error_script.sh
#!/bin/bash


at now + $time minutes <<< ”./error_script.sh » /tmp/log”
case $rand in
at now + $time2 minutes <<< “ifconfig eth0 127.0.99.5”
echo “1”
;;
2) #extinction brutale du client sans reboot
at now + $time2 minutes <<< “shutdown -h now”
echo “2”
;;
3) #extinction brutale du client puis reboot
at now + $time2 minutes <<< “shutdown -r now”
echo “3”
;;
at now + $time2 minutes <<< “ifconfig eth0 down”
echo “4”
;;
at now + $time2 minutes <<< “echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all”
echo “5”
;;
6) #extinction du client snmp

at now + $time2 minutes <<< ”/etc/init.d/snmpd stop”
echo “6”
;;
at now + $time2 minutes <<< “ifconfig -broadcast localhost”
echo “7”
;;
esac
9.9. error_script_modAutoCorrect.sh
#!/bin/bash

#L'erreur sera mise en place 5 à 10 minutes après le déclenchement du script
at now + $time minutes <<< "./error_script.sh >> /tmp/log"
case $rand in
at now + $time2 minutes <<< "ifconfig eth0 127.0.99.5"
echo "1"
;;
2) #extinction brutale du client sans reboot
at now + $time2 minutes <<< "shutdown -h now"
echo "2"
;;
3) #extinction brutale du client puis reboot
at now + $time2 minutes <<< "shutdown -r now"
echo "3"
;;
4) #down d'une carte réseau puis up quelques minutes plus tard
at now + $time2 minutes <<< "ifconfig eth0 down"
time3=$time2+5
at now + $time3 minutes <<< "ifconfig eth0 up"
echo "4"
;;
at now + $time2 minutes <<< "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"
time3=$time2+5
echo "5"
;;
6) #extinction du client snmp puis relance au bout de 10 mn
at now + $time2 minutes <<< "/etc/init.d/snmpd stop"
time3=$time2+10
echo "6"
;;
at now + $time2 minutes <<< "ifconfig -broadcast localhost"

echo "7"
;;
esac
9.10. error_script_serveur_modAutoCorrect.sh
#!/bin/bash

#Valable pour les serveurs
at now + $time minutes <<< "./error_script.sh >> /tmp/log"
case $rand in
at now + $time2 minutes <<< "ifconfig eth0 127.0.99.5"
echo "1"
;;
2) #extinction brutale de la machine sans reboot
at now + $time2 minutes <<< "shutdown -h now"
echo "2"
;;
3) #extinction brutale de la machine puis reboot
at now + $time2 minutes <<< "shutdown -r now"
echo "3"
;;
at now + $time2 minutes <<< "ifconfig eth0 down"
time3=$time2+5
at now + $time3 minutes <<< "ifconfig eth0 up"
echo "4"
;;
time3=$time2+10
echo "5"
;;
6) #extinction de snmp
time3=$time2+10
echo "6"
;;
at now + $time2 minutes <<< "ifconfig -broadcast localhost"
echo "7"
;;
8) #extinction d'apache
at now + $time2 minutes <<< "/etc/init.d/apache2 stop"
time3=$time2+10

at now + $time2 minutes <<< "/etc/init.d/apache2 start"
echo "8"
;;
esac
9.11. Feuilles d’heures
BUCHER Aurélie :
4h : Lecture et compréhension du rapport VirtualNet (téléchargement des sources)

3h : Prise en main de VirtualBox
3h : Prise en main de VirtualNet
40mn : Installation d’un Ubuntu virtuel pour test
2h : Test de plusieurs fichiers de topologie
1h : Création du fichier de topologie
6h : Test de charge, préparation d’un ordinateur pour la démonstration
1h : Détermination de la topologie la plus adaptée
1h : Création du fichier de topologie final après test de charge
2h : Test du réseau final
5h : Test d’une technique de création d’images
2h30 : Rédaction d’articles sur le wiki
4h : Recherches diverses
2h : Recherche de la distribution hôte
3h : Recherche de la distribution serveur
17h : Rédaction, correction et mise en forme du rapport
2h : Démonstration du projet
4h : Réunions avec le tuteur
Total : 63h10
Jean-Nicolas FRITZ :
4h : Lecture et analyse du rapport sur VirtualNet (téléchargement des sources)

2h : Tests et tentative de prise en main de la version non corrigée de VirtualNet
3h : Prise en main de VirtualBox
1h : Rédaction d’un tutoriel pour VirtualBox
4h : Tentative de création d’un parser pour fichiers de topologie
4h : Installation et prise en main de VirtualNet
4h : Réunions, recherches et choix d’images iso à modifier
4h : Recherche de distributions Linux légères
6h : Recherches diverses sur la virtualisation de réseaux
1h : Algorithmes des scripts de simulation de trafic réseau et d’apparition d’erreurs
3h : Recherche des commandes les plus appropriées pour les scripts
2h : Tests des commandes en local
4h : Réalisation des scripts
1h : Finalisation des scripts
2h : Test des scripts
1h : Rédaction du rapport sur les scripts via le wiki
2h : Modification des scripts après réunion
2h : Test de fonctionnement des scripts modifiés
30mn : Modification de l’article du wiki
2h30 : Test du projet
1h : Mise en fonctionnement du projet pour voir les effets sur MRTG
Total : 54h

Florian LAMBERT :

1h : Installation de VirtualBox et test d’installation Ubuntu
4h : Mise en place de VirtualNet, test d’images, identification des erreurs
1h : Création d’un fichier de topologie test, test de ce dernier
3h : Analyse et correction du script VirtualNet, écriture d’un article pour le rapport
4h : Recherche pour la modification et la création des iso
3h : Création d’une première distribution
6h : Modification d’une image (SNMP), création d’une image routeur et hôte
2h : Rédaction d’un article pour le rapport
3h30 : Test de création d’une image modifié Evinux (Knoppix)
4h : Réunion, réinstallation du projet (image Knoppix et ajout du fichier de topologie)
2h : Configuration de MRTG
1h : Recherche de scripts MRTG
3h30 : Ajout de graphiques MRTG, configuration des services SNMP sur le routeur et les
hôtes
2h : Correction des scripts MRTG non fonctionnels
1h : Intégration de Nagios2 dans l’image serveur
3h : Génération d’une nouvelle image serveur, configuration du boot, installation des paquets
requis
2h : Création de l’image Apache, configuration du serveur Web, test sur le réseau virtuel
2h : Rédaction d’un article pour le rapport, configuration MRTG sur un PC réel, configuration
SNMP
4h : Modification de l’image serveur, ajout et configuration MRTG, ajout de nouveaux
graphiques, test
6h30 : Modification de l’image hôte « buguée », installation de ab et lynx, ajout de atd au
démarrage, mise en place des scripts au démarrage, configuration du serveur
1h30 : Analyse et résolution du problème du serveur de supervision (ram), rédaction de la
solution
4h : Modification des deux fichiers de configuration de MRTG, test de fonctionnement, mise
en place du réseau pour les impressions d’écrans des graphiques, création d’une image iso
Finnix pour illustrer le rapport
4h : Correction des derniers problèmes mrtg (script), test de fonctionnement, rédaction et
création de schéma dans le rapport
3h : Création et intégration d'un site sur le serveur web, génération de l’image serveur finale
et rédaction du rapport
1h : Test de fonctionnement des interfaces tun/tap, recherche pour la démonstration et
expérimentation de comportement réseau
3h : Correction des scripts réseau, intégration des nouveaux scripts réseaux sur les hosts,
test des images et la génération des graphiques et vérification finale du rapport
Total : 80h00
Gaël LAMBERT :

4h : Recherches, achat d’un domaine et mise en place du wiki, création de sa structure
3h : Test, installation de machines virtuelles (VirtualBox, VirtualNet, fichier de topologie de
test)
2h : Recherches diverses sur Internet
1h30 : Installation d’un Debian et d’un Ubuntu sur VirtualBox pour tests
4h : Recherche de documents pour la modification de l’iso
3h30 : Test de différents moyens de modification d’iso

4h : Création d’une iso Finnix modifié
3h : Création d’une iso Ubuntu modifié pour le serveur de supervision
3h : Recherche de distributions graphiques légères et modifiables
4h : Téléchargement et installation de distribution à tester
5h : Modification d’images de type Knoppix et autres
4h : Réunion, test de réinstallation de VirtualNet, création d’une image Knoppix (Evinux)
modifié
2h30 : Configuration, prise en main de Nagios3 et MRTG sur une machine réelle
2h : Intégration de MRTG dans une image Evinux
4h : Configuration de Nagios2
6h : Rédaction d’un tutoriel création d’iso pour le rapport
2h30 : Réinstallation du PC de démonstration, réalisation de tests pour résoudre les
problèmes de l’ancien PC de démonstration
2h30 : Modification de l’iso serveur, suppression du mot de passe Nagios, création de l’index,
localhost en page d’accueil du navigateur
1h30 : Création de schéma pour le rapport, création de la page de présentation du rapport.
4h : Rédaction d’un tutoriel Nagios2 pour le rapport
1h30mn : Régénération de l’image Evinux pour les impressions d’écran nagios, génération de
trafique pour but de tester le bon fonctionnement du serveur.
3h : Mise en forme du rapport, création du sommaire, intégration d’image nagios, modification
de texte sur le choix des distrib.
6h : Remise en forme final du rapport, rédaction de la conclusion. Recherche et test des
informations au sujet du réseau de virtualbox (type Adaptateur réseau hôte). création de
schémas et rédaction d’une explication dans le rapport sur le réseau sur virtualbox.
Total : 81h

Virtualisation de Reseau Rapport

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Virtualisation de Reseau Rapport

Transféré par

Droits d'auteur :

Formats disponibles

BUCHER Aurélie

Projet tutoré 2008-2009

Virtualisation de réseau et supervision

Licence Pro ASRALL

Objectif : Mettre en place un réseau virtuel et réaliser sa supervision.

1.1. Intérêt de la virtualisation

La virtualisation correspond à l’ensemble des techniques matérielles et/ou logicielles qui

Chaque outil de virtualisation implémente une ou plusieurs de ces notions :

La virtualisation présente un grand nombre d’intérêts pour les entreprises :

La virtualisation possède également des intérêts pédagogiques :

1.2. Objectifs du projet

Virtualisation de réseau et supervision 2/49

2.1. Fonctionnement global

Sous VirtualBox, la manipulation des machines virtuelles nécessite plusieurs étapes :

Pour exécuter ces actions, il existe plusieurs possibilités :

Création d'une machine virtuelle

A ce moment, le système nous renvoi

Création d'une image disque virtuelle

Création d'une machine virtuelle

Association du disque avec la machine

Association de l'iso du système (de la distribution)

Nous obtenons ainsi une machine virtuelle.

Virtualisation de réseau et supervision 3/49

Tap1 Tap2 eth0 eth0 Tap2 Tap1

Virtualisation de réseau et supervision 4/49

De ce fait, nous avons modifié, dans le fichier parser.h, à la ligne 81

Virtualisation de réseau et supervision 5/49

echo -e "----------------------------------------------------\nAllocation de 128MB de

if [ `echo $3 | grep serveur_knoppix.iso` ]; then

Ceci permet de détecter le nom de l’image. S’il correspond à serveur_knoppix.iso, la

3.2. Pré requis

Nous avons également du générer nos images systèmes :

VirtualNet se base sur un fichier de description du réseau.

Virtualisation de réseau et supervision 6/49

On commence par définir le réseau à utiliser : 10.0.0.0 avec un masque 255.0.0.0

VirtualNet fonctionne avec la commande

Virtualisation de réseau et supervision 7/49

4.1. Choix des distributions utilisées

Pour nos images hôtes et routeur, nous avons choisi une

Pour finir, l’image du serveur de supervision est Evinux,

4.2. Modification des iso de type squashfs

o Création d’un dossier de travail

o Montage et copie de l’iso

Virtualisation de réseau et supervision 8/49

On commence par rajouter notre sources.list et désactiver certains dépôts

chroot:/# apt-get update

Nous pouvons ensuite effacer l’ancien système de fichier compressé.

Virtualisation de réseau et supervision 9/49

o Reconstruction du système de fichiers

o Création de l’iso bootable

Virtualisation de réseau et supervision 10/49

o Création d’un dossier de travail

o Montage et copie de l'iso

Pour l’étape suivante le paquet cloop-utils est nécessaire

Virtualisation de réseau et supervision 11/49

o Extraction du système de fichier compressé vers une iso

Nous devons maintenant monter l’image

o Copie du système de fichier compressé

chroot squashfs /bin/bash

Virtualisation de réseau et supervision 12/49

o Effacer le système compressé

o Génération du live cd modifié

Virtualisation de réseau et supervision 13/49