Université de la Réunion

Département de Mathématiques etInformatique

Master 2 Informatique

Rapport de Stage De Fin d'Etudes

Mise en place d'un outil desupervision et contrôle distant

Réalisé au Conseil Général de la Réunion

Du 06 Janvier 2014 au 7 Juillet 2014

Auteur :

Kévin TAOCHY

N◦ Etudiant : 28000637

Tuteur :

François BOYER

Responsable pédagogique :

Fred MESNARD

20 juin 2014

1

Remerciements

Je tiens à remercier en premier lieu François BOYER pour son encadrementsans faille ainsi que pour les nombreuses discussions que nous avons pu avoir.

Mes remerciement s'adressent également à Laurent PRUNELLA, qui m'a permisd'e�ectuer ce stage au Service Support Utilisateur et pour ses précieux conseils.

Je remercie mon meilleur ami Patrick IRSAPOULLE pour sa collaboration dansce projet mené de façon professionnelle.

Je remercie également Monsieur Fred MESNARD pour sa disponibilité et sonimplication durant ces années universitaires.

Mes remerciements s'adressent à l'ensemble du Service Support Utilisateur pourleur gentillesse, leur accueil au sein de la Direction de l'e-Administration et laModernisation des Services et surtout leur bonne humeur quotidienne, notammentcelle de Jean-Pierre JOB.

Ils s'adressent également au Service Ressources et Méthodes, notamment Marie-Paule CRESCENCE, Chris RAMASSAMY et Valérie FONTAINE pour leur ac-cueil et leur gentillesse, et au Service Applications pour leurs conseils tout au longde ce stage et j'ai été ravi des discussions sur les dernières technologies que j'ai puaborder avec eux.

Je tiens également à remercier l'équipe du Service Architecture et Réseaux etnotamment Pierre-Louis CORION pour son aide précieuse et ses astuces dans ledéveloppement de l'application.

2

Résumé

Le Conseil Général de la Réunion a connu durant ces dernières années un dé-ploiement massif de matériel informatique. La Direction de l'e-Administration etla Modernisation des Services, de part ces techniciens, s'occupe de la maintenancematérielle et applicative répondant aux demandes d'interventions des agents. Lestechniciens décident de la nécessité d'agir sur site ou résoudre le problème à dis-tance. Toutefois, certains de ces déplacements sont jugés super�us.

Dès lors, durant ce stage, il m'a été demandé de mettre en place un outil per-mettant le diagnostic de 1er niveau d'un matériel (poste de travail et imprimante)à la demande du technicien. Des informations pertinentes doivent guider au mieuxle technicien dans son processus d'analyse du problème. Une application Web dé-veloppée en Ruby On Rails couplée à un outil de supervision a été conçue dansl'optique de répondre à ce besoin et augmenter les interventions à distance.

Mots-clés : maintenance, diagnostic, supervision, application Web.

Abstract

Over the last few years, "Le Conseil Général de la Réunion" has invested en-ormesly in hardware. "La Direction de l'e-Administration et la Modernisation desServices", thanks to their technicians, are in charge of the hardware and softwaremaintenance to satisfy the requests of the employees. The technicians decide whe-ther to solve the problem onsite or directly from their o�ce. However, certainonsite interventions could have been carried out at a distance.

Thus, during my work experience, I was asked to develop a tool for use in theinitial diagnosis of hardware (computer or printer), launched by the technician.The useful information guides the technician in his analysis of the problem. AWeb application using the Ruby On Rails framework alongside with a monitoringtool was created for this purpose and increase remote interventions.

Keywords : maintenance, diagnosis, monitoring, Web application.

3

Table des matières

1 Introduction 71.1 Présentation du Conseil Général de la Réunion . . . . . . . . . . . . 7

1.1.1 Organisation et fonctionnement . . . . . . . . . . . . . . . . 81.1.2 La Direction de l'e-Administration et la Modernisation des

Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Missions de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4 Présentation du rapport . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Étude du besoin et spéci�cations 132.1 Enjeux du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Étude de l'existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Architecture du SI . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Les outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 Les normes instaurées par la DEMS . . . . . . . . . . . . . . 18

2.3 Les informations pertinentes pour le technicien . . . . . . . . . . . . 192.3.1 Les postes de travail . . . . . . . . . . . . . . . . . . . . . . 192.3.2 Les imprimantes . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Constitution de l'équipe projet . . . . . . . . . . . . . . . . . . . . . 212.5 Gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.1 Les ressources nécessaires . . . . . . . . . . . . . . . . . . . 222.5.2 Le planning prévisionnel établi . . . . . . . . . . . . . . . . . 232.5.3 Validations mensuelles . . . . . . . . . . . . . . . . . . . . . 232.5.4 Cycle de développement . . . . . . . . . . . . . . . . . . . . 24

3 État de l'art 263.1 Des outils et langages de développement . . . . . . . . . . . . . . . 26

3.1.1 Le langage PHP . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.2 ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.3 Ruby On Rails . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Avantages et inconvénients . . . . . . . . . . . . . . . . . . . . . . . 29

4

3.3 Solution retenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Ruby On Rails, du déploiement à l'authenti�cation 314.1 Passenger Phusion, module pour Apache . . . . . . . . . . . . . . . 31

4.1.1 Un outil open-source . . . . . . . . . . . . . . . . . . . . . . 314.1.2 Les raisons de ce choix . . . . . . . . . . . . . . . . . . . . . 32

4.2 SSO : Kerberos, le gardien . . . . . . . . . . . . . . . . . . . . . . . 324.2.1 Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.3 Un point négatif . . . . . . . . . . . . . . . . . . . . . . . . 334.2.4 Kerberos, la solution . . . . . . . . . . . . . . . . . . . . . . 33

5 Réalisation 355.1 Le diagnostic à l'instant t . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.1 Superviser les imprimantes . . . . . . . . . . . . . . . . . . . 365.1.2 Requêter simplement les postes de travail . . . . . . . . . . . 385.1.3 Analyse du matériel à la demande . . . . . . . . . . . . . . . 40

5.2 A la recherche des imprimantes . . . . . . . . . . . . . . . . . . . . 405.2.1 La di�érenciation des sites du Conseil Général . . . . . . . . 405.2.2 Discovery par SNMP . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Les di�cultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . 425.3.1 La barrière Linux - Windows . . . . . . . . . . . . . . . . . . 425.3.2 Ports fermés et droits d'accès . . . . . . . . . . . . . . . . . 435.3.3 Des problèmes de normalisation . . . . . . . . . . . . . . . . 44

5.4 Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.4.1 Architecture de l'outil . . . . . . . . . . . . . . . . . . . . . 445.4.2 Documents écrits . . . . . . . . . . . . . . . . . . . . . . . . 465.4.3 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Conclusions et Perspectives 47

7 Références bibliographiques et webographiques 497.1 Références bibliographiques . . . . . . . . . . . . . . . . . . . . . . 497.2 Références webographiques . . . . . . . . . . . . . . . . . . . . . . . 49

A Annexe technique 50A.1 Les outils utilisés pour le développement . . . . . . . . . . . . . . . 50A.2 Installation et con�guration Passenger Phusion et Rails sur Debian 51A.3 Créer des boites de sélection dynamiques avec Rails . . . . . . . . . 52A.4 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . 53A.5 Interface de l'application : version Beta . . . . . . . . . . . . . . . . 55

5

Table des �gures

1.1 Organigramme du Conseil Général de la Réunion . . . . . . . . . . 81.2 Organigramme du Conseil Général de la Réunion . . . . . . . . . . 9

2.1 Architecture générale du Conseil Général . . . . . . . . . . . . . . . 152.2 Coeur du LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3 Schéma simpli�é du fonctionnement d'un Proxy - Kévin TAOCHY . 202.4 Graphe systémique - Kévin TAOCHY . . . . . . . . . . . . . . . . . 222.5 Déroulement des réunions mensuelles - TAOCHY Kévin . . . . . . . 232.6 Cycle de développement - TAOCHY Kévin . . . . . . . . . . . . . . 242.7 Diagramme de cas d'utilisation - TAOCHY Kévin . . . . . . . . . . 25

3.1 Fonctionnement de PHP . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Fonctionnement de Rails - MVC . . . . . . . . . . . . . . . . . . . . 29

4.1 Architecture et fonctionnement de Kerberos . . . . . . . . . . . . . 34

5.1 Utilisation de l'architecture MVC - Kévin TAOCHY . . . . . . . . . 355.2 Exemple de MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 SNMP - Communication de base . . . . . . . . . . . . . . . . . . . 385.4 Processus d'implémentation SNMP sur les postes Windows - Kévin

TAOCHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.5 Diagramme de classes associant les zones géographiques aux sites . 415.6 Architecture de l'application Diagmoustik - Kévin TAOCHY . . . . 455.7 Principe de fonctionnement de l'outil - Kévin TAOCHY . . . . . . . 45

A.1 Diagramme de Gantt - Kévin TAOCHY . . . . . . . . . . . . . . . 54A.2 Page de lancement du diagnostic - Kévin TAOCHY . . . . . . . . . 55A.3 Résultat du diagnostic pour un poste de travail - Kévin TAOCHY . 55A.4 Résultat du diagnostic pour une imprimante - Kévin TAOCHY . . 56A.5 Page de lancement d'un discovery - Kévin TAOCHY . . . . . . . . 56A.6 Page de lancement du diagnostic - Kévin TAOCHY . . . . . . . . . 57

6

Chapitre 1

Introduction

Dans le cadre du Master 2 Informatique à l'Université de la Réunion, les étu-diants ont l'obligation de réaliser un stage de �n d'études a�n de valider leurdiplôme universitaire et d'acquérir une expérience professionnelle. Ce stage d'unedurée de 6 mois, allant du 6 Janvier 2014 au 7 Juillet 2014, s'est déroulé au seinde la Direction de l'e-Administration et la Modernisation des Services (DEMS),entité du Conseil Général de la Réunion, sous la tutelle de François BOYER, chefde projet bureautique et avec la collaboration de Patrick IRSAPOULLE, étudiantdu Master 2 Informatique également.

