< Ingénierie de la solution < > Bilan >
|
|
Projet de fin d'année Logiciel
< Ingénierie de la solution < > Bilan > |
A l'origine la compilation était assez laborieuse dès qu'on sortait
de l'environnement des développeurs. Afin de la simplifier, nous avons
utilisé autoconf et automake. Le logiciel se compile
et s'installe maintenant avec le classique
./configure && make && make install.
En effet, il existe différentes sources donnant accès à ces informations, mais elles ne sont pas toutes disponibles sur tous les systèmes. Par exemple, à l'ENSEIRB on peut se servir de la base NIS pour avoir d'une part la liste des machines du réseau et d'autre part leurs adresses physiques (MAC). A l'origine, la récupération était codée en dur dans le logiciel qui n'était pas utilisable sans modification sur un réseau où les tables NIS correspondantes ne sont pas présentes.
Pour permettre une utilisation de notre logiciel sur le plus grand
nombre de réseau, nous avons choisi de fournir ces listes indispensables
au fonctionnement du logiciel dans des fichiers dont les chemins sont
passés sur la ligne de commande.
Nous avons écrit des scripts sh/perl pour
créer ces listes dans le cas de la base NIS de l'ENSEIRB.
Nous avons aussi écrit des scripts semblables utilisables sur n'importe quel
réseau faisant tourner arpwatch3.1Les deux jeux de scripts sont utilisables à l'ENSEIRB
puisqu'arpwatch y tourne également.
Nous avons choisi d'écrire des scripts sh/perl car ils sont
bien adaptés pour ce travail. De plus, un utilisateur quelconque peut
les modifier facilement pour les adapter à son réseau sans avoir à
plonger dans le code de notre application.
La quasi totalité du logiciel a été reprise afin de l'organiser en modules logiques. Cette refonte a été effectuée de manière incrémentielle afin de pouvoir faire des tests de non regression à chaque étape. Nous nous étions posé la question de l'éventuel intérêt de refaire complètement certaines parties à partir de zéro après l'analyse du code. Nous n'avions pas choisi cette possibilité en particulier parce qu'on risquait de ne pas pouvoir finir une application avec au moins autant de fonctionnalités que celle d'origine; compte-tenu des gros dépassements sur nos prévisions de départ en particulier pour ce qui concerne la prise en charge des réseaux virtuels, ce choix s'est avéré judicieux.
Nous avons aussi documenté précisément la partie sur la récupération des informations concernant la configuration des réseaux virtuels; en effet la localisation de ces informations nous a pris beaucoup de temps et mérite un récapitulatif.
Les informations récupérables par SNMP sont organisées de façon
arborescente. Chaque noeud de l'arborescence contient une valeur (qui
peut être de différents types). Les RFCs définissent la signification
des différents n
uds. Cependant, les informations relatives aux
VLANs ne sont pas toujours implémentées de la manière décrite dans la
RFC correspondante [13].
En conséquence, il y a eu un travail de recherche de la localisation des informations assez important car il fallait le faire pour chaque type d'équipement. Une fois que l'on savait où trouver les différents éléments de la configuration des réseaux virtuels pour chaque équipement, nous avons implémenté leur récupération de la manière suivante: on commence par récupérer le type d'équipement (une chaîne décrivant l'équipement est récupérable par SNMP, elle comporte en général le constructeur et la référence de la machine), ensuite suivant le type de l'équipement, on récupère l'information à la bonne ``adresse''.
Comme il s'agit d'un élément du logiciel qui a de grande chance de poser des problèmes lors de l'utilisation d'équipements différents de ceux utilisés à l'ENSEIRB actuellement, nous avons veillé à bien documenter ceci pour que des tiers puissent facilement adapter le logiciel à d'autres marques ou modèles de commutateurs.
Un autre point intéressant pédagogiquement parlant a été une mauvaise analyse de notre part des informations à notre disposition. Sur certains équipements, les forwarding lists sont récupérées ventilées par réseau virtuel. Sur d'autres elles sont récupérés globalement mais on peut aussi récupérer la configuration du matériel (c'est-à-dire à quel VLAN appartient chaque port, et sur quel VLAN il taggue les paquets non taggués provenant d'un port donné). Nous pensions que cette information était suffisante pour ventiler les différentes adresses des forwarding lists mais en réalité cela oblige à mettre en place une heuristique assez délicate: il faut savoir où les paquets sont taggués, autrement dit descendre dans la topologie mais celle-ci n'est pas encore construite puisque c'est précisément pendant sa construction que l'information est nécessaire.
On notera par ailleurs que le client n'avait pas non plus réalisé qu'il y avait un problème à ce niveau là. En fait nous pensons que nous nous sommes laissés abuser par le fait que la méthode permettant de récupérer les forwarding lists ventilés par VLAN n'était pas standard (c'est une méthode spécifique au constructeur 3Com). Aussi, pour nous, c'est inconsciemment la méthode normalisée (celle conforme aux RFCs) qui était la plus judicieuse...
Nous nous sommes inspirés de l'implémentation des méthodes d'affichage de Nagios [20] d'arbres réseau sur plusieurs niveaux, dans le but de rester le plus compatible possible avec les versions futures de ce logiciel afin de profiter des corrections de bugs/améliorations dans leurs algorithmes de placement des machines.
Outre le rajout de menus pour appeler les fonctionnalités, nous avons réglé quelques problèmes d'affichage comme des scintillements dus à une méthode de rafraichissement peu judicieuse (lecture d'un fichier configurant une couleur pour chaque lien). De plus, un réaffichage était réalisé à chaque ajout sur la représentation graphique du réseau, ce qui ralentit l'affichage.
D'autre part, un certain nombre de bugs mineurs comme des fuites mémoires ont été corrigés.
Il existait plusieurs fichiers de configuration pour lesquels le groupe
de l'année dernière avait écrit un parser à la main. Celui-ci marchait
moyennement; nous avons donc écrit un parser de fichier de configuration
avec yacc et lex afin de faciliter le paramétrage de
l'application et surtout l'ajout de nouvelles directives de configuration.
Il fonctionne maintenant sur les plateformes suivantes:
|
|
Projet de fin d'année Logiciel
< Ingénierie de la solution < > Bilan > |