Ce chapitre réunit les conditions générales de ce stage. Une présentation del'organisme d'accueil et de ses objectifs sera faite, suivi de la problématique àlaquelle j'ai dû répondre et apporter la meilleure solution, et les missions poséesau lancement de ce stage.

1.1 Présentation du Conseil Général de la Réunion

Le Conseil Général de la Réunion est une collectivité territoriale de l'île de laRéunion, dont la Présidente représente l'exécutif. Une collectivité est une divisionadministrative située � au dessous � du niveau de l'Etat, gérée par une assembléedélibérante élue (dite assemblée départementale) distincte de l'Etat et qui exercedes compétences lui étant dévolues sur un département. Le Conseil Général règlepar ses délibérations les a�aires du Département. La collectivité possède plus de150 sites inter connectés, avec des débits variés, grâce à leur Intranet.

7

1.1.1 Organisation et fonctionnement

Le Conseil Général de la Réunion s'organise de la façon suivante :

� Un cabinet, sous l'autorité de la Présidente, qui exerce ses missions dans lesouci de promouvoir le Département, l'action de la Présidence, de l'assembléedépartementale et celle de son administration

� Un ensemble de services et fonctions, dirigé par un Directeur Général desServices.

Figure 1.1 � Organigramme du Conseil Général de la Réunion

Il existe les fonctions opérationnelles qui se chargent des familles, de l'insertionprofessionnelle des Réunionnais ainsi que l'avenir de l'île, et les fonctions straté-giques au service des politiques publiques. Dans le pôle Management et Europe,on retrouve la Direction de l'e-Administration et la Modernisation des Services (exDirection Informatique), entité dans laquelle j'ai e�ectué mon stage de �n d'études.

8

1.1.2 La Direction de l'e-Administration et la Modernisa-

tion des Services

La DEMS 1 assure la maintenance évolutive, préventive et corrective du Sys-tème d'Informations et Télécommunications des services du Conseil Général. Leurprincipale mission est de développer l'administration électronique et l'ouverturedu SI aux usagers et partenaires. La direction s'occupe également de la formationet de l'assistance des di�érents agents de la collectivité.

Figure 1.2 � Organigramme du Conseil Général de la Réunion

Il y a 4 services au sein de la DEMS :

� Le Service Ressources et Méthodes a pour but de faciliter les travaux desservices opérationnels en mettant à leur disposition les moyens requis à la

1. Direction de l'e-Administration et la Modernisation des Services

9

conduite de leurs missions et en assurant la gestion des ressources transver-sales.

� Le Service Architecture Réseaux a pour vocation de construire l'infrastruc-ture du Système d'Information, le surveiller, le maintenir et le moderniser.

� Le service Applications a pour vocation d'assurer la mise en place de solutionsou d'outils informatiques modernes et d'assurer leur fonctionnement et leurévolution.

� Le Service Support Utilisateur a pour but d'être toujours à la demande desagents en terme de ressource matérielle ou souci technique.

C'est dans ce dernier que j'ai été a�ecté pour la conduite de ce projet, encompagnie de Patrick IRSAPOULLE. Le Service Support Utilisateur s'assure dela distribution d'équipements informatiques et téléphoniques aux di�érents agentsdu Conseil Général, de la maintenance de ces équipements et de la bonne utilisationdes di�érents outils de base utilisés sur ces machines. Des marchés sont entreprispour acheter le matériel nécessaire et le stocker a�n de ne jamais manquer à lademande de ressource informatique d'un agent. Le SSU dispose de trois cellules detravail : la cellule téléphone, la cellule maintenance et la cellule équipements.

Les écrans, les unités centrales, les imprimantes, les scanners et les copieurs sont lesappareils utilisés quotidiennement par l'employé. Pour parler de la maintenance,les techniciens ont la possibilité de régler le problème sur site ou à distance sipossible.

1.2 Problématique

Le Service Support Utilisateur est une entité très active au quotidien, notam-ment par les demandes d'intervention des agents du Conseil Général. Les techni-ciens de maintenance recueillent ces requêtes, les analysent grâce à la descriptionde celles-ci faite par l'agent, puis décident de régler ces problèmes sur site ou àdistance. Le numéro du matériel défaillant est également renseigné. Malheureuse-ment, il arrive que les techniciens se déplacent en voiture pour de simples problèmescomme le câble réseau non branché ou une cartouche d'encre vide, et donc du car-burant qui aurait pu être économisé. De plus, les descriptions faites par l'agentlaissent un champ de possibilité concernant le problème assez large, ce qui obligele technicien, potentiellement, à passer plus de temps sur le souci et trouver l'erreur.

La problématique générale de mon stage était la suivante :Comment minimiser les déplacements super�us des techniciens et rendrel'intervention à distance plus e�ciente ?

10

Ce travail étant réalisé avec Patrick IRSAPOULLE, le problème qui découlede cette problématique générale et sur lequel je me suis penché était :

Comment permettre au technicien de voir depuis son poste des informationsimportantes liées à l'état d'un matériel ?

1.3 Missions de stage

Avant d'énoncer les missions liées à ce projet, d'autres demandes nous ont été faitesdans le cadre de ce stage :

� Un projet d'aide à la prise en main de l'outil informatique a du être monté a�nd'enseigner aux travailleurs sociaux du Conseil Général les bonnes pratiqueset la bonne utilisation d'un poste de travail Windows et ses outils. Ayant reçudes postes de travail dernièrement, à la demande de Madame La Présidente,ces personnes avaient, pour la plupart, peu de connaissances en informatique.Les thèmes choisis pour cette formation étaient : Windows 7, Microsoft O�ce2007, la navigation sur le Web et l'utilisation de la messagerie interne. Outrel'aspect pédagogique, nous devions, avec mon collègue, mettre en place cesdi�érentes journées d'apprentissage et les organiser (logistique).

� A�n de mieux comprendre le fonctionnement de SSU 2, des clonages de ma-chines (installation de Windows via un service de déploiement), des inter-ventions sur sites et des recensements de postes ont été e�ectués. De plus,Patrick et moi-même devions accueillir des stagiaires venant de centres deformation et leur présenter le fonctionnement de SSU et les mécanismes tech-niques utilisés.

� Lié à ce travail de recensement, Patrick IRSAPOULLE et moi devions trou-ver une application sur smartphone permettant de scanner les codes barresdes étiquettes du Conseil Général, correspondant au numéro de chaque ma-tériel, et de les associer à leurs propriétaires, ainsi qu'au site sur lesquels ilsont été placés.

Ce projet s'inscrit entièrement dans les objectifs généraux de la DEMS, à savoiraugmenter encore plus l'e�cacité et la vitesse d'intervention des techniciens infor-matiques. Ce projet est décomposé en 3 missions :

2. Service Support Utilisateur

11

� Choisir et récupérer des informations pertinentes concernant un matériel a�nd'évaluer au mieux la nature du problème rencontré.

� Réaliser une interface Web a�chant au technicien ces informations, unique-ment à sa demande, et ne pas surcharger le réseau par des requêtes constantesde l'application vers les postes de travail, au vu de leur nombre.

� Sécuriser l'application et autoriser son utilisation qu'aux agents de la DEMS.

1.4 Présentation du rapport

Dans une première partie, je ferai une description du système d'informations duConseil Général, des outils utilisés et des normes instaurées par la DEMS pourparler plus précisément du besoin de SSU. Puis, nous verrons dans une secondepartie, les di�érentes possibilités a�n de développer une interface Web, leurs avan-tages et inconvénients et la solution que j'ai retenu. La troisième partie montrerales pratiques e�ectuées autour de la solution retenue en terme de déploiement etd'authenti�cation. Ensuite, j'exposerai les réalisations e�ectuées en mettant enavant les explications concrètes sur les choix réalisés, les problèmes rencontrés etl'avancement �nal du projet. En�n, je donnerai une conclusion et des perspectivespossibles sur ce projet, et un bilan sur mon apport personnel.

12

Chapitre 2

Étude du besoin et spéci�cations

L'analyse des besoins est la phase initiale de toute mise en ÷uvre de projet.Elle conditionne une grande part de réussite et la performance de l'outil à venir.

Ce chapitre traite d'une analyse de l'infrastructure actuelle du Système d'In-formations du Conseil Général, des outils utilisés en sein de la DEMS en terme degestion, et des normes et contraintes instaurées par la DEMS et en�n, d'une étudesur le besoin précis du technicien avant toute intervention.

2.1 Enjeux du projet

Ce projet a une valeur importante pour le SSU. Les objectifs du service pourcette année 2014 est de satisfaire encore plus les agents du Conseil Général. Lestechniciens sont les personnes les plus proches des ces agents, c'est pour cela qu'ilest primordial de leur apporter une aide supplémentaire a�n d'améliorer leursconditions de travail, par le biais d'un outil de supervision et de contrôle distant.Deux paramètres importants sont à prendre en compte :

� La vitesse d'intervention : Le technicien doit avoir un maximum d'infor-mations avant son analyse du problème et sa résolution. Malheureusement, ildoit souvent se contenter de la description faite par l'agent et du retour éta-bli par la Hotline, service prestataire de la DEMS, qui s'avère quelques foisinsu�sant et donc ralentissant. Un moyen doit être trouvé a�n de donner autechnicien les meilleures conditions et accélérer son processus d'intervention.

� Le type d'intervention : Il est possible d'améliorer l'intervention du tech-nicien en lui donnant des informations précises concernant le matériel. L'étatd'un équipement ainsi que leurs con�gurations sont des informations quipeuvent aider le technicien à cibler encore mieux le problème et donc dé-

13

terminer l'utilité d'une intervention sur le terrain ou tout simplement d'unerésolution à distance.

Les techniciens se déplacent souvent pour des problèmes mineurs, voir quasi-inexistants. Nous pouvons citer quelques exemples de situation à éviter :

� Câble réseau non branché� Absence de con�guration proxy dans les navigateurs� Absence de papier dans le bac à papiers� Cartouche d'encre à remplacer.

2.2 Étude de l'existant

Cette section traite de l'architecture en place au Conseil Général (serveurs,sécurité), et des outils utilisés assurant l'intégrité de ce réseau.

2.2.1 Architecture du SI

Le Conseil Général, c'est plus de 150 sites interconnectés. Sur ces sites, on re-trouve près de 3500 postes de travail et pas moins de 500 imprimantes ou copieurs.Nous avons a�aire à un parc informatique très conséquent. Il est important detenir compte de la structure du système d'informations du Conseil Général a�n depouvoir y adapter notre outil et respecter les politiques de sécurité.

L'architecture du Conseil Général est de type réseau maillé hébergé par un opéra-teur historique. Des débits variés sont proposés aux di�érents sites (en fonction dubesoin des services). Le coeur du SI 1 est un DataCenter sous VMWare. Les prin-cipaux OS 2 sont Microsoft Windows Server, Debian et Ubuntu pour les serveurs.Les postes de travail des agents disposent de Microsoft Windows XP à 7.

Le réseau du Conseil Général est composé de :

� Connexion très haut débit. Deux connexions 10 Mbits en �bre optiquesont utilisées pour avoir accès aux applications métiers et applications Webhébergés par le Conseil Général. Une connexion de 50 Mbits est réservéuniquement aux connexions avec Internet.

1. Système d'informations2. Operating System : Système d'exploitation

14

Figure 2.1 � Architecture générale du Conseil Général

� Connexion haut débit. Les di�érents sites du Conseil Général sont rat-tachés par des liaisons BVPN 3 de 2 Mbits à 10 Gbits en fonction de leurdemande.

� Firewall. Deux �rewalls sont disposés a�n d'assurer la sécurité du réseau :un �rewall interne protégant les serveurs du réseau et un �rewall externebloquant les attaques provenant de l'extérieur.

� DMZ. Une zone démilitarisée ou DMZ 4 est un réseau lié au réseau local etInternet grâce au �rewall. Les personnes malveillantes n'auront accès qu'auxmachines placées dans la DMZ. On y retrouve également les serveurs héber-geant des applications accessibles depuis l'extérieur.

� Sous-réseaux. Un sous-réseau correspond à un site et communique avecles autres grâce aux switchs. Ces sous-réseaux sont des VLAN 5 qui sont enrelation avec les serveurs grâce à un switch VLAN. En réseau, un site est

3. Broadband Virtual Private Network4. Demilitarized Zone5. Virtual LAN

15

identi�é grâce au deuxième octet de l'adresse IP. Exemple : 10.1.*.* corres-pond au site de la DEMS.

Figure 2.2 � Coeur du LAN

2.2.2 Les outils utilisés

Pour surveiller ces di�érents serveurs, a�n de toujours prévenir un souci majeurdu système et d'y remédier très rapidement, des outils ont été mis en place. Cesserveurs sont le coeur du SI, les agents du Conseil Général ne doivent à aucunmoment être dépourvus de connexion Internet et Intranet. C'est une rigueur quela DEMS s'impose.

16

Les outils utilisés au sein de la DEMS qui supervise les serveurs sont :

� Boumbo. Il s'agit d'un outil développé en interne qui permet de remonterdes informations telles que l'état des di�érentes machines, switchs et routeurscôté serveur ou proposer des connexions à distance sur ces entités.

� Nagios. C'est une moteur permettant la surveillance système et réseau. Sonsystème d'alerte permet à l'administrateur d'être informé très rapidementd'un dysfonctionnement.

� Centreon. Cette application permet la supervision du système informatique,basée sur le moteur de récupération d'information libre Nagios. Centreonsimpli�e l'interface compliquée de Nagios et est destiné aux techniciens ounon-techniciens.

� Active Directory.Microsoft a mis en oeuvre des services d'annuaire LDAP 6.AD fournit des services d'identi�cation et authenti�cations à un groupe d'or-dinateurs sous le système d'exploitation Windows mais également l'applica-tion de stratégies ou l'installation de mises à jour critiques. Ces informationssont stockées dans une base de données centralisée.

� Serveur d'authenti�cations Kerberos. Kerberos est un outil permettantl'accès à une/des applications grâce à un système de tickets. On parle alorsd'authenti�cation unique et sans utilisation de mot de passe.

Un autre outil, instauré à la DEMS depuis 2012, est utilisé quotidiennementpar le clan informatique : EasyVista. Cette solution d'IT Service Management 7

apporte une amélioration nette de la performance et la qualité des services in-formatiques de la DEMS. EasyVista permet la gestion du parc informatique, lacontinuité des services, et la gestion des indicents. C'est cette dernière fonctionna-lité qui nous intéresse.

6. Lightweight Directory Access Protocol : Norme pour système d'annuaire7. Information Technology Service Management : Gestion des services informatiques

17

Un prestataire Hotline du Conseil Général va recueillir les rêquetes des agents.Puis, après avoir posé quelques questions au demandeur, la Hotline crée, au be-soin, une demande d'intervention sur l'outil EasyVista. C'est à ce moment que letechnicien de maintenance entre en scène.

2.2.3 Les normes instaurées par la DEMS

Au Conseil Général, chaque matériel informatique possède un identi�ant uniqueappelé code matériel : PC***** pour les postes de travail, PT***** pour les ordi-nateurs portables et PR*****. Il est important de di�érencier chaque équipementinformatique a�n d'avoir une base cohérente (gestion du parc). Un travail de re-censement est e�ectué par la cellule équipements a�n de mettre à jour la base demanière régulière.

Exemple : PC123456 ou PR98765.

Les adresses IP. Les équipements informatiques en réseau ont également uneadresse IP attribuée par le DHCP 8 et qui respecte une normalisation a�n de pou-voir di�érencier chaque type de matériel au niveau réseau :

� Les postes de travail et ordinateurs portables : 10.*.7.* ou 10.*.8.*� Les imprimantes : 10.*.2.*

Ces informations nous permettront de bien cibler le matériel qui entre dans l'inté-rêt de notre outil.

Cette étude nous a permis de comprendre que l'outil que nous développerons devraêtre une application Web, a�n de pouvoir communiquer très simplement avec lesdi�érents matériels connectés au réseau Intranet et requêter les di�érentes entitéscontenant des informations sur l'état des machines. C'est seulement après ce travailque nous pouvons choisir notre outil de développement.

8. Dynamic Host Con�guration Protocol

18

2.3 Les informations pertinentes pour le technicien

Ma ré�exion s'est porté sur le besoin concret de ce projet : le type d'infor-mations pouvant servir au technicien. Ces informations doivent re�éter l'état dumatériel à la demande du technicien, ce qui nous a permis de comprendre qu'ils'agit d'un outil permettant le diagnostic du matériel à l'instant t qu'il faudradévelopper et un outil de supervision, c'est à dire avoir un ÷il constant sur l'étatde tous les matériels, avec un système d'alerte.

2.3.1 Les postes de travail

A�n de pouvoir communiquer avec le poste distant, il est impératif que celui-cisoit connecté au réseau Intranet. La première information que l'on peut avoir c'estla présence du poste sur le réseau :

� Oui : un simple ping nous permet de véri�er la réponse du poste.� Non : le ping est négatif. Soit le poste n'est pas connecté au réseau, soit lacarte Ethernet (ou Wi�) du poste est hors-service.

Stratégie de groupe Windows Si le poste est bien connecté au réseau, unesérie de tests peuvent être e�ectués. Des outils Windows nous permettent d'ad-ministrer les postes distants. On peut parler tout d'abord de la mise à jour de lastratégie de groupe du poste. Ces stratégies permettent la gestion des postes etde ses utilisateurs dans un environnement Active Directory. A chaque utilisateurest appliqué des restrictions d'utilisation comme le verrouillage du panneau decon�guration, l'accès à des dossiers ou l'interdiction d'installer des programmes. Ilserait donc judicieux de véri�er ces informations, depuis le poste du technicien.

Paramètres proxy Le proxy "proxysquid" est utilisé à la DEMS a�n de sécu-riser le système d'informations. Un proxy sert d'intermédiaire entre deux réseaux(ici Intranet et Internet). L'ordinateur dans le réseau Intranet e�ectue la demandeau proxy et c'est lui qui envoie ensuite l'information vers l'extérieur. Cependant,l'opréation inverse n'est pas possible a�n d'assurer la con�dentialité des informa-tions contenues dans le réseau Intranet.

A�n d'accéder à la toile, les agents utilisent les navigateurs Web qui doivent êtrecon�gurés au préalable par le technicien, en y inscrivant l'adresse du serveur proxyet le port. Cette étape a pu être oublié, il est donc utile d'avoir ces informations.

19

Figure 2.3 � Schéma simpli�é du fonctionnement d'un Proxy - Kévin TAOCHY

DNS Un serveur de système de nom de domaine (DNS 9) associe un nom demachine à son adresse IP. Lorsque notre poste essaie de communiquer avec unemachine sur le réseau, il va d'abord récupérer l'adresse IP de l'hôte distant surle serveur DNS grâce à une résolution de nom. C'est un outil intégré à WindowsServer.

DHCP Le serveur DHCP 10 a pour but de distribuer les adresses IP à des clientssur le réseau pendant une durée déterminée. Seuls les postes de travail sont a�ectéspar ce bail DHCP, une fois dépassé, une nouvelle adresse IP est attibuée. Lesautres éléments du réseau ont, quand à eux, une adresse IP �xe. DHCP fait partieintégrante de Windows Server.

2.3.2 Les imprimantes

L'imprimante est un des périphériques les plus utilisés au Conseil Général, cequi oblige les techniciens à veiller à son bon fonctionnement. Connectés au réseau,ces imprimantes se caractérisent par leurs composants et leur état. Ces informa-tions nous permettraient de véri�er le bon fonctionnement ou les réparations àe�ectuer, si besoin :

� Le ping. Ce test déterminera si l'imprimante est connectée au réseau ounon.

9. Domain Server Name10. Dynamic Host Con�guration Protocol

20

� Le niveau d'encre. Le technicien anticipera de manière précise la cartouched'encre à remplacer.

� Le bac à papier. Le technicien pourra déterminer si l'imprimante ne disposeplus de papier pour les impressions, et éviter un déplacement.

� Le nom et le modèle. Cette information permettrait au technicien deconsulter avant intervention les documents techniques liés au modèle d'im-primante.

� Localisation physique. Si le technicien doit se déplacer, cette informationlui permettrait de gagner du temps une fois arrivé sur le site.

� Statut de l'imprimante. Il pourra déterminer si l'imprimante est en coursd'impression ou autre.

Top Access Il est possible d'accéder à la fenêtre de con�guration de l'imprimanteen indiquant l'adresse IP dans la barre d'adresses d'un navigateur Web. Depuiscette page, des modi�cations peuvent être apportés à distance.

Le besoin étant explicité, nous pouvons à présent étudier le système d'informa-tions a�n de cadrer au mieux ce projet.

2.4 Constitution de l'équipe projet

L'équipe se compose de trois personnes : Patrick IRSAPOULLE, le tuteurFrançois BOYER et moi-même. A�n de partager au mieux la tâche qu'il nous aété con�é et de pro�ter pleinement de la productivité de chacun, la répartition dutravail s'est faite ainsi : la partie Back End 11 pour mon collègue et la partie FrontEnd 12 pour moi. En e�et, l'administration réseau et les serveurs sont les aspectsles plus appréciés par Patrick IRSAPOULLE, et le développement logiciel et Webest ma spécialité. François BOYER quand à lui véri�era que nous restons toujoursdans le cadre du projet, en donnant quelques directives.Le graphe systémique montre les di�érentes personnes que j'ai sollicité et le niveaud'interaction que j'ai eu avec elles, les �èches les plus �nes montrant une faibleinteraction et les �èches les plus larges une forte interaction. J'ai également misen rouge le nom des acteurs principaux de ce projet.

11. Travail d'arrière-plan.12. Correspond à l'interface Homme Machine et le recueil / a�chage des informations

21

Figure 2.4 � Graphe systémique - Kévin TAOCHY

2.5 Gestion du projet

Tout projet doit être bien organisé a�n d'en assurer son bon déroulement.Les chefs de projet doivent dé�nir les di�érentes ressources humaines, matérielles,informationnelles et �nancières.

2.5.1 Les ressources nécessaires

Évaluer les ressources nécessaires avant la réalisation concrète du projet permetde visualiser l'ampleur et les services nécessaires pour son déroulement. On parlede ressources humaines, logicielles et �nancières.

Ressources humaines. La maitrise d'oeuvre est restreinte à Patrick IRSA-POULLE et moi-même. Cependant, des interactions ont dû se faire a�n de mieuxappréhender l'architecture en place et les conditions de sécurité à respecter.

Ressources logicielles. Un outil de développement ainsi qu'un outil de com-munication via SNMP doivent être étudiés et utilisés a�n de réaliser l'outil destinéà ces techniciens.

22

Ressources �nancières. La maîtrise d'ouvrage, c'est à dire la DEMS et plusparticulièrement SSU, a insisté sur le réalisation d'un outil sans frais. Des solutionsopen-sources doivent donc être trouvées.

2.5.2 Le planning prévisionnel établi

Il faut impérativement être organisé lors du lancement d'un projet et savoirconstamment vers où nous allons. Après concertation avec Patrick IRSAPOULLE,j'ai décidé de diviser mon travail en 4 grandes étapes qui a réellement commencéà la �n du mois de février :

� Etape 1 : Analyser les besoins et étudier le fonctionnement de la DEMSainsi que leur architecture, puis du SSU et organiser le projet. 1 mois.

� Etape 2 : Ré�échir à la meilleure solution au niveau développement etsystème. 3 semaines.

� Etape 3 : Réaliser, sécuriser l'outil. Valider à chaque réunion mensuelle. 1mois et demi

� Etape 4 : Mettre en production l'outil, apporter des modi�cations si néces-saires et établir des documents techniques pour la maintenance. 2 semaines

2.5.3 Validations mensuelles

Des réunions mensuelles devaient être réaliséss a�n de montrer l'évolution del'application aux techniciens et recueillir des critiques a�n d'améliorer le travailréalisé. La validation de l'avancement du projet est un point important a�n de nepas dévier de l'objectif initialement prévu.

Figure 2.5 � Déroulement des réunions mensuelles - TAOCHY Kévin

François BOYER, le tuteur de stage, nous faisait part également de son aviset de ses préférences concernant l'application très régulièrement.

23

2.5.4 Cycle de développement

Le cycle de développement que j'ai entrepris est le suivant :

Figure 2.6 � Cycle de développement - TAOCHY Kévin

C'est un projet de moyenne importance, qui concerne un service du ConseilGénéral. Cet outil va en aucun cas changer les principes et les fondements duSSU. Cependant, le but est d'apporter au technicien de maintenance un moyend'analyse supplémentaire sur un équipement informatique, c'est à dire améliorersa condition de travail. De ce fait, ce cycle de développement est un processussu�sant et adapté pour ce type de projet. En�n, la maintenance est un pointessentiel a�n d'assurer la continuité de l'outil à la suite de notre stage.

Cas d'utilisation de l'application Après avoir analysé les besoins, nous avonsétabli un diagramme concernant les cas d'utilisation de l'outil. Le technicien pro-cédera soit à l'analyse d'une imprimante, soit à l'analyse d'un poste de travail, soitune exploration du réseau a�n de trouver des imprimantes sur un site.

24

Figure 2.7 � Diagramme de cas d'utilisation - TAOCHY Kévin

25

Chapitre 3

État de l'art

Dans ce chapitre, je présente dans un premier temps 3 solutions susceptiblesd'être choisi a�n de répondre à la problématique. Puis dans un deuxième temps,je montrerai les raisons qui m'ont poussé à choisir un outil de développement enparticulier.

3.1 Des outils et langages de développement

3.1.1 Le langage PHP

PHP : Hypertext Preprocessor, connu sous le sigle PHP est un langage deprogrammation impératif orienté objet utilisé principalement pour la création depages Web dynamiques. Il s'agit d'un langage interprêté. PHP est né en 1994, ils'agissait là d'une simple bibliothèque en Perl. En 1995, son concepteur décida depublier le code, a�n que tous les développeurs puissent en pro�ter. En 1997, desétudiants décidèrent de renforcer le coeur du langage et son moteur. Puis au �ldu temps, les versions de ce langage se succédèrent. Aujourd'hui, PHP est à saversion 6. C'est à ce jour le langage Web le plus utilisé dans la communauté desdéveloppeurs.

Fonctionnement Le client, via son navigateur va envoyer des requêtes au ser-veur HTTP. Si la page est identi�é comme du code PHP, l'interpréteur du langagesera appelé et va traiter le code a�n d'en ressortir du code HTML. Ce contenu estalors renvoyé au serveur HTTP, qui l'envoie au navigateur et son client. Il peut yavoir également une étape de dialogue entre PHP et la base de données grâce àune connexion SGBD.

26

Figure 3.1 � Fonctionnement de PHP

3.1.2 ASP.NET

ASP.NET fournit un modèle de développement Web qui o�re des services a�nde générer des applications Web et permet de tirer parti au mieux du CLR 1 deMicrosoft. Le langage utilisé principalement pour le développement est C# (pro-noncé C "Sharp"), un langage orienté objet à typage fort. On retrouve une grandesimilitude avec le langage Java.

Les applications ASP.NET peuvent donc être écrites en plusieurs langages .NET,le CLR pourra les interprêter. Les pages Web ASP.NET permettent égalementde créer du contenu dynamique. Lorsqu'une personne demande une page WebASP.NET, celle-ci va s'exécuter en tant que programme côté serveur. Tous les cal-culs, les requêtes vers les bases de données ou les appels vers les autres programmesvont se lancer. De plus, comme la plupart des langages objet, ASP.NET disposed'un ramasse-miettes a�n de toujours libérer de l'espace mémoire.

3.1.3 Ruby On Rails

Ruby est un langage de programmation open-source et libre. Il est interprété,contrairement aux langages compilés et est orienté-objet. Il est standardisé en2011 au Japon et en 2012 par ISO . Ruby est facile d'accès, c'est-à-dire simpleen apparence mais doté d'une architecture interne très complexe, ce qui en fait sa

1. Common Language Runtime : Machine virtuelle du framework .NET permettant d'exécuterle code.

27

robustesse.

Ruby, le langage. Tout est un objet dans ce langage, chaque entité d'informa-tion et de code peut recevoir ses propres propriétés et actions, y compris les typesde base. De plus, Ruby se rapproche des langages de haut-niveau par sa facilité enterme d'écriture d'algorithme.

Les blocs sont utilisés dans Ruby, ce qui assure une grande �exibilité. Le program-meur peut appliquer à chaque méthode, une closure, un bloc de code décrivant lamanière dont la méthode doit se �nir. On a comme type de bloc le if. . . else. . . end,mais encore do. . . end etc.

D'autres fonctionnalités sont à la disposition du programmeur, on peut parler degestion des exceptions, tout comme Java, ce qui permet au développeur de gérerles erreurs. Le ramasse-miettes est également un des principaux atouts de Ruby, cequi permet de ne pas s'occuper de l'espace mémoire utilisé comme pour le langageC. En�n, Ruby est portable, le développement est possible sur une grande partiedes systèmes UNIX, des Windows, des Macs et est principalement utilisé sur lesdistributions Linux.

Rails, le framework écrit en Ruby. Rails est un framework web libre et écriten Ruby. Il est basé sur une architecture MVC 2. Les modèles sont des classes quigèrent les données, Rails détermine automatiquement la structure de celles-ci àpartir de la base de données (Classe mère ActiveRecord). Les vues correspondentà la manière dont est a�ché le contenu à l'utilisateur. Ce sont des �chiers quimélangent HTML et Ruby qui permettent l'a�chage des informations. En�n, lescontrolleurs s'occupent des actions des utilisateurs, ils récupèrent les données sai-sies ou stockées dans la base de données pour leur a�chage. Des �chiers de routagepermettent d'exécuter une méthode d'un controller à la demande du client.

2. Model View Controller

28

Figure 3.2 � Fonctionnement de Rails - MVC

3.2 Avantages et inconvénients

Voici un tableau des di�érents avantages et inconvénients de chaque outil dedéveloppement Web vu précédemment.

29

Avantages InconvénientsPHP - Multi plateforme : compatible

avec tous les navigateurs- Des failles de sécurité dues à sapopularité

- De nombreuses interactionsavec le serveur (BDD, scripts,...)

- Pas de typage donc attention àla lisibilité

- Beaucoup de documentations - Pas de structure prédé�niecar très utilisé - Peu robuste- Un IDE (Eclipse) pour tout(PHP, MySQL, Flex)

ASP.NET - Une librairie très complète - Trois IDE au moins pour tra- Un langage robuste vailler (Visual Studio, Flex Buil-- Possibilité de développer en der, SQL Server)VB.NET, ou C# - Payant

- Hébergement limitéRuby On Rails - Framework gratuit - Quelques signes de lenteur

- Structure MVC bien intégrée - Récent, des mises à jour fré-- Langage littéraire, simple à quentes donc changement légercomprendre du langage- Hébergement simpliste

3.3 Solution retenue

La solution choisie pour développer l'outil est : Ruby On Rails. Après uneétude approfondie et avoir pris connaissance de ce qui était déjà réalisé à la DEMS,j'ai opté pour ce framework pour des raisons simples :

� Le framework est gratuit, il su�t donc de télécharger les di�érents outils a�nde l'installer

� L'architecture Model View Controller apporte une réelle vision et une sim-pli�cation sur les di�érentes parties de l'application (base de données, géné-ration du code HTML, contrôle sur l'action du client)

� Grâce à un module pour Apache, le déploiement pourra se faire sans contraintessur un serveur Linux et pourra être couplé à un module de sécurité commeKerberos. De plus, un serveur d'authenti�cation Kerberos est déjà en placeà la DEMS.

� Découvrir ce langage me permettra d'avoir une vision encore plus large etdes connaissances supplémentaires sur le développement Web.

30

Chapitre 4

Ruby On Rails, du déploiement àl'authenti�cation

Nous allons voir dans ce chapitre le moyen de déploiement choisi pour notresolution, l'accès à l'application mais également les principales raisons de ces choix.

4.1 Passenger Phusion, module pour Apache

4.1.1 Un outil open-source

Après avoir choisi ma solution, je me suis penché sur un élément très importantde le cadre d'une application Web, le déploiement et surtout la mise en produc-tion. Il existe plusieurs modules pour déployer une application Rails. On peutciter par exemple JRuby On Rails, qui amène le framework vers une JVM 1. Ala DEMS, Pierre-Louis CORION, ingénieur au SAR, a étudié ce framework et adéployé son application Boumbo sur les serveurs de la DEMS. Il m'a présenté lemodule pour Apache, Passenger Phusion, connu également sous le nom mod_rails.

Passenger Phusion permet de déployer en production nos applications Rails surApache et gère seul le côté Back End de notre application, il su�t de l'installeret de le lancer. Il est donc plus facile de commencer le développement de notreapplication, et la tester. Mod_rails est open-source et doit être installé sur unemachine Linux. Une demande de création de machine virtuelle et d'accès a étéfaite a�n de pouvoir installer cet outil. A�n d'accéder à l'application, le serviceApache doit être démarré et l'utilisateur a tout simplement besoin d'un client denavigation Web et de l'adresse de la machine virtuelle.

1. Java Virtual Machine : Machine Virtuelle Java

31

4.1.2 Les raisons de ce choix

La première raison pour laquelle j'ai décidé de choisir ce module de déploiementest tout simplement la possibilité d'utiliser un système d'authenti�cation unique,se gre�ant à Apache. Il est important pour la sécurité de notre application etsa con�dentialité d'intégrer un moyen d'identi�er ses utilisateurs. La deuxièmeraison est le serveur d'authenti�cation Kerberos déjà en place à la direction. Il estévident que notre application doit fonctionner avec les mêmes politiques de sécuritédu Conseil Général. En�n, c'est un outil gratuit qui est utilisé par énormément dedéveloppeurs, qui con�rme sur les di�érents forums sur le Web sa stabilité et sonintérêt. Nous allons voir dans la section suivante les avantages et inconvénients decette protection.

4.2 SSO : Kerberos, le gardien

Notre application est accessible seulement aux agents de la DEMS. Il a doncfallu ré�échir à un moyen d'authenti�cation sûr, e�cace et simple à con�gurer.

4.2.1 Single Sign-On

Durant le cursus en Licence Informatique, un moyen a été étudié : il s'agit de laconnexion en utilisant les annuaires LDAP. L'annuaire LDAP regroupe toutes lesinformations concernant un utilisateur, notamment son nom et son mot de passe.Un utilisateur, pour accéder à une application, écrit dans les champs correspon-dants ces informations et un processus de véri�cation se fait a�n d'autoriser sonaccès à l'application. Les utilisateurs, en général, n'aiment pas ce processus, sur-tout si celui-ci est à répétition. De plus, ils doivent souvent retenir tous les motsde passe utilisés pour chaque application, chose qui n'est pas forcément évidentepour tout le monde.

L'authenti�cation unique appelé SSO 2 a tous ses avantages à ce niveau. Lebut de cette technique est d'e�ectuer une seule authenti�cation a�n d'accéder àplusieurs applications ou sites Web sécurisés. Un seul mot de passe est nécessaire.De plus, il est plus facile de dé�nir et mettre en ÷uvre les politiques de sécu-rité, c'est-à-dire les plans d'actions pour assurer la pérennité et l'intégrité d'uneapplication.

2. Single Sign-On

32

4.2.2 Avantages

L'utilisateur a une meilleure souplesse concernant ses mots de passe. Un seul estutilisé pour plusieurs applications. Cette technique est utilisée par plusieurs géantsdans le domaine informatique, comme Google ou Microsoft. Par conséquent, moinsde temps est utilisé pour cette étape d'authenti�cation.De plus, ces systèmes d'authenti�cation sont centralisés, les modi�cations appor-tées doivent s'e�ectuer au même endroit (avantage sur le contrôle ou les restrictionsd'accès).

4.2.3 Un point négatif

L'inconvénient de SSO reste tout de même l'accès à de nombreuses ressourcespar le biais d'une authenti�cation. Si un utilisateur mal intentionné arrive à seconnecter en récupérant le mot de passe d'un agent, les pertes peuvent être nom-breuses. Un système plus sécurisé est nécessaire, qui permettrait de palier à cesouci de vol de mot de passe.

4.2.4 Kerberos, la solution

Chaque poste est placé sous le domaine utilisé au sein de la Collectivité et unebase d'utilisateurs (annuaire) a été crée a�n que chacun d'entre eux puisse ouvrirune session Windows via Active Directory. Il est donc possible de dé�nir des res-trictions grâce à cet annuaire disponible.C'est là qu'intervient le protocole d'authenti�cation Kerberos (qui vient de Cer-bère, gardien de la porte des enfers dans la mythologie grecque). C'est lui quidonne l'autorisation à un utilisateur d'utiliser l'application sans qu'il utilise unmot de passe. On dé�nit le groupe d'utilisateurs autorisés à accéder au service et àchaque tentative, Kerberos véri�e et donne un ticket d'accès au client (utilisationd'un serveur d'émission de tickets). Ce procédé évite à l'agent de s'authenti�er àchaque utilisation, et de plus, une procédure d'identi�cation de l'utilisateur (nomd'utilisateur récupéré par l'ouverture d'une session Windows) est faite a�n d'éviterqu'un utilisateur externe au domaine et donc à l'annuaire utilise l'application. Leserveur attribue une clé secrète avec un certain temps de validité à un client etc'est cette clé qui lui ouvrira la porte de l'application. Kerberos utilise l'algorithmede chi�rement DES 3, technique qui s'avère malheureusement vieillissante et facileà contourner.

Kerberos assure l'identi�cation des utilisateurs grâce à un serveur d'authen-ti�cation(AS 4) et les autorise à accéder aux applications et services à l'aide du

3. Data Encryption Standard4. Authenti�cation Server

33

Figure 4.1 � Architecture et fonctionnement de Kerberos

serveur d'émission de tickets (TGS 5). Ces deux services sont réunis dans ce qu'onappelle le Centre de Distribution des Clés (KDC 6).

Après avoir pris connaissance de ces di�érents procédés et système d'authen-ti�cation réalisés en interne, nous avions pu commencer à ré�échir sur le modede fonctionnement que nous avions entrepris concernant ce projet, puis le réaliserconcrètement.

5. Ticket Granting System6. Key Distribution Center

34

Chapitre 5

Réalisation

Dans ce chapitre, nous verrons dans un premier temps comment nous avionsabordé ce projet, puis les choix réalisés vis à vis du développement de l'outil et lesproblèmes rencontrés.

Ce schéma simpli�é introduit ce chapitre en expliquant mon exploitation del'architecture MVC a�n de réaliser cette application. Les �èches indiquent les in-teractions entre les di�érentes entités Modèle Vue et Contrôleur de l'outil et leschoix que j'ai réalisé pour le mécanisme de diagnostic et discovery.

Figure 5.1 � Utilisation de l'architecture MVC - Kévin TAOCHY

35

Grâce aux controllers, l'application attend chacune des actions que peut réaliserle technicien, à savoir lancer un diagnostic, réaliser les requêtes ou amorcer lediscovery d'imprimantes. Les modèles (classe Site et Secteur) font directementl'interaction avec la base de données SQL. En�n, les views a�chent l'informationet les boutons au technicien.

5.1 Le diagnostic à l'instant t

Nous aborderons dans cette section le travail concret réalisé et l'approche quej'ai eu par rapport à cette problématique.

5.1.1 Superviser les imprimantes

Les imprimantes étant connectées au réseau Intranet, il a fallu ré�échir à unmoyen de récupérer des informations concrètes sur chaque périphérique. Notrepremière analyse était de détecter l'emplacement des informations sur ces impri-mantes, c'est à dire le toner, l'état ou encore leur description.

Figure 5.2 � Exemple de MIB

36

Sur les entités réseau, il existe des bases d'informations appelés MIB 1 quipeuvent être exploités a�n de les surveiller. Ces bases peuvent être interrogéesgrâce au protocole SNMP 2 et sont de structure hiérarchisée comme l'indique leschéma ci-dessous. Un identi�ant unique appelé OID est associé à chaque infor-mation de la base.

Disposant d'un agent SNMP déjà installé sur ces périphériques, Patrick IRSA-POULLE a e�ectué des recherches sur le moyen de récupérer ces informations.Après étude et validation, c'est donc un outil de supervision qui ira en constancechercher ces données : Centreon, couplé à son moteur Nagios.

Avantage. Nagios communique avec ces entités via le protocole SNMP et Cen-treon stocke ces informations dans une base de données interne de type SQL.L'intérêt d'un tel outil est donc évident : depuis notre application Rails, il mesu�ra d'indiquer l'adresse de la machine hébergeant Centreon et le nom de basede données a�n d'envoyer mes requêtes. De plus, les requêtes sont d'une rapiditéremarquable, ce qui est très important lors du diagnostic qui va être réalisé par letechnicien : les résultats apparaîtront en quelques secondes.

Inconvénient. La supervision du matériel est un processus à répétition. Despaquets sont échangés sans arrêt entre le moteur Nagios et les imprimantes, ce quiimplique une utilisation de la bande passante fréquente. Des ressources sont doncutilisées, même si celles-ci sont tout de même minimes.

Connexion avec l'application Rails. Grâce à la classe ActiveRecord, il estpossible de se connecter à une base de données distante. En e�et, les informationsà renseigner sont simplement l'adresse IP de la machine virtuelle, le nom de labase de données, ainsi que le nom d'utilisateur et le mot de passe pour l'accès. Unobjet de connexion est donc crée et des requêtes SQL peuvent être établies entrela Vue de l'application et la base Centreon.

1 <% @connect = ActiveRecord : : Base . e s tab l i sh_connec t i on ({ : adapter => 'mysql ' ,

3 : database => ' centreon_status ' ,: host => ' address_ip ' ,

5 : username => ' root ' ,: password => ' ∗∗∗∗∗∗ ' }

7 ) %>

Listing 5.1 � Se connecter à une base SQL distante

1. Management Information Base2. Simple Network Management Protocol

37

Top Access. Un bouton Top Access a été intégré a�n d'accéder directement enun clic à la page de con�guration de l'imprimante.

Figure 5.3 � SNMP - Communication de base

5.1.2 Requêter simplement les postes de travail

La supervision est une pratique utilisant des ressources informatiques, pou-vant diminuer légèrement de façon générale le débit sur le réseau. Plus le nombred'équipements à surveiller est grand, moins la rapidité de l'outil de supervision seragrande. Au Conseil Général, plus de 3500 postes sont connectés au réseau (contreseulement 500 imprimantes), un nombre très important. Les débits étant limités(mauvais retours des agents de la zone Sud de la Réunion), il est préférable de nepas les diminuer. De plus, ces équipements ne font pas partie du coeur du systèmed'informations mais l'utilisent. Il est donc futile de recevoir des informations sanscesse sur ces machines.

38

Figure 5.4 � Processus d'implémentation SNMP sur les postes Windows - KévinTAOCHY

Comme nous l'avons vu précédément, l'agent SNMP doit être installé et ac-tivé sur l'entité réseau que l'on veut requêter. Malheureusement, sur les postes detravail, l'agent n'est pas installé au préalable sur les systèmes Windows (commenous montre la Figure 5.2, ce qui nous limite dans notre utilisation du protocole.De plus, les informations comme la stratégie Windows n'apparaissent pas dans cesMIB.Par conséquent, le moyen choisi est tout simplement l'utilisation de simples re-quêtes vers ces di�érentes machines. Grâce à Ruby, il est possible d'exécuter descommandes Shell comme le ping.

1 argument = " t e s t "output = %x [ nom_de_la_commande #{argument } ]

Listing 5.2 � Exécuter une commande Shell avec Ruby

Avantage. Contrairement à la supervision, les requêtes sont e�ectués lors del'analyse du matériel, ce qui implique une utilisation ponctuelle des ressourcesinformatiques.

Un inconvénient de taille. Malheureusement, les commandes Shell ne s'ap-pliquent pas aux outils spéci�ques de Microsoft comme Active Directory. Noussommes donc limités par rapport à l'architecture et à la plupart des outils utiliséspar la DEMS, comme les outils d'administration à distance (Bureau à distance ouAssistance à distance). Une alternative a dû être étudiée.

39

5.1.3 Analyse du matériel à la demande

François BOYER nous a demandé à concevoir un outil qui sera utilisé principa-lement lors d'une analyse technique d'un matériel dans le contexte d'une demandeintervention. C'est à la demande du technicien qu'un diagnostic de premier niveausera établi. Il était donc important de voir visuellement un bouton qui permet delancer ce diagnostic. Les paramètres liés à ce bouton sont simples :

� L'adresse IP, a�n d'appliquer les di�érentes requêtes SQL ou Bash sur leshôtes ou imprimantes distants. Après avoir constaté dans mon étude de l'exis-tant de la présence d'un DNS et des normes concernant le nom des ordina-teurs et des imprimantes, il est possible également de renseigner le nomde l'hôte ou de l'imprimante, et de procéder par la suite à une résolutiond'adresse IP.

� Le type du matériel, a�n de donner les résultats correspondants à l'équipe-ment concerné.

5.2 A la recherche des imprimantes

A la demande de notre tuteur, il est possible d'avoir la liste des imprimantesplacées sur un site. On appelle cette technique le discovery, qui va tout simplementrechercher sur le réseau la présence d'une entité.

5.2.1 La di�érenciation des sites du Conseil Général

Comme nous l'avons vu dans l'étude de l'existant, les sites sont di�érenciés surle réseau grâce au deuxième octet de l'adresse IP. Par exemple, le site de la DEMScorrespond à la plage d'adresse IP 10.1.1-254.1-254. Pour le bon établissement dela zone d'intervention, un découpage a été établi par zone : Nord, Sud, Est etOuest, et pour chacune d'elles les sites qui leur sont associés.

A�n de faciliter la recherche d'un site avant son inspection, j'ai décidé d'établirune base de données :

C'est l'attribut plageIP qui va me permettre d'exécuter la recherche d'impri-mantes par site.

40

Figure 5.5 � Diagramme de classes associant les zones géographiques aux sites

Boites de sélection dynamiques. A�n de �ltrer les sites en fonction de leursecteur, j'ai dû rechercher et implémenter un mécanisme qui va analyser la zonesélectionnée et générer automatiquement les sites qui sont liés. La classe Active-Record permet entre autre d'utiliser la technologie JSON 3 qui est un format dedonnées textuelles permettant d'a�cher de l'information structuré comme XML 4

le permet. La classe ActiveRecord de Rails permet de convertir très simplementdes informations de la base de données au format JSON. J'ai ensuite écrit un codeen javascript qui, à la sélection du secteur géographique par le technicien, va gé-nérer dynamiquement les sites correspondants (voir Annexe A). Il est importantpour le technicien de retrouver très rapidement un site, c'est un gain de temps.

@objets = Class . to_json2 render : j son => @objets

Listing 5.3 � Conversion d'une classe Ruby en �chier JSON

5.2.2 Discovery par SNMP

Il est possible par le biais du protocole SNMP d'e�ectuer une exploration duréseau, dit discovery en anglais. En e�et, cette opération s'exécute en deux étapes :

� Scanner les ports a�n de détecter la présence d'un matériel ou un service� Récupérer les informations concernant le matériel en fonction de l'adresse IPet du port

3. JavaScript Object Notation4. Extensible Markup Language

41

Patrick IRSAPOULLE a repris le travail l'un des travaux d'un agent du SAR.Il s'agit d'un script récupérant par SNMP les informations concernant les impri-mantes en réseau en fonction d'une plage d'adresses IP. Il utilise deux outils pourson exploration : Nmap et snmpwalk, correspondant respectivement aux étapesdétaillées précédemment. En sortie, un �chier contenant les informations sur lesdi�érentes imprimantes du site était crée.

Exécution du script et recueil des résultats. Après modi�cation du script,mon but était de l'implémenter dans mon architecture Rails et générer les lienscorrespondants aux di�érentes lignes du �chier de sortie. En cliquant sur chaquelien, le technicien lance le diagnostic du matériel correspondant. J'ai placé ce scriptsur la machine virtuelle, et depuis mon application Ruby, je lance le discovery enindiquant la plage d'adresses IP et l'emplacement du �chier que je veux alimenter.Puis, une fois l'exploration faite, l'application va e�ectuer un découpage à chaqueligne du �chier et récupérer les informations nécessaires pour chaque imprimantea�n de provoquer le diagnostic de ces entités.

Intérêt. Notre discovery permet donc de rechercher les imprimantes qui sontsitués sur un site. En e�et, cette fonctionnalité lui permettra de faire une conclusionrapide sur l'état du réseau sur un site donné. De plus, si le numéro de l'imprimanten'est pas indiqué, le discovery lui permettra également de retrouver l'imprimantedéfectueuse grâce à son nom de modèle.

5.3 Les di�cultés rencontrées

J'ai été confronté à plusieurs soucis durant ce stage, qui ont ralenti le déve-loppement de l'outil. Dans cette section, j'expose les problèmes rencontrés et lesmoyens qui m'ont permis de les contourner.

5.3.1 La barrière Linux - Windows

Comme cité précédemment, les commandes Shell ont un champ d'applicationrestreinte, en fonction du système d'exploitation. En e�et, depuis une console Unix(côté serveur), il est peu évident de communiquer avec des postes de travail Win-dows. La barrière entre les systèmes Unix et Microsoft a été négligée.

Cependant, les machines utilisés par les techniciens sont sous le système Win-

42

dows. Il est donc possible d'utiliser la base de Registre 5 de la machine. C'est unebase contenant les données de con�guration du système d'exploitation Windows,comme l'exécution d'actions lors de l'utilisation des protocoles. Il su�t d'ajou-ter un nouveau protocole dans la base et via un lien HTML, généré par le codeRuby, le Registre exécutera un script Visual Basic 6 également placé sur le postedu technicien. Ce script exécutera la requête voulue via une commande DOS parle professionnel et a�chera à l'écran les di�érentes informations résultant de cettecommande ou les outils d'administration voulus.

[HKEY_CLASSES_ROOT\protocole_name ]2 @="URL: Protoco l e protocole_name""URL Protoco l "=""

4 "EditFlags "=dword :00000002"BrowserFlags "=dword :00000008

6

[HKEY_CLASSES_ROOT\ execute \ s h e l l \open\command ]8 @="\"PATH\ c s c r i p t . exe " \"PATH\scriptVB . vbs" %1"

Listing 5.4 � Ajout d'un nouveau protocole dans le Registre

Le chemin (PATH) doit être con�guré dans ce code à chaque copie des deuxscripts (édition de Registre et Visual Basic Script) sur les ordinateurs des techni-ciens. Concernant le code Ruby, il su�t de générer un lien HTML et d'écrire lacible du lien comme ainsi :

<%= link_to "nom_du_lien" , "nom_protocole : // argument1_argument2" %>

Listing 5.5 � Génération d'un lien HTML avec protocole

C'est en utilisant ce procédé que les di�érentes fonctionnalités d'accès à distanceou requêtes spéci�ques à Windows vont pouvoir être lancés. L'avantage est depouvoir exécuter des programmes ou scripts même depuis un serveur Linux sur cessystèmes. L'inconvénient est l'obligation d'installer ces scripts et éditer le Registredu poste du technicien a�n d'utiliser pleinement l'outil que nous avons développé.

5.3.2 Ports fermés et droits d'accès

La sécurité est un mot d'ordre à la DEMS, tout accès doit être justi�é. Endéployant mon application sur l'un des serveurs, j'ai dû faire la demande d'ouver-ture de plusieurs ports, tout en justi�ant mes requêtes. L'utilisation de protocolescomme ICMP ou UDP pour le diagnostic dépendent de leurs accès vers le réseauIntranet. En e�et, le serveur sur lequel j'ai e�ectué mon déploiement est isolé

5. Base de con�guration Windows6. Langage de programmation crée par Microsoft

43

du reste des serveurs du Conseil Général, ce qui a retardé le développement del'application.

5.3.3 Des problèmes de normalisation

Lors de l'installation des imprimantes, les techniciens doivent les renommer a�nde suivre la normalisation imposée au Conseil Général. Malheureusement, environ15% de ces entités ont été correctement nommés après leur mise en place. Ce fait estclairement un problème pour notre outil. Pour procéder à la résolution d'adressesIP, le technicien doit connaître au préalable le numéro du matériel concerné, nu-méro qui est renseigné dans la demande d'intervention. Par conséquent, le DNSne fera pas de lien entre le numéro du matériel et le nom de l'imprimante, et netrouvera aucune adresse IP correspondante.

Nous avons donc proposé au responsable du SSU d'élaborer à une campagne derenommages des imprimantes a�n d'exploiter au maximum notre outil.

5.4 Livrables

Autour de notre application, des outils ont dû être implémentés a�n de conduireau mieux l'analyse du matériel. Après les tests, nous sommes donc passés à uneétape intégration de l'outil et maintenance.

5.4.1 Architecture de l'outil

L'outil est donc décomposé en deux grandes parties :

� La partie serveur où nous avons hébergé l'application Rails, qui est passé enmode production. Nous avons également les modules Kerberos (authenti�-cation) et Passenger Phusion (déploiement) qui ont une importance considé-rable dans le bon fonctionnement de l'outil.

� La partie cliente qui intègre un navigateur Web, un script Visual Basic oùdes commandes DOS seront exécutés a�n d'accéder aux outils d'administra-tion Windows et un Registre édité.

Il est important également de montrer au technicien le fonctionnement de l'ap-plication. Les di�érentes pages et boutons doivent être explicités a�n de connaîtreexactement le processus d'utilisation de l'outil.

44

Figure 5.6 � Architecture de l'application Diagmoustik - Kévin TAOCHY

Figure 5.7 � Principe de fonctionnement de l'outil - Kévin TAOCHY

45

5.4.2 Documents écrits

A�n d'utiliser l'application, des documents techniques doivent être donnés auservice a�n de comprendre l'utilisation de l'outil, les techniques utilisés et les infor-mations a�chés. Une documentation est importante a�n de formaliser nos travauxet nos choix de conception.

Deux types de documents ont été rédigés :

� Un document technique expliquant l'architecture, les technologies utiliséeset la méthode abordée a�n de récupérer les données de chaque matériel.

� Un manuel d'utilisation de l'outil qui indique la procédure à suivre et com-ment analyser les informations a�chés.

5.4.3 Maintenance

A�n d'assurer la pérennité de l'outil et éventuellement la reprise de nos travaux,il était primordial pour Patrick IRSAPOULLE et moi-même ainsi que pour le SSUd'avoir des détails techniques et des commentaires concernant notre code. Pour mapart, a�n de pouvoir réutiliser mes scripts, des commentaires ont été faits a�n dereprendre ma démarche dans le code et les mécanismes qui sont utilisés. De plus, cetravail m'a permis également de toujours me situer dans mon écriture et spéci�erl'utilité et le but de mon code. Grâce à un éditeur de code proposant une colo-ration syntaxique, il est facile de repérer les lignes de commentaires de mes �chiers.

Avec le document technique fourni, il sera très simple de se placer dans l'architec-ture MVC de l'application et de comprendre les principes. En cas de migration deserveur ou déplacement de �chiers, les modi�cations que l'on doit apporter auxconnecteurs à distance (base de données Centreon par exemple) sont indiqués.

46

Chapitre 6

Conclusions et Perspectives

Bilan et perspectives du projet. Le but de ce projet était d'apporter une aideconcrète aux techniciens du Service Support Utilisateur du Conseil Général en leurdonnant des informations pertinentes concernant l'état d'un matériel défectueuxou mal con�guré. En e�et, ces techniciens doivent assurer le bon fonctionnementdu matériel pour 5000 agents, un nombre très important. Il est donc importantd'éviter les déplacements supe�us dus à des faux problèmes et pouvoir traiter plusrapidement les autres demandes. Du fait du temps passé sur les autres projets quenous avons dû mener avec mon collègue Patrick IRSAPOULLE, notamment laformation "Prise en main de l'outil informatique" que j'ai cité dans mon introduc-tion (préparation, conception du support de formation, formation des groupes etréalisation), ce projet a été retardé. Cependant, malgré un côté design assez léger,nous avons pu réaliser ce projet à une estimation d'environ 80%. En e�et, nousavons réussi à développer un outil beta qui a�che des informations pertinentes,comme le toner, les informations DNS ou la stratégie Windows appliquée. De plus,j'ai réussi à faire en sorte de lancer directement les outils d'administrations depuisl'application, comme le Bureau à distance ou le Top Access. Aussi, c'est un outilexclusif aux agents de la DEMS, l'aspect authenti�cation n'a pas été négligé. Desaméliorations peuvent être apportées concernant l'aspect visuel de l'applicationet le traitement des informations. Malheureusement, la version mobile de l'outiln'a pas pu être abordée, étant clairement rattrapé par le temps. Mais le planningprévisionnel a été plus ou moins respecté.

Ce projet se doit d'être poursuivi au vu de ses mérites au sein de la DEMS. Ene�et, cette version doit continuer à être développée a�n de l'éto�er et la rendrecomplètement indispensable. Un système de suggestions dynamiques pourrait êtreétabli, qui permettrait au technicien de lancer plus rapidement un diagnostic, plu-tôt que d'écrire le nom entier ou l'adresse IP entière de l'entité. De plus, une versionmobile mérite d'être conçue. En e�et, les techniciens pourraient accéder à l'outil

47

entre deux interventions et avoir des précisions sur un matériel, ce qui apporteraitune connaissance supplémentaire avant le déplacement. La librairie JQueryMobilepermettrait de concevoir une Web App, multi plateforme et donc compatible avectous les appareils mobiles. Cependant, un accès depuis l'extérieur doit être établi.

Cet outil concerne seulement les postes de travail et les imprimantes. Il ne s'agitpas des seuls équipements en réseau utilisés au sein du Conseil Général, on yretrouve également des photocopieurs, des scanners et des auto-commutateurs té-léphoniques permettant de relier les postes téléphoniques d'un établissement avecle réseau téléphonique public. Pouvons-nous donc étendre l'utilisation de cet outilvers d'autres équipements qui pourraient servir à d'autres agents de la DEMS,comme ceux de la cellule téléphonie ?

Apport personnel. Ce stage était ma première expérience professionnelle et unegrande réussite pour moi. Mon intégration s'est faite très rapidement grâce auxagents du Service Support Utilisateur, notamment Anise FONTAINE, et Marie-Paule CRESCENCE du Service Ressources & Méthodes. Dès mon arrivée, j'ai pucomprendre le rythme e�réné et quotidien dans un service comme le SSU et ila fallu que je m'adapte. J'ai su adopter ce rythme, et répondre toujours présent.Étant confronté à une architecture réseau très importante et ayant peu de connais-sance à ce niveau, j'ai appris énormément de notions dans ce domaine, et réalisél'importance d'avoir un réseau Intranet toujours �able. Pour rappel, la DEMS doitassurer le meilleur service pour 5000 agents.

Ce que je retiendrai avant tout de cette expérience, c'est le travail à fournir avantde se lancer dans le développement d'un outil. En e�et, il a fallu réellement com-prendre le besoin derrière ce projet, et surtout dans quelles conditions j'allaisdévelopper. La sécurité est un point primordial, et je ne pouvais pas me lancerdans ce travail sans prendre en compte les contraintes qu'impose la DEMS et sonfonctionnement. De plus, le choix d'un outil de développement a dû se faire enfonction des outils déjà en place à la Direction. Autre chose également, une boîteinformatique ne peut pas avancer sans travail d'équipe. Chaque personne a sonimportance, sa spécialité et c'est en travaillant ensemble que nous aboutissons àde vrais résultats. Il est donc important d'interagir avec les autres professionnelsdu milieu et d'entretenir de bonnes relations avec ces derniers. En�n, j'ai prisconscience de ma capacité à réagir face à des problèmes concrets. La documenta-tion et la recherche d'informations ainsi que mes phases de test sont des pointsessentiels que j'ai clairement amélioré.

48

Chapitre 7

Références bibliographiques etwebographiques

7.1 Références bibliographiques

Fact extraction for Ruby on Rails Platform, Nima Tshering, November 2010.

Essential SNMP, Douglas Mauro et Kevin Schmidt, 2001.

7.2 Références webographiques

https://www.phusionpassenger.com/documentation_and_support

http://rubyonrails.org/documentation/

http://nathanhoad.net/how-to-ruby-on-rails-ubuntu-apache-with-passenger

http://support.microsoft.com/kb/256986/fr

http://www-igm.univ-mlv.fr/~dr/XPOSE2006/CLERET/techniques.html

http://www.gladir.com/LEXIQUE/ARTICLES/comparewebphpvsaspnetvsjsp.htm

http://msdn.microsoft.com/fr-fr/library/2x7h1hfk.aspx

http://en.wikibooks.org/wiki/LaTeX/

http://stackoverflow.com/

http://doc.ubuntu-fr.org/snmp

http://apidock.com/rails/ActiveRecord/Serialization/to_json

http://apidock.com/rails/

49

Annexe A

Annexe technique

A.1 Les outils utilisés pour le développement

Notepad ++. C'est un éditeur de texte écrit en C++, qui dispose d'une colora-tion syntaxique des langages comme Ruby ou HTML. C'est un outil léger, e�caceet une vraie alternative aux éditeurs de texte classique sous Windows.

Putty. C'est un émulateur de terminal gratuit doublé d'un client pour di�érentsprotocoles comme SSH, Telnet ou rlogin. Pour mon développement, j'ai utilisé cetoutil a�n de travailler sur la machine virtuelle où j'ai déployé mon applicationRails.

Mozilla Firefox. C'est un navigateur Web qui existe depuis les années 2000qui est open-source et développé grâce à de milliers de bénévoles. C'est grâce àce navigateur que j'ai pu voir le rendu de mon application Rails et tester sesfonctionnalités.

50

A.2 Installation et con�guration Passenger Phu-sion et Rails sur Debian

Étape 1. Installer Ruby (sudo) :

1 apt−get updateapt−get i n s t a l l ruby− f u l l bui ld−e s s e n t i a l

3 wget http :// rubyforge . org / f r s /download . php/57643/ rubygems −1 . 3 . 4 . tgzta r xvz f rubygems −1 . 3 . 4 . tgz

5 cd rubygems−1.3 .4ruby setup . rb

7 ln −s / usr / bin /gem1 . 8 / usr / bin /gemgem update −−system

9 apt−get i n s t a l l apache2 apache2−mpm−pre f o rk apache2−pre fork−dev

Étape 2. Installer Apache, MySQL (sudo) :

1 apt−get i n s t a l l apache2 apache2−mpm−pre f o rk apache2−pre fork−devapt−get i n s t a l l mysql−s e r v e r mysql−c l i e n t

3 apt−get i n s t a l l l ibmysql−ruby l i bmysq l c l i e n t 15−devgem i n s t a l l mysql

Étape 3. Installer Rails (sudo) :

gem i n s t a l l r a i l s

Etape 4. Installer Passenger Phusion (sudo) :

1 gem i n s t a l l passengerpassenger−i n s t a l l −apache2−module

Etape 5. Con�guration de Passenger Phusion :

Copier ces lignes dans /etc/apache2/apache2.conf.

LoadModule passenger_module / usr / l i b /ruby/gems /1 .8/ gems/ passenger−2.2 .2/ ext /apache2/mod_passenger . so

2 PassengerRoot \/ usr \/ l i b \/ ruby\/gems \/1.8\/ gems\ s / passenger −2.2 .2PassengerRuby / usr /bin /ruby1 . 8

Activer rewrite pour Apache(sudo) :

1 a2enmod r ewr i t e

51

Étape 6. Créer une première application :

1 r a i l s mon_projet −d mysql

Étape 7. Ajouter un Virtual Host dans les �chiers de con�guration de Apache :

1 <Virtua lHost ∗>RailsEnv development

3 ServerName se rveur . nomDocumentRoot /var /www/mon_projet/ pub l i c

5 </VirtualHost>

Étape 8. Activer votre serveur et démarrer Apache (sudo) :

1 a2 en s i t e s e rveur . noms e r v i c e apache2 r e s t a r t

Ajouter dans /etc/hosts la ligne :

1 2 7 . 0 . 0 . 1 s e rveur . nom

A.3 Créer des boites de sélection dynamiques avecRails

Ajout de boîtes de sélection dans la vue concernée. Nommer les boîtesde sélection et faire la liaison avec la méthode du contrôleur.

1 <%= form_tag ( " pa r cou r i r / r e s u l t " , : method => ' post ' , : mul t ipart =>true ) do %>

<p>Se l e c t i o nn e r l e s e c t eu r ou se trouve l e s i t e que vous vou lez :</p>3 <%= co l l e c t i o n_ s e l e c t ( n i l , : secteur_id , @secteurs , : id , : name , { :

prompt => " Se l$<p>Se l e c t i o nn e r l e s i t e que vous vou lez ana ly s e r : </p>

5 <%= co l l e c t i o n_ s e l e c t ( n i l , : s i t e_id , @s ites , : id , : name , { : prompt =>" Se l e c t i o n$

<%= submit_tag "Lancer " %></center>7 <% end %>

Listing A.1 � Création des boîtes de sélection

Implémentation du javascript. Dans le �chier .html.erb correspondant, écrirece Javascript.

52

1 $ ( document ) . ready ( func t i on ( ) {$ ( '#s e c t eu r s_s e l e c t ' ) . change ( func t i on ( ) {

3 // r e cupe ra t i on de l ' id du s e c t eu r s e l e c t i o nn esecteur_id = $ ( '#s e c t eu r s_s e l e c t ' ) . va l ( ) ;

5 $ . get ( "/ pa r cou r i r / l i s t _ s i t e s /" + secteur_id , f unc t i on ( data ) {

7 // con s t ruc t i on de chaque <option> du <s e l e c t > des s i t e svar s i t e s_se l ec t_html = '<opt ion value="0">Se l e c t i onne z un s i t e

</option>' $ . each ( data , f unc t i on ( i , s i t e ) {9 s i t e s_se l ec t_html += '<opt ion value=" ' + s i t e . id + '"> ' +

s i t e . name + ' $}) ;

11 // mise a jour du s e l e c t des s i t e s$ ( '#s i t e s_ s e l e c t ' ) . html ( s i t e s_se l e c t_html ) ;

13 } , ' j s on ' ) ;}) ;

15 }) ;

Listing A.2 � Mise à jour de la boite de sélection Sites

Méthode dans le Contrôleur. Dans le contrôleur, rechercher les sites corres-pondant au secteur sélectionné.

1 de f l i s t _ s i t e s@s i t e s = Secteur . f i nd ( params [ : id ] ) . s i t e s . to_json

3 render : j son => @s i t e send

Listing A.3 � Récupération des sites en fonction de l'id du secteur dans la boitede sélection - TAOCHY Kévin

A.4 Diagramme de Gantt

53

Figure A.1 � Diagramme de Gantt - Kévin TAOCHY

54

A.5 Interface de l'application : version Beta

Figure A.2 � Page de lancement du diagnostic - Kévin TAOCHY

Figure A.3 � Résultat du diagnostic pour un poste de travail - Kévin TAOCHY

55

Figure A.4 � Résultat du diagnostic pour une imprimante - Kévin TAOCHY

Figure A.5 � Page de lancement d'un discovery - Kévin TAOCHY

56

Figure A.6 � Page de lancement du diagnostic - Kévin TAOCHY

57