Rapport de stage - Bienvenue sur la page d'accueil · MAGHEZZI venus me rejoindre en cours de stage...

Dpartement informatiqueUniversit de France-ComtStage du 13 fvrier au 4 juin

Anne 2011-2012

Projet Yuukou IIBenot MEILHAC

Rapport de stage

School of Electronics and Computer ScienceUniversity of Westminster115 New Cavendish Street

London W1W 6UW

Tuteur de stage : M. Thierry DELAITREResponsable de stage : M. Jean-Michel HUFFLEN

Remerciements

Je tiens avant tout remercier mon tuteur de stage M. Thierry DELAITREpour son accueil lUniversit, pour mavoir propos un projet aussi intressant, pouravoir mis ma disposition tout ce dont javais besoin pour travailler correctement etaussi pour tout le temps quil ma consacr.

Je remercie galement mon responsable de stage M. Jean-Michel HUFFLENpour mavoir offert lopportunit deffectuer mon stage de fin dtudes Londres maisaussi pour ses conseils et laide apporte pendant la rdaction de ce rapport.

Jadresse aussi tous mes remerciements toute lquipe du CPC, avec qui jaipartag un bureau, pour mavoir accueilli, pour leur aide et leur bonne humeur malgrla barrire de la langue en dbut de stage.

Merci encore mes camarades francophones Damien HOSTACHE et YacineMAGHEZZI venus me rejoindre en cours de stage pour les bons moments passs en-semble.

Jexprime galement toute ma gratitude Clia NASROUNE et JrmieBOURSEAU pour le travail de relecture quils ont effectu et laide apporte.

I

Table des matires

Remerciements I

Introduction 1

1 Lieu de stage 31.1 University of Westminster . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.2 Les diffrents campus et coles . . . . . . . . . . . . . . . . . . . . 31.1.3 Quelques informations sur lUniversit . . . . . . . . . . . . . . . . 4

1.2 School of Electronics and Computer Science . . . . . . . . . . . . . . . . . 51.3 quipes intgres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Infrastructure Team . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.2 Information Systems and Library Services . . . . . . . . . . . . . . 6

1.4 Centre for Parallel Computing . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Prsentation du sujet 82.1 Le projet Yuukou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Quelques chiffres . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.4 Changement vers Yuukou II . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Le projet Yuukou II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Prsentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Rflexions de lquipe technique . . . . . . . . . . . . . . . . . . . . 132.2.3 Premires approches . . . . . . . . . . . . . . . . . . . . . . . . . . 14

II

2.2.4 Contraintes techniques . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 La notion de service Web 163.1 Service Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.3 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 LAPI JAX-WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Le projet Yuukou II 214.1 Recherches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.3 LIDE NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.4 Le serveur Web GlassFish . . . . . . . . . . . . . . . . . . . . . . . 274.1.5 Le SGBD MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.6 Laccs aux donnes des tables . . . . . . . . . . . . . . . . . . . . 284.1.7 Gestion de la base de donnes . . . . . . . . . . . . . . . . . . . . . 294.1.8 Le format de retour . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1.9 Complment dinformation sur JSON . . . . . . . . . . . . . . . . 34

4.2 Communication avec Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.1 Le module MKLivestatus . . . . . . . . . . . . . . . . . . . . . . . 354.2.2 Requtes pour Nagios . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Fonctionnement du service Web . . . . . . . . . . . . . . . . . . . . . . . . 394.3.1 Le cycle principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.2 Les fonctions accessibles . . . . . . . . . . . . . . . . . . . . . . . . 414.3.3 Retour des fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Fonctionnalits en place . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4.1 Scurisation du service Web . . . . . . . . . . . . . . . . . . . . . . 444.4.2 Gnration de graphes dutilisation . . . . . . . . . . . . . . . . . . 454.4.3 Gestion des emplois du temps . . . . . . . . . . . . . . . . . . . . . 464.4.4 Catalogue logiciels des salles . . . . . . . . . . . . . . . . . . . . . 474.4.5 Migration des donnes . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.1 Gestion du poste de travail . . . . . . . . . . . . . . . . . . . . . . 484.5.2 Travail en quipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.5.3 Tests du service Web . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6 Exploitation du service Web . . . . . . . . . . . . . . . . . . . . . . . . . . 504.7 Problmes rencontrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 Bilan 535.1 Bilan du travail ralis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Rcapitulatif du projet . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.2 Calendrier du stage . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.3 Bilan pour lUniversit . . . . . . . . . . . . . . . . . . . . . . . . . 555.1.4 Amliorations possibles . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2 Bilan personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6 Conclusion 58

Bibliographie 59

Glossaire 60

Annexes 63

A Fichiers LQL Nagios 64

B Retours de requte LQL 66

C Base de donnes 68

D Exemples de retours JSON 74

Table des figures 76

Liste des tableaux 78

Introduction

Le cursus professionnel de deuxime anne du Master informatique lUniver-sit de Franche-Comt de Besanon inclut la ralisation dun stage en entreprise dunedure minimum de quatre mois. LUniversit donne, de plus, lopportunit deffectuer cestage ltranger.

Langlais est la langue prdominante dans le domaine de linformatique maiscest aussi un pr-requis indispensable dans certaines recherches demploi. Cest pour celaque jai saisi lopportunit que moffrait lUniversit de raliser mon stage au Royaume-Uni. Cest avec laide de M. Jean-Michel HUFFLEN, Matre de Confrences lUniversitde Franche-Comt, que jai pu intgrer pendant quatre mois lUniversit de Westminster Londres o jai t accueilli par M. Thierry DELAITRE, directeur des infrastructures lUniversit, afin de travailler sur le projet Yuukou II.

Ce projet est n dune collaboration de deux quipes de lUniversit :lInfrastructure Team de la School of Electronics and Computer Science et les servicescentraux informatiques Information Systems and Library Services. De ce fait, jai intgrces deux quipes tout en travaillant dans le Centre for Parallel Computing.

Yuukou, venant du japonais et signifiant validit, disponibilit, efficacit, estun projet mis en place dans le but de montrer lutilisation des salles informatiques etden garder un historique. Ainsi, il permet de connatre la disponibilit des salles delUniversit et offre la possibilit de voir les ordinateurs disponibles, occups ou encoreteints.

Cependant les principaux dveloppeurs de cette application ne faisant plus par-tie de lUniversit, le projet nest plus maintenu. De plus, son principal intrt serait defaire savoir un tudiant les salles qui sont disponibles ainsi que les ordinateurs libres.Ce quil ne fait que trs partiellement actuellement. En outre, lUniversit change lefonctionnement de son infrastructure, ce qui aura, entre autres consquences, de rendrelapplication obsolte.

Cest dans ce contexte que sinscrit le projet Yuukou II. Mon stage consistedonc la mise en place dun service Web permettant le suivi des diffrents ordinateursde lUniversit et pouvant retourner ces donnes pour un affichage sur un smartphone,ou encore un cran plasma se trouvant lentre de chaque btiment par exemple.

1

Le prsent rapport concerne le travail ralis au sein de lUniversit de West-minster. Une premire partie prsentera lUniversit et les services que jai intgrs ainsique ceux que jai ctoys tout au long du stage. Une seconde partie traitera du projetYuukou, avec une prsentation de ses fonctionnalits et de ce quoi il donne accs ainsique des raisons qui ont conduit au projet Yuukou II. Cette partie permettra de dcouvrirle sujet de stage afin de comprendre les choix qui ont t raliss dans les autres partiesdu rapport. La troisime partie mettra en avant la notion de service Web, le point centraldu projet. Ensuite, une quatrime partie prsentera les diffrentes recherches qui ont tfaites ainsi que le travail accompli et les problmes rencontrs. Enfin, une dernire partiedonnera un bilan des diffrents points retenus lors de ce stage avant de clore ce rapport.

NOTE : Les termes marqus dun astrisque() sont dfinis dans le glossaire.

2

1 Lieu de stage

1.1 University of Westminster

1.1.1 Prsentation

Figure 1.1 Blason delUniversit

LUniversit de Westminster est une universit pu-blique de recherche situe Londres. sa fondation, en 1838,elle portait le nom de Royal Polytechnic Institution et tait lapremire cole polytechnique ouverte en Angleterre. Son buttait de fournir une institution o le public peut, moindrecot, acqurir une connaissance pratique des divers arts etbranches de la science en rapport avec les fabricants indus-triels, les oprations minires et lconomie rurale. Sa fonda-tion est une raction la popularit grandissante de lensei-gnement de type polytechnique en Europe continentale. No-tamment avec lAllemagne et la Fachhochschule, la France etlcole Polytechnique ou encore les tats-Unis et la Rensse-laer Polytechnic Institute.

En 1970, la Royal Polytechnic Institution devient Polytechnic of Central Lon-don aprs avoir fusionn avec Holborn College of Law, Languages and Commerce. Cesten 1992 que le statut duniversit fut attribu Westminster qui devint University ofWestminster.

1.1.2 Les diffrents campus et coles

LUniversit compte quatre principaux campus, trois dans le centre de Londres :Regent, Cavendish, Marylebone et le quatrime Harrow, louest de Londres.

Regent : situ au 309 Regent Street, cest le campus le plus ancien de lUni-versit, il contient une cole : School of Social Sciences, Humanities andLanguages ;

Cavendish : situ au 101-115 New Cavendish Street, dans le quartier deFitzrovia proche de West End de Londres (entre Marylebone, BloomsBury et

3

University of Westminster Lieu de stage

au nord de Soho), ce campus contient trois coles : School of Electronics andComputer Science, School of Life Sciences et Westminster Exchange dont lebut principal est lamlioration de lducation ;

Marylebone : situ sur Marylebone Road, en face du clbre muse de cireMadame Tussauds, il contient deux coles : School of Architecture and theBuilt Environment et Westminster Business School ;

Harrow : situ dans le village de style victorien Harrow-on-the-Hill sur-plombant Londres, ce campus contient une cole : School of Media, Art andDesign.

(a) Faade (b) Entre

Figure 1.2 Campus de Regent Street

Outre ces principaux campus, lUniversit compte deux autres sites : Little Tichtfield Street : situ au 4-12 Little Titchfield street, il contient

une cole : School of Law ; Wells Street : situ au 32-38 Wells street, juste au coin des autres btimentsdu campus de Regent, il offre une grande varit de salles de classe.

LUniversit gre galement leWestminster International University Tachkenten Ouzbkistan ainsi quun campus satellite Paris travers lAcadmie Diplomatiquede Londres.

1.1.3 Quelques informations sur lUniversit

LUniversit se situe officiellement au 309 Regent Street London W1B 2HM.Elle compte en 2011 plus de 20 000 tudiants venant de plus de 150 nations diffrentesgrce de nombreux programmes dchange avec dautres universits.Parmi ses diplms les plus prestigieux :

Sir Alexander Fleming, biologiste et pharmacologue britannique, prix No-

4

School of Electronics and Computer Science Lieu de stage

bel de Physiologie ou Mdcine en 1945 avec Ernst Boris Chain et Sir HowardWalter Florey pour la dcouverte de la pnicilline et de son effet curatif surdiverses maladies infectieuses ;

Christopher Bailey, directeur de la cration chez Burberry ; Charlie Watts, musicien et batteur des Rolling Stones.

Concernant les cours, lUniversit donne accs plus de 300 cours diffrents.

1.2 School of Electronics and Computer Science

Le stage sest droul dans cette cole se trouvant, comme vu au 1.1.2, dans lecampus Cavendish au 101-115 New Cavendish Street. La figure 1.3 montre une vue ex-trieure du btiment avec la BT Tower, tour de communication possde par loprateurde tlcommunications BT Group, se trouvant juste ct.

Figure 1.3 Campus de New Cavendish Street

Lcole propose divers parcours, aussi bien dans le domaine de la recherche quedans celui des tudes, allant de lingnierie lectronique et informatique, aux mathma-tiques appliques. Ainsi de nombreuses matires peuvent tre abordes dans la formationcomme la gestion des systmes dinformations, la programmation parallle et distribue,lintelligence artificielle mais aussi le dveloppement de jeux vidos et bien dautres.Il existe quatre grands ples de recherche au sein de lcole qui sont :

Electronic and Communication Engineering, qui se concentre sur le traitementde signaux ainsi que dans la conception de composants et circuits pour les systmes decommunication ;

Operational Research and Intelligent Systems, dont les activits sont principa-lement la modlisation quantitative des systmes complexes pour soutenir des processusdcisionnels, la gestion des donnes et des informations, les technologies de bases dedonnes destines au processus de gestion et dinteroprabilit dans les environnements

5

quipes intgres Lieu de stage

o les logiciels sont omniprsents ;Parallel and Distributed Computing, qui sintresse la recherche et au dve-

loppement dans le domaine des calculs parallles et distribus ;Semantic Computing and Systems Engineering, regroupe des chercheurs de dif-

frentes disciplines, comme le gnie logiciel, les interactions homme-machine, et abordeles aspects thoriques et pratiques de linformatique smantique.

1.3 quipes intgres

Le projetYuukou II sur lequel jai travaill pendant mon stage regroupe deuxservices de lUniversit. Dune part lInfrastructure Team, et dautre part lInformationSystems and Library Services (ISLS). Le but de mon stage tant de fournir un pilote dece quil est possible de faire afin que mon travail puisse tre repris par les deux serviceset dvelopp plus en profondeur.

1.3.1 Infrastructure Team

LInfrastructure Team est une quipe de 13 personnes dans la School of Elec-tronics and Computer Science qui a pour rle de grer les laboratoires spcialiss delcole. Ce sont 34 laboratoires de lcole qui sont sous la responsabilit de cette quipe.Ces laboratoires sont dit spcialiss du fait des possibilits qui peuvent y tre ralises :linstallation de nouveaux systmes dexploitations sur les ordinateurs par exemple.

Lquipe apporte aussi un support pour les laboratoires denseignement et pourles groupes de recherches dans lcole. Elle reprend et tend les services fournis parles services centraux informatiques (voir ISLS au 1.3.2) comme lauthentification, lesquotas de disques, le rseau ou encore les outils denseignement.

1.3.2 Information Systems and Library Services

ISLS est un dpartement dont le but est de contribuer la qualit de lducationdans lUniversit de Westminster travers le dveloppement et la livraison de services.Le dpartement est compos de cinq services qui sont :

Archive Services, qui gre les archives de lUniversit ; Corporate Information, qui dveloppe et livre des applications qui prennenten charge le fonctionnement des activits (enregistrement des tudiants, em-plois du temps, . . .) ;

Infrastructure, qui gre linfrastructure informatique pour fournir des servicesinformatiques et de tlcommunications ;

Learning and Research Support, qui gre la bibliothque et les services infor-matiques pour le personnel et les tudiants ;

6

Centre for Parallel Computing Lieu de stage

Resources and Planning, qui gre les ressources et le planning du dparte-ment.

1.4 Centre for Parallel Computing

Durant toute la dure de mon stage, jai travaill dans le Centre for Paral-lel Computing (CPC). Le bureau se situe au 7e tage de la School of Electronics andComputer Science et est compos de sept personnes. Cette quipe appartient au plerecherche Parallel and Distribued Computing.

Ce centre se focalise sur la recherche dans la technologie et les applicationsde calculs parallles et distribus. Les activits du centre incluent le dveloppementdoutils et denvironnements pour soutenir le cycle de vie dans le gnie logiciel comme lasimulation dvnements discrets en parallle. Les chercheurs travaillent en collaborationavec lUniversit hongroise Sztaki.Parmi les projets dvelopps par le service, on peut citer :

Gemlca (Grid Execution Management for Legacy Code Applications), solu-tion gnrale dont le but est de deployer le code dapplications existantes,quelque soit le langage, comme un service de grille ;

NGS (National Grid Service), solution dont le but est de fournir un accslectronique cohrent pour les chercheurs du Royaume-Uni toutes les res-sources de calculs et de donnes ainsi qu lquipement ncessaire pour mener bien leurs travaux, indpendamment de lemplacement de la ressource oudu chercheur ;

SHIWA (SHaring Interoperable Workflows for lages-scale scientific simula-tions on Available DCIs 1), projet qui a pour but linteroprabilit de diff-rents systmes de workflow europen (comme Moteur, P-Grade, Askalon ouGwes) laide de lapproche par granularit (grain fin ou grossier).

Pendant le stage, jai t rejoint par deux tudiants en troisime anne deLicence Informatique lUniversit de Franche-Comt de Besanon : Yacine MAGHEZZI,travaillant sur la partie affichage du projet qui ma t confi (plus dexplications au 4.1.1) et Damien HOSTACHE, travaillant sur le dveloppement dune applicationpour le portail Web de lUniversit de Westminster dans le but de grer des objets entrois dimensions.

1. Distributed Computing Infrastructure

7

2 Prsentation du sujet

2.1 Le projet Yuukou

2.1.1 Prsentation

Le terme Yuukou comme abord dans lintroduction de ce rapport, vient dujaponais Yuukou et signifie validit, disponibilit, efficacit. Cest un systme permet-tant la rcupration des informations depuis les serveurs LDAP 1 de lUniversit afinde comprendre et construire linfrastructure des ressources et ainsi de voir sa facilitdutilisation. Larchitecture du systme utilise un processus dapprentissage simple pourdduire et maintenir la structure jour avec un minimum de rglages initiaux. Yuukoua t cr pour montrer lutilisation des salles informatiques et conserver un historiquedes informations sur le campus de New Cavendish.

2.1.2 Fonctionnement

Le but principal de Yuukou est dafficher loccupation des salles informatiquesen se rapprochant autant que possible du comportement dun systme fonctionnant entemps rel. Pour ce faire, lapplication a t divise en deux parties comme le montre lafigure 2.1.

1. Lightweight Directory Access Protocol

8

Le projet Yuukou Prsentation du sujet

Figure 2.1 Architecture de Yuukou

Premire partie

La premire partie est un programme crit en Perl qui rcupre les informationsde connexion des utilisateurs depuis un serveur LDAP et qui se charge de construire,modifier ou mettre jour larchitecture rseau de lUniversit tout en stockant les infor-mations dans une base de donnes relationnelle de type MySQL.

Le robot de Yuukou offre deux fonctionnalits : il permet de mettre jour lesdonnes de connexion via le serveur LDAP toutes les cinq minutes environ pour uneutilisation normale, et de mettre jour le statut des ressources (ordinateurs) toutes lesdemi-heures, l aussi pour une utilisation normale.

9


Deuxime partie

La seconde partie est un ensemble de pages Web crites en PHP 2 et hbergessur un serveur Web permettant de prsenter les donnes collectes lutilisateur final.Ces pages sont de deux types : les pages publiques et les pages prives.

Les pages publiques sont accessibles par tous les utilisateurs de lUniversit ledsirant. Les pages prives, quant elles, ne sont accessibles quaux administrateurs.

Les pages publiques

Les pages publiques permettent laffichage des pages suivantes : une page contenant tous les campus et salles informatiques actuellement uti-lises ;

une page par campus avec les salles informatiques actuellement utilises ; une page par campus et dpartement avec les salles informatiques actuelle-ment utilises.

Les pages publiques offrent une vision gnrale de chaque salle : le nombre deressources totales, disponibles, occupes par un utilisateur et dans un tat inconnu. Ilest noter que chacunes des prcdentes pages peut tre affiches sur un cran plasmaprsent dans les diffrents btiments de lUniversit. La figure 2.2 donne un exemple depage publique.

Les pages prives

Les pages prives permettent laffichage des pages suivantes : une page didentification via LDAP pour ladministrateur ; toutes les pages publiques mais bnficiant de fonctionnalits supplmen-taires : liste des ressources teintes ; une fentre permettant davoir des informations sur un utilisateur actuelle-ment connect une ressource (identifiant, nom, photo, heure de connexionet dure de la session) ;

possibilit dajouter des commentaires sur les utilisateurs ; liens vers les statistiques des salles informatiques.

La figure 2.3 donne un exemple des fonctionnalits supplmentaires auxquellesun administrateur a accs.

2. Personal Home Page ou PHP : Hypertext Preprocessor

10


Vue sur le produit

Figure 2.2 Exemple de page publique de Yuukou repsentant un campus et lutilisationdes salles informatiques dun dpartement

Figure 2.3 Exemple de page prive de Yuukou montrant en particulier les donnesdun utilisateur

11


2.1.3 Quelques chiffres

Le projet Yuukou permet de surveiller le rseau du campus de New Cavendishsoit 43 salles informatiques, ce qui reprsente 661 PC. Le support des Macintosh ntantpas pris en compte.

2.1.4 Changement vers Yuukou II

LUniversit souhaite reprendre le principe du projet Yuukou, cependant elle estconfronte diffrents problmes. Le premier tant que les personnes ayant dvelopple projet ont quitt lUniversit. Ce qui signifierait, pour la personne ou lquipe quiserait en charge de reprendre le projet, de prendre du temps pour se former Perl,comprendre tout ce qui a t dj ralis et ensuite seulement, commencer dvelopper.Actuellement de nombreux projets sont en cours et il nest pas possible pour une quipede passer du temps sur lexistant.

Un autre problme est les changements importants, du point de vue infrastruc-ture, qui sont en train dtre mis en place. En effet, lUniversit qui utilisait eDirectoryde Novell pour grer ses annuaires LDAP a commenc migrer toutes ses donnes versle systme Active Directory de Microsoft qui est cens tre plus efficace. Ce changementrendrait Yuukou obsolte.

Point suivant, la volont de donner accs aux informations sur les salles, passeulement en utilisant un navigateur Internet, mais aussi et surtout en utilisant unsmartphone (IPhone ou autre par exemple) ou une tablette (IPad par exemple), choseque lancien logiciel ne peut pas fournir. De ce fait, un tudiant aurait tout momentles informations sur les salles via son smartphone ou sa tablette, si tant est quil ait lunou lautre. ces prcdents problmes, dautres viennent sajouter :

les Macintosh ne sont pas pris en compte ; le logiciel est assez monolithique, il deviendrait donc trs difficile et complexede vouloir ltendre ;

Yuukou ne prend en compte que les donnes en temps rel et ne garde pasun historique ;

son utilisation prte confusion car il na aucun interfaage avec lemploi dutemps, de ce fait, quand une salle est prsente comme libre, il ny a aucunmoyen, avec le logiciel, de savoir si un cours sy droule ou non.

Cest en considrant tous ces points quil a t dcid dabandonner le pro-jet Yuukou afin de pouvoir mettre en place Yuukou II qui rpondrait aux attentes delUniversit.

12

Le projet Yuukou II Prsentation du sujet

2.2 Le projet Yuukou II

Yuukou II a pour but de combler les lacunes de Yuukou et daller plus loin entermes de fonctionnalits quil peut offrir. Le projet sera tout dabord prsent avec lesprincipaux points le composant. Ensuite seront abordes les diffrentes rflexions que lesquipes intresss par le projet ont effectues. Ces rflexions donneront lieu aux premiresides qui en ont merges. Enfin, les principales contraintes techniques du projet serontdcrites.

2.2.1 Prsentation du projet

Dans son fonctionnement gnral, Yuukou II doit permettre de donner untudiant ou toute personne travaillant lUniversit et cherchant utiliser un ordinateur,une vue globale des ressources qui sont disponibles actuellement. Les donnes devant trebien sr exactes afin que la personne nait pas de mauvaise surprise en se rendant dansune salle quelle pensait libre. Laffichage pourra se faire via un smartphone, une tabletteou encore un navigateur Internet.Le but du stage est :

la conception dun logiciel permettant la rcupration de donnes concernantles connexions sur les diffrentes ressources de lUniversit et cela en tempsrel ;

la gestion de la persistance de ces donnes ; la cration dun maximum de fonctionnalits retournant les informationsutiles dans le but dtre exploites pour laffichage sur les diffrents supports.

La cration dapplications permettant laffichage des rsultats ne fait pas partiede ce sujet de stage. Ici, seule la partie rcupration, stockage et retour des donnes estaborde.

2.2.2 Rflexions de lquipe technique

Diffrents acteurs de lUniversit intresss dans le projet Yuukou II ont com-menc fixer une liste des fonctionnalits quils aimeraient voir avec lapplication finale.

Concernant les ressources

Macintosh et Windows ; connatre ltat de la ressource, ventuellement la dmarrer distance(WOL 3) ;

inclure une surveillance partielle du matriel et des logiciels ;

3. Wake On Lan

13


utilisation des services dActive Directory.

Concernant les donnes rcupres

mettre au point un formalisme avec les autres services de lUniversit concer-nant les informations sur les salles, campus et dpartements ;

stocker les informations dans une base de donnes SQL 4 ; mettre en place des outils pour gnrer des statistiques partir des donnesstockes (utilisation dune salle, nombre de connexions par jour dans un moispour une salle, . . .).

Concernant les donnes retournes

gnration de flux RSS 5 pour retourner des informations ; laffichage doit tre en temps rel et doit aussi permettre davoir une vueglobale dans le temps : utilisation des emplois du temps pour savoir quellesalle est libre et quel moment.

Cette liste nest pas complte tant donn quelle ne prend pas en compte lapartie affichage des rsultats du fait que le projet ne consiste qu la rcupration,au traitement et au retour de donnes.

Lide initiale tait de dvelopper un projet pilote qui permettrait davoir unevue sur ce quil est possible de faire et sur la faon de le faire. Il serait ensuite reprispar les quipes de lUniversit pour tre termin. Ce projet consisterait en la crationdun service Web (la notion sera explique plus en dtail au 3) crit en C# et utilisantle framework .Net de Microsoft. Le service Web devra offrir un maximum de fonction-nalits et tre exploit par une application mobile pour smartphone et par un site Webpouvant tre projet sur les crans plasma lentre de chaque site.

Cependant, aprs rflexion avec M. Thierry DELAITRE, la structure, les ob-jectifs et le projet en gnral ont t revus. Dans lide initiale, pour connatre ltatdune ressource, si elle est teinte ou allume par exemple, il aurait fallu interroger Ac-tive Directory. De plus, nest connu que ltat si un utilisateur est connect. Il faudraitdes traitements supplmentaires pour pouvoir fixer prcisement ltat dune ressource,avec un ping par exemple pour savoir si la ressource est teinte ou non.

2.2.3 Premires approches

Une solution simple, rapide et fonctionnelle avait dj t mise en place afinde monitorer , cest--dire surveiller le fonctionnement des diffrentes ressources decertaines salles dans lUniversit. Nagios est une application permettant deffectuer une

4. Structured Query Language5. Rich Site Summary

14


surveillance systme et rseau. Il permet de connatre ltat dune machine ainsi quedautres informations comme le systme dexploitation utilis, la version de Java instal-le, la charge du processeur, . . .

En partant de ce logiciel, le projet consiste en la rcupration des donnesde Nagios, leur traitement et le dveloppement des fonctionnalits permettant uneapplication extrieure de pouvoir afficher les informations.Les objectifs principaux deviennent les suivants :

cration dun service Web en utilisant lAPI 6 Java JAX-WS 7 ; mise en place dune mthode de communication avec Nagios ; cration de la base de donnes permettant larchivage ; mise en place dun cycle permettant de traiter les informations rcupres ; dfinition de fonctions utiles pour une application cliente ; choix dune structure de retour des informations pour une application cliente ; faire un lien avec lemploi du temps des diffrentes salles sous surveillance.

2.2.4 Contraintes techniques

Deux des principales contraintes du cahier des charges sont lutilisation de lo-giciels libres et du langage de dveloppement Java, tout en me laissant un maximum delibert dans les autres choix.

Durant le stage, un ordinateur ma t fourni avec un libre choix sur le sys-tme dexploitation. De ce fait jai opt pour un Linux Mint 11 nomm Katya, que jailhabitude dutiliser.

Un autre ordinateur, lui contenant un Debian 6.0.5 nomm Squeeze, a t mis ma disposition en tant que serveur distant hbergeant le service Web ainsi que lesdiffrents outils ncessaires son fonctionnement. Le serveur distant contient le logicielNagios, le serveur Web permettant de faire fonctionner la dernire version stable duservice Web ainsi que le systme de gestion de bases de donnes (SGBD).

Les tests tant en premier lieu raliss en local sur la machine de dveloppementet ensuite, quand le fonctionnement tait garanti, lapplication tait dploye sur leserveur distant. Des renseignements supplmentaires seront apports au 4.5.1.

6. Application Programming Interface7. Java API for XML Web Services

15

3 La notion de service Web

Le projet repose donc sur la cration dun service Web. Son but tant de mettre disposition dun client, des mthodes retournant des informations pour quelles soienttraites et affiches. Cest pourquoi la notion de service Web sera explique dans un pre-mier temps. Une dfinition sera donne ainsi quune architecture basique et la faon dontfonctionne un service Web. Puis, dans un deuxime temps, une prsentation de lAPIutilise, JAX-WS, pour le dveloppement du service Web sera faite. Elle permettra dedonner un aperu des mthodes de dveloppement dun service Web.

3.1 Service Web

3.1.1 Dfinition

Un service Web est une application accessible par le rseau, qui permet unclient de dialoguer avec le service Web et cela indpendamment de tout langage de pro-grammation et de toute plate-forme dexcution. Un service Web dvelopp en Javapeut donc tre accessible par un client PHP par exemple. Cest un systme de mes-sagerie standard utilisant le protocole HTTP pour communiquer travers le rseau etchangeant des fichiers XML. Son intrt resulte dans lutilisation de normes (HTTP etXML) permettant linteroprabilit des services. De plus, le fait que les services Webnimposent pas de modle de programmation spcifique permet aux vendeurs doutils dedveloppement doffrir des mthodes diffrentes et donc de facilement diffrencier leursproduits de ceux de leurs concurrents.

3.1.2 Architecture

Lorsquon parle de services Web, on parle aussi de SOA, Service-Oriented Ar-chitecture ou architecture oriente services en franais. Une architecture oriente servicesest un style darchitecture qui a pour objectif une interdpendance faible entre diffrentsagents logiciels (modules, services). Les services Web possdent trois normes principales

16

Service Web La notion de service Web

qui sont SOAP 1, WSDL 2 et UDDI 3 qui permettent respectivement de connatre la fa-on dont les messages sont changs, leurs descriptions et la faon de les dcouvrir surle rseau.

change de messages

Dans la grande majorit des services Web, le protocole principal de communi-cation est SOAP. Il offre le transport dobjets srialiss (objets reprsents par un fluxdoctets) et autres donnes en XML, et lappel de procdures distantes.

Description dun service Web

Un service Web est dcrit par un document WSDL. Cest un langage de des-cription bas sur XML qui permet de donner de faon prcise les dtails concernant leservice Web :

son protocole de communication utilis ; le format de messages requis pour communiquer avec lui ; les mthodes que le client peut utiliser ; sa localisation.

Un fichier WSDL permet ainsi de savoir comment communiquer avec le service Web.

Dcouverte dun service Web

Pour utiliser un service Web, il faut savoir sil existe. UDDI est une norme quidfinit le mcanisme pour dcouvrir dynamiquement des services Web. Cest en fait unannuaire de services permettant de localiser sur le rseau le service Web demand. Ilcomporte :

des pages blanches, liste des entreprises ainsi que les informations les concer-nant ;

des pages jaunes, liste des services Web de chacunes des entreprises sous leformat WSDL

des pages vertes, liste des informations techniques prcises sur les servicesfournis.

1. Simple Object Access Protocol2. Web Services Description Language3. Universal Description, Discovery and Integration Service

17

Service Web La notion de service Web

3.1.3 Fonctionnement

Le fonctionnement des services Web sarticule autour de trois acteurs principauxillustrs par la figure 3.1.

Figure 3.1 Fonctionnement des services Web

Les tapes impliquant la mise disposition et lutilisation (consommation) dunservice Web sont les suivantes :

1. le service Web dcrit son service en utilisant WSDL ; cette dfinition est publiedans lannuaire UDDI ;

2. le client envoit une ou plusieurs requtes afin de localiser le service Web lannuaireet de dterminer comment communiquer avec ce service ;

3. une partie du fichier WSDL fourni par le service Web est pass au client. Le clientpeut maintenant savoir quelles requtes et rponses envoyer au service Web ;

4. le client utilise le fichier WSDL pour envoyer une requte au service Web ;5. le service Web fournit la rponse attendue au client.

18

LAPI JAX-WS La notion de service Web

3.2 LAPI JAX-WS

Java API for XML Web Services (JAX-WS) est une API Java permettantde simplifier la cration, le dveloppement et le dploiement de services Web clients etde services Web prestataires. Il fonctionne avec un systme dannotations spcifiquesdu code Java. JAX-WS fait partie de la plate-forme Java EE 4 de Sun Microsystems.Anciennement appele JAX-RPC 5, ce changement de nom intervient lors de labandondu style RPC 6, des appels de procdures distantes, pour des services Web de styledocument, avec une transmission de donnes au format XML dfinies dans un schmaXML.

Toute la partie communication de JAX-WS est gre avec des messages de typeSOAP travers HTTP. LAPI permet de cacher toute la complexit des messages, ledveloppeur choisit simplement la manire dimplanter le service. Pour cela, il existedeux mthodes : top-down et bottom-up.

Top-down

La mthode top-down permet de dvelopper un service Web en partant dunfichier WSDL. Ce fichier doit contenir la complte description de tout le service Web,ensuite le code Java est gnr automatiquement. Les classes doivent ensuite tre com-pltes avant dploiement.

Bottom-up

La mthode bottom-up permet, quant elle, de dvelopper un service Web enpartant du code Java. Le code Java est dune part annot, ensuite le fichier WSDL estautomatiquement gnr. Le service peut enfin tre dploy.

Choix de la mthode et exemple

Cest la mthode bottom-up qui a t employe dans le projet. Elle permet dene se soucier que du code Java, le reste tant gr automatiquement par NetBeans avecla construction du service Web et le dploiement sur le serveur GlassFish. NetBeanset GlassFish seront dcrits respectivement aux 4.1.3 et 4.1.4. Le code 3.2 donne unexemple dannotations sur un code Java.

4. Java Platform, Entreprise Edition5. Java API for XML-based RPC6. Remote Procedure Call

19

LAPI JAX-WS La notion de service Web

1 @WebService (name = " ExempleService " )2 pub l i c c l a s s ExempleService {3 @WebMethod( operationName = " a f f i c h e r " )4 pub l i c S t r ing a f f i c h e r (5 @WebParam(name = " tex t e " ) S t r ing t ex t e ){6 . . .7 }8 }

Figure 3.2 Exemple de classe Java annote avec JAX-WS

JAX-WS Reference Implementation est disponible sur son site Internet[1] enversion 2.2.6.

20

4 Le projet Yuukou II

Une fois le sujet pos et la notion de service Web comprise, plusieurs recherchesont t ncessaires afin de pouvoir commencer le projet en lui-mme. Cest seulementensuite que la phase de dveloppement a pu commencer. Le premier point traitera de laphase de recherche sur les outils et les choix qui ont t pris pour le projet. Ensuite unsecond point abordera la mthode utilise pour accder aux informations indispensablesau fonctionnement du service Web. Les deux points suivants seront consacrs au fonc-tionnement et aux fonctionnalits quoffre le service Web. Le premier de ces deux pointspermettra de dcouvrir le cycle qui permet de rcuprer les informations de Nagios et deles archiver, ainsi que les mthodes auxquelles un client peut accder pour rcuprer unepartie ou toutes les informations archives par le service Web. Le deuxime de ces deuxpoints expliquera les diffrentes fonctionnalits dont Yuukou II bnficie. Suite cela,un autre point aura pour but dexpliquer lorganisation du travail qui a t adopte toutau long du dveloppement du service Web. Une vue expliquant comment est exploit leservice Web sera faite ensuite et montrera des captures dcrans de ce qui a t ralis.Enfin, un dernier point permettra de voir les principaux problmes qui ont t rencontrslors du stage.

4.1 Recherches

Aprs avoir compris comment fonctionne un service Web, il a fallu se concentrersur les diffrents outils et la faon de les utiliser afin de dvelopper le projet. La rflexionse portera dabord sur une architecture du projet dont le but est de se faire une ide decomment toutes les pices peuvent sarticuler les unes avec les autres. Ensuite il sera faitune description des outils utiliss durant le projet. Enfin les choix techniques oprs lorsdu stage seront dcrits.

4.1.1 Architecture du projet

Le premier travail a t la rflexion propos de la mise en place dune solu-tion pouvant communiquer avec Nagios dont une description sera faite au 4.1.2. Lesfigures 4.1 et 4.2 prsentent le fruit des recherches qui ont t faites sur la mise en place

21

Recherches Le projet Yuukou II

du projet Yuukou II.

Figure 4.1 Architecture du projet, partie service Web

Figure 4.2 Architecture du projet, partie affichage

Partie service Web

Basiquement, Nagios sert surveiller les ressources auxquelles il lui est permisdaccder. De ce fait, il doit garder des traces des informations quil rcupre. Ces infor-mations sont stockes dans un fichier. Cependant, il existe un module qui est directement

22


intgr dans le processus de fonctionnement de Nagios et qui offre une grande rapiditdans lenvoi dinformations. Le module MK Livestatus permet, laide dun langage derequtes qui lui est propre, de rcuprer les informations que garde Nagios.

Le service Web doit permettre, dans un premier temps, de rcuprer toutes lesinformations utiles pour un archivage des donnes. Elles seront ensuite stockes dansune base de donnes MySQL. Ces informations sont :

les donnes rcupres via le module MK Livestatus, la rcupration doit trefaite intervalles rguliers ;

les diffrents emplois du temps de toutes les salles que Nagios surveille, larcupration doit tre faite une fois par jour ;

les donnes sur un utilisateur inconnu (nom, prnom, rle : tudiant parexemple, photo) via un serveur LDAP.

Partie affichage

Dans un deuxime temps, le service Web doit pouvoir retourner ces informationstries un utilisateur normal ou un administrateur afin de garantir laffichage sousla forme dune application mobile ou dune interface Web. La rflexion doit ainsi seporter sur le contenu des diffrentes mthodes auxquelles un utilisateur pourra avoiraccs (en fonction quil soit administrateur ou non). Le but tant un affichage le plusrapide possible des informations demandes.

Lutilisateur doit sauthentifier via un Servlet qui communique avec LDAP etqui donne un accs lapplication. Le reste de la communication sera scurise commeexpliqu dans le 4.4.1.

Le dernier point est de choisir un format pour les donnes qui seront changesentre le service Web et lapplication cliente.

Cest sur la partie affichage que Yacine MAGHEZZI est intervenu durant sonstage.

4.1.2 Nagios

Figure 4.3 Logo de Nagios

23


Prsentation

Nagios est une application permettant la surveillance systme et rseau de touteune infrastructure informatique. Nagios complte cette surveillance en offrant la possi-bilit dalerter les quipes en charge de linfrastructure en cas dapparition de problmescomme une panne ou encore un fonctionnement anormal. Cest actuellement la solutionde surveillance la plus efficace du march.

Nagios a t cr en 1999 et portait initialement le nomde NetSaint Network Monitor. Il est crit en C et est conu pourun environnement Unix. Le projet a t maintenu jusquen 2002avant de changer de nom pour devenir Nagios en rponse unecontestation judiciaire par les propritaires dune marque similaire.N.A.G.I.O.S. est lacronyme rcursif de Nagios Aint Gonna Insist

On Sainthood o Sainthood est une rfrence NetSaint.Maintenant connu sous le nom de Nagios XI, Nagios est un logiciel libre sous

la licence GNU GPL V2. Il est disponible sur son site Internet[2] en version 3.2.1.

Fonctionnement

Larchitecture de base de Nagios est trs simple, elle comporte : un ordonnanceur pour grer les vrifications ainsi que les actions prendresur les diffrents incidents ;

une partie graphique : visible travers un simple serveur Web ; des sondes : greffons (ou plugins en anglais) dans Nagios, ce sont de petitsscripts permettant deffectuer diverses vrifications.

la base, Nagios est un moteur dordonnancement de vrifications diverses etvaries dont les vrifications sont effectues via des greffons. Ces vrifications peuventtre la charge dutilisation du CPU 1, lespace disque utilis ou encore les utilisateursactuellement connects. Dans le cadre de la vrification de linfrastructure, deux typesde machines sont observes : les ordinateurs dots de Windows et les ordinateurs dotsde Macintosh.

Nagios tant install et fonctionnel depuis un peu plus dun an sur le site deNew Cavendish, les greffons pour observer les deux types de machines ont dj t d-velopps. Pour les machines fonctionnant sous Windows, le greffon est en fait lappel la commande Unix winexe qui permet lexcution de commandes distance sur des ma-chines Windows. Pour les machines fonctionnant sous Macintosh, le greffon effectue uneconnexion SSH 2, offrant une connexion scurise sur une machine distante pour ensuiteexcuter la commande Unix who permettant lobtention de lutilisateur connect. Pour

1. Central Processing Unit ou processeur en franais2. SecureShell

24


les machines bnficiant dun double boot (dun dmarrage de lordinateur permettant dechoisir entre deux systmes dexploitation) Windows-Unix, seul le systme Windows estsurveill. La configuration actuelle de Nagios ne permet pas de rcuprer avec exactitudelutilisateur connect sur le systme Unix. Il est juste possible de savoir que lordinateurest occup, mais pas par qui.

La configuration de Nagios sarticule entre diffrents concepts : les hosts, leshostgroups et les services. Un host reprsente un ordinateur, cet ordinateur possde desservices comme le service check_whoisloggedin permettant de savoir si un utilisateur estactuellement connect sur ladite machine. Ces services sont donc les greffons de Nagios.Les hosts font enfin partie dun groupe dordinateurs hostgroups qui reprsente une salleinformatique au sein de lUniversit.

Monitoring lUniversit

Initialement, Nagios surveillait juste les machines se situant sur le campus deNew Cavendish, soit 31 salles PC, soit environ un peu plus de 600 machines. Actuelle-ment, ce sont 102 salles qui sont sous la surveillance de Nagios, soit 99 salles utilisantWindows soit 1920 PC, 3 salles utilisant des Macintosh soit 63 MAC, pour un totalde 1983 machines travers toute lUniversit. Cela reprsente la grande majorit desordinateurs de lUniversit. Il faut noter que seuls les Macintosh de New Cavendish sontsous surveillance, les autres ncessitant dtre lists et des accs diffrents. De ce fait, lenombre de machines devrait augmenter par la suite.

Vue sur la surveillance de Nagios

Les figures 4.4 et 4.5 donnent un aperu de linterface graphique de configurationmais aussi de suivi de Nagios. La figure 4.4 offre une vue densemble sur tous les hostsappartenant tous les hostgroups surveills. La figure 4.5, quant elle, offre une vuepour un hostgroup spcifique : la salle pourtant le nom e-cg24.

25


Figure 4.4 Exemple daffichage de Nagios, vue sur tous les hostgroups

Figure 4.5 Exemple daffichage de Nagios, vue sur tous les hosts dun hostgroupspcifique

26


4.1.3 LIDE NetBeans

Figure 4.6 Logo de NetBeans

NetBeans est un IDE 3 open source dvelopp par Sun Microsystems permet-tant le dveloppement en utilisant les langages de programmation tels que Java, JavaS-cript, PHP, C, C++, et autres. Il est crit en Java et fonctionne sous Windows, MacOS, Linux, Solaris et dautres plates-formes du moment quelles possdent une JVM 4compatible.

NetBeans permet de dvelopper et dployer rapidement des applications gra-phiques Swing, des Applets, des JSP/Servlets et des architectures J2EE 5. Il possdetoutes les fonctionnalits recherches dans un IDE moderne (coloration syntaxique, re-factoring, dbogueur, . . .) et ajoute, dans le cas dun dveloppement dun service Webcomme pour ce projet, un support avec la dernire version de GlassFish, permettant no-tamment de faire des deploy on save , de dployer les applications Web sur un serveurdistant et de contrler le serveur (suivre la sortie de logs, dmarrer, arrter le serveur).Il donne accs une gestion simple du serveur dapplication GlassFish qui sera utilisdans le projet. Sa premire version date de 1996 et portait le nom Xelfi. Il est disponiblesur son site Internet[3] en version 7.1.2.

4.1.4 Le serveur Web GlassFish

Figure 4.7 Logo de GlassFish

GlassFish est un serveur dapplication open source dvelopp par Sun Micro-systems pour les plates-formes Java EE 5 et 6, et est maintenant maintenu par OracleCorporation. Il dispose de nombreux outils pour faciliter le dveloppement, le dploie-ment et la maintenance dapplication. Un de ses avantages est quil est particulirement

3. Integrated Development Environment4. Java Virtual Machine5. Java Platform, Enterprise Edition

27


bien intgr NetBeans, ce qui permet un dploiement trs rapide des applications ainsiquune trace dexcution lors du fonctionnement. GlassFish est disponible sur son siteInternet[4] en version 3.1.2.

4.1.5 Le SGBD MySQL

Un des objectifs du projet Yuukou II est un archivage temporel des donnes. Lebut tant de gnrer des statistiques dutilisation des salles informatiques des diffrentscampus par exemple.

Figure 4.8 Logo de MySQL

MySQL est le Systme de Gestion de Base de Donnes (SGBD) le plus po-pulaire qui fonctionne comme un serveur fournissant un accs multi-utilisateurs desbases de donnes de type SQL. Il a t cr par MySQL AB en 1995, rachet par SunMicrosystems et est maintenant maintenu par Oracle. Il prsente les avantages dtreopen source, gratuit, fiable, rapide et facile utiliser. Il est trs souvent utilis avec lelangage de cration de pages Web dynamique PHP. Cest donc avec cet outil que lesdonnes de Yuukou II seront archives. MySQL est disponible sur son site Internet[5] enversion 5.5.24.

4.1.6 Laccs aux donnes des tables

Par souci de performance, cest--dire, limiter les accs multiples la base dedonnes mais aussi faciliter la manipulation des donnes lors des traitements, le designpattern Data Access Object (DAO) a t utilis. Un Data Access Object, ou objet daccsaux donnes en franais, est un objet qui constitue une reprsentation en mmoire desdonnes dune base de donnes. En Java, un DAO est une classe reprsentant une tabledont les attributs sont les champs de la table comme le montre la figure 4.9. Des classesreprsentant des listes sont gnralement dveloppes pour contenir les DAO et simplifierlaccs aux donnes.

28


Lorsquil sera ncessaire deffectuer des traitements rpts sur les donnesdune table, mme si ces traitements ne portent pas sur la totalit de la table, il estprfrable de charger en mmoire la totalit des lments utiles avec, dans le cas idal,une seule requte SQL.

Figure 4.9 Exemple de mapping dune table avec sa classe DAO associe (source :Cyrille Herby)

Dans le cadre du projet, les chargements sont effectus lorsquun client appelleune mthode du service Web. Les donnes sont charges dans une liste, elles sont ensuitetraites puis retournes au client.

4.1.7 Gestion de la base de donnes

La base de donnes a volu tout au long du projet en fonction des fonctionna-lits qui ont t demandes. Lannexe C permet davoir une description des diffrentestables composant la base de donnes, une vue gnrale de ce quoi elle ressemble, etdes vues dcoupes des diffrentes parties.

La base de donnes peut tre dcoupe en diffrentes grandes parties. La partiearchivage a pour but de conserver les donnes dans le temps. Pour ce faire, elle estcompose de deux tables centrales de sauvegarde dinformations. La premire est latable yuukou_who, son but est de simuler la commande UNIX who. Cette commandepermet de donner tous les utilisateurs connects sur la machine o elle est excute. Dece fait, si elle est porte au niveau de Nagios et du projet, la table contiendra tous lesutilisateurs connects sur un ordinateur et depuis quand ils le sont. La deuxime table estyuukou_last, son but est aussi de simuler une commande UNIX, la commande last. Cettecommande permet de donner la liste de tous les derniers utilisateurs sur la machine surlaquelle elle est excute. De ce fait, si elle est porte au niveau de Nagios et du projet,la table contiendra toutes les connexions des utilisateurs sur un ordinateur, lheure de

29


dbut et de fin et la cause de la dconnexion. En fait, elle contiendra les donnes de latable yuukou_who et ajoutant les informations du temps de fin de connexion et la causede la dconnexion.

La partie logicielle a pour but de stocker la configuration logicielle de chaquesalle informatique. La rcupration de cette configuration est explique au 4.4.4.Cette partie est compose de plusieurs tables. Une salle informatique peut avoir desgroupes de logiciels, yuukou_rooms_groups et aussi des logiciels indpendants de toutgroupe, yuukou_rooms_software. Un groupe de logiciels contient des logiciels, yuu-kou_groups_software. Les descriptions des groupes et logiciels sont contenues dans lestables yuukou_groups et yuukou_software. Avec ces tables, il est possible de facilementreconstruire la configuration logicielle dune salle.

La partie emploi du temps a pour but de stocker tous vnements des diff-rents emplois du temps de lUniversit. La rcupration de cette configuration est ex-plique au 4.4.3. Cette partie est compose de trois tables. La premire table est cellecontenant toutes les salles yuukou_rooms, la deuxime contenant tous les vnementsyuukou_timetables. Pour la dernire table yuukou_mapping_room, son rle est de faire lelien entre les noms des salles dans Nagios et les noms des salles qui sont utilises pourlemploi du temps. En effet, la gnration des emplois du temps est effectue par unservice de lUniversit. De ce fait, ce service utilise un systme pour nommer les sallesqui lui est propre. Il est donc ncessaire de pouvoir relier un vnement une salle laide de cette dernire table.

La partie mapping avec les salles a pour but de faire le lien entre une descriptioncomplte dun lieu et la description courte qui est donne dans la description dunesalle dans la table yuukou_rooms. Les informations concernant les diffrents lieux sontcontenues dans la table yuukou_mapping_location.

La dernire partie, configuration, a pour but de grer les diffrents paramtrespermettant la gestion de cycle lors du fonctionnement du service Web. Les explicationsconcernant ce quest un cycle se trouvent au 4.3.1.

4.1.8 Le format de retour

Le choix du type de retour est un choix important. En effet, il faut que lesdonnes puissent tre rapidement transmises, rcupres, traites et affiches. Lobjectifest un affichage instantan des pages sur le navigateur Web ou lapplication mobile. Dece fait, plusieurs possibilits ont t envisages.

Parsing dun texte

La premire est de transmettre un document texte basique, celui-ci formatdune certaine faon afin dtre pars (cest--dire parcourir un flux structur dinfor-mations pour en extraire les donnes). Ce qui aurait comme avantage de pouvoir tre

30


rcupr par un client utilisant nimporte quel langage. La figure 4.10 reprsente unexemple de fichier quil est facile de parser, il suffit de rcuprer les informations setrouvant entre les arobases.

1 i n f o 1 @ in f o 2 @ in f o 3 @ in f o 4

Figure 4.10 Exemple de ligne pouvant tre facilement parse

Cependant cette mthode est assez contraignante et oblige parcourir len-semble du fichier alors quun seul type dinformation peut tre utile. Ce qui signifie uneperte de temps plus ou moins significative en fonction de la taille du fichier reu.

Objet Java srialisable

Une autre mthode pourrait tre de transmettre un objet Java dit srialisable.La srialisation est un mcanisme fourni par Java permettant de considrer un objetcomme une squence doctets qui inclut les donnes de lobjet, le type de lobjet et letype des donnes. De cette manire, lobjet en question peut tre transmis traversle rseau vers une autre application Java pour le rcuprer et le dsrialiser, ce quireprsente la procdure inverse de la srialisation. La figure 4.11 donne un exemple declasse Java srialisable qui pourrait tre transmise par le rseau comme un flux de bytes.

1 pub l i c c l a s s Exemple implements S e r i a l i z a b l e {2 pub l i c S t r ing cha ine = " He l lo " ;3 pub l i c i n t i = 0 ;4 }

Figure 4.11 Exemple de classe Java srialisable

Lobjet contiendrait toutes les donnes utiles et celles-ci seraient facilementaccessibles. Le problme venant avec cette solution est que les objets doivent tre r-cuprs par une JVM. Ce qui peut savrer plus ou moins compliqu voire impossibledans dautres langages de programmation que Java.

XML

eXtensible Markup Language ou XML est un mta-langage pour raliser dubalisage gnrique permettant de mettre en forme des documents. XML a connu ungrand succs depuis sa cration. Il est utilis en particulier pour grer la configuration,le stockage des donnes, lchange dinformations et bien dautres fonctions encore. La

31


figure 4.12 donne un exemple de document XML pouvant tre facilement converti enune arborescence DOM.

1 2 3 4 5 6 7

Figure 4.12 Exemple de document XML

XML offre une solution structure et trs simple comprendre pour lenvoidinformation par le rseau, cependant, dans les changes dinformations entre client etserveur, il montre ses limites :

le chargement et la manipulation deviennent vite compliqus, la plupart dutemps, il est ncessaire de parser le XML sous forme de DOM, puis de leparcourir, ce qui requiert lappel de nombreuses fonctions, sans mentionnerle fait que parser un document XML est parfois long ;

la taille des fichiers changs peut parfois tre consquente du fait de laduplication des donnes : par nature, le XML ne permet pas de grer unenorme masse dinformations.

JSON

JavaScript Object Notation ou JSON est un format lger dchange de donnestextes. Il utilise la notation des objets JavaScript pour transmettre de linformationstructure. Il est aussi souvent utilis pour simplifier et allger les accs des servicesWeb depuis les navigateurs. La figure 4.13 donne un exemple de fichier JSON reprenantle mme arbre que le document XML de la figure 4.12.

32


1 { "Menu" :2 { " id " : " f i l e " ,3 " va lue " : " F i l e " ,4 "Commands" : {5 "MenuItem" : [6 { " value " : "New" , " a c t i on " : " CreateDoc " } ,7 { " value " : "Open" , " a c t i on " : "OpenDoc " } ,8 { " value " : " Close " , " a c t i on " : " CloseDoc " }9 ]

10 }11 }12 }

Figure 4.13 Exemple de fichier JSON

JSON offre lavantage dtre indpendant du langage utilis, il est lger et simple utiliser. Cest un langage dchange idal pour beaucoup dapplications.

Choix du format

Le choix du format de retour des donnes sest port sur lutilisation de JSON.Le but du client, qui demande des informations au service Web, est de recevoir lesdonnes le plus rapidement possible afin de pouvoir les afficher dans la foule. De cefait, le parsing dun texte contenant des balises certains endroits savre inadapt,notamment pour rcuprer un seul type dinformation. Lenvoi dun objet srialisableJava est, quant lui, trop restrictif. Le choix a donc t entre XML ou JSON.

XML offre un format de donnes verbeux et prend beaucoup despace. De plus,un document XML peut tre valid via lutilisation de DTD 6, document permettant dedcrire un modle de document XML, ou de XML Schema, langage de description deformat de document XML permettant de dfinir la structure et le type de contenu dundocument XML.

JSON offre un format de fichier plus simple que XML, facilement comprhen-sible. Pour complter, les fichiers JSON, arbre gal, seront toujours plus petits quelquivalent XML et prsenteront lavantage dtre plus rapidement parss.

Au final JSON permet une plus grande rapidit dans les changes avec unserveur ainsi que sur le temps de parsing des fichiers, le tout avec une conomie desressources du fait de sa petit taille. Cependant, les donnes ne peuvent pas tre vrifiesdans un fichier JSON, il demande donc une certaine rigueur dans son criture du cotserveur ainsi quune connaissance de sa structure du cot client.

6. Document Type Definition

33


4.1.9 Complment dinformation sur JSON

Prsentation

Une courte description de ce quest JSON a dj t faite au 4.1.8. Pourreprendre ce qui a dj t dit, JSON est un format lger dchange de donnes quiest apparu en 2002. Il est facile crire et comprendre pour des humains. Il est fondsur un sous-ensemble du langage de programmation JavaScript et est compltementindpendant de tout langage, tout en possdant des conventions familires aux langagesdescendant du C (C++, C#, Java, JavaScript, . . .). Ces proprits font de JSON unlangage dchange de donnes idal.

Cependant, il ne supporte pas les espaces de noms au contraire dXML. Pourla vrification des donnes, les schmas JSON ne sont pas trs utiliss du fait quilsdoivent tre crits la main comme il nexiste aucun outil pour gnrer un schma partir de donnes JSON. Et concernant la scurit, il existe la possibilit o des scriptsmalveillants pourraient tre dissimuls et excuts. Il existe des fonctions pour tester lesfichiers JSON mais celles-ci ne sont pas vraiment concluantes. La meilleure dfense estde connatre lavance les points sensibles et de prendre les prcautions ncessaires.

Structure

JSON se base sur deux structures de donnes universelles dans pratiquementtous les langages de programmation modernes :

une collection de couples nom/valeur ; une liste de valeurs ordonnes.

Ces lments reprsentent trois types de donnes : un objet :

Ensemble de couples nom/valeur non ordonns. Un objet commence par "{"(accolade gauche) et se termine par "}" (accolade droite). Chaque nom est suivide " :" (deux-points) et les couples nom/valeur sont spars par "," (virgule) ;

un tableau :Collection de valeurs ordonnes. Un tableau commence par "[" (crochetgauche) et se termine par "]" (crochet droit). Les valeurs sont spares par ","(virgule) ;

une valeur :Soit une chane de caractres entre guillemets, soit un nombre, soit true ou falseou null, soit un objet, soit un tableau. Ces structures peuvent tre imbriques ;

une chane de caractres :Suite de caractres Unicode (zro ou plus), entre guillemets, et utilisant leschappements avec antislash. Un caractre est reprsent par une chane dunseul caractre.

34

Communication avec Nagios Le projet Yuukou II

4.2 Communication avec Nagios

Nagios offre la surveillance dun grand ensemble de machines dans lUniversit.Cependant sil ny a aucune manire de rcuprer ces informations, il naurait aucuneutilit de son utilisation dans le projet. Ainsi un module existe et son but est de pouvoirinterroger Nagios et obtenir ses rponses le plus rapidement et simplement possible.

4.2.1 Le module MKLivestatus

Le module MKLivestatus permet un accs immdiat au statut de Nagios ainsiqu ses donnes de logs. Avant le module, une faon classique de rcuprer les informa-tions importantes tait de parser le fichier status.dat, qui est cr automatiquement parNagios chacun de ses cycles. Ce fichier contient toutes les informations concernant lesservices et les machines que Nagios surveille. Parser ce fichier savre dlicat, surtoutpour extraire quelques informations. Il existe bien une manire alternative de rcuprerces informations avec le module NDO. Ce module est directement charg dans le proces-sus de Nagios et chaque nouveau cycle, il envoie les mises jour via une socket UNIX un processus auxiliaire qui se charge de mettre jour une base de donnes.

Les avantages tant une mise jour immdiate de linformation et une simplicitet rapidit daccs aux bases de donnes pour les applications. Mais dun autre cot, lamise en place de ce systme est complexe, elle ncessite une administration humaine dela base de donnes, la consommation CPU est significative juste pour garder la base jour et son entretien rgulier peut bloquer Nagios pendant un moment (cela dpend dela taille de linfrastructure).

Le module MKLivestatus reprend le principe de NDO dans lintgration directedans le processus Nagios, cependant, la diffrence de taille est quil ouvre juste une socketde communication par laquelle les donnes peuvent tre retournes la demande. Lasocket ouverte par dfaut par MKLivestatus est une socket UNIX, mais il est possiblede configurer une socket Internet classique sur un port choisi et accessible seulement parcertaines machines. Par cette socket, il est possible denvoyer une requte vers une ciblespcifique comme un service, une machine, un ensemble de machines, . . . La rponseest immdiate et les donnes renvoyes ont t directement lues dans les structures dedonnes internes de Nagios.MKLivestatus offre donc de nombreux avantages :

consommation CPU non mesurable, juste une petite consommation lors delexcution dune requte ;

pas dcritures sur le disque ; accs aux donnes beaucoup plus rapide quavec un parsing du fichier sta-

tus.dat ou lexcution de requtes SQL. pas de configuration, dadministration ou autre, tout est install automati-quement.

35


MKLivestatus est disponible sur le site Internet[6] de Mathias Kettner en ver-sion stable 1.1.12p7.

4.2.2 Requtes pour Nagios

criture des requtes avec LQL

LQL, Livestatus Query Language, prononc Liquel , est un langage spciale-ment conu pour communiquer avec le module MKLivestatus via une socket. Il ressembleun peu au langage SQL.Chaque requte consiste en :

une commande commenant par le mot cl GET suivit du nom de la table ; un nombre arbitraire de lignes den-tte consistant en un mot-cl, un double-point et une liste darguments ;

une ligne vide ou une fin de transmission (pour fermer la procdure denvoisur la socket).

Tous les mots-cls sont sensibles la casse. La version actuelle de Livestatusdonne accs seize tables dont voici les principales :

hosts : les htes surveills par Nagios ; services : les services de Nagios, relis avec toutes les donnes de la tablehosts ;

hostgroups : les groupes dhtes crs dans Nagios ; servicegroups : les groupes de services crs dans Nagios.

Les requtes peuvent aussi tre affines avec la slection de certaines colonnes,la cration de filtres sur les rsultats (tous les rsultats dont la valeur est gale deux),compter des rsultats, faire des comparaisons avec des expressions rgulires, . . . Aufinal, LQL savre trs flexible dutilisation. La figure 4.14 donne un exemple de requtepermettant de rcuprer tous les services avec leur tat actuel 2.

1 GET s e r v i c e s2 Columns : host_name d e s c r i p t i o n s t a t e3 F i l t e r : s t a t e = 2

Figure 4.14 Exemple de requte LQL

Les scripts Nagios utiliss tout au long du stage sont disponibles en annexe Ade ce rapport.

36


Excution des requtes

Comme pour une base de donnes SQL, toutes les tables possdent un nombrede colonnes. Si une requte est passe sans paramtres, toutes les colonnes seront retour-nes dans lordre alphabtique.

Comme vu au 4.2.1, il existe deux manires daccder la socket de MKLi-vestatus. La premire mthode est avec une socket UNIX. Pour ce faire, MKLivestatusfournit pendant son installation un petit utilitaire appel unixcat permettant de commu-niquer avec une socket UNIX. Sous forme dune commande shell, cet utilitaire envoittoutes les donnes lues par lentre standard (stdin) la socket et crit sur la sortiestandard (stdout) tout ce quil reoit de la socket. Voici un exemple dexcution enutilisant la commande unixcat :

echo GET hosts | unixcat /var/lib/nagios/rw/live.

La seconde manire consiste en louverture dune socket Internet sur un portprdfini. Avec cela, il est possible daccder depuis le rseau de lUniversit au serveurhbergeant Nagios. Il suffit ensuite denvoyer via la commande UNIX netcat, qui permetdouvrir des sockets serveurs et clientes, un fichier contenant la requte LQL :

cat requete | netcat yuukou-ws.wmin.ac.uk 6557.

Dans le cadre du projet, lutilisation dune socket UNIX en Java ncessite lins-tallation de bibliothques de type JNI 7. Ce sont en fait des bibliothques qui permettentlintgration du code crit en Java avec du code crit dans un autre langage tel le C ou leC++. Cette installation est plus ou moins complexe et ncessite une certaine configura-tion du serveur, ainsi, il est plus simple douvrir une socket Internet plutt que dessayerla configuration dune socket UNIX avec JNI. De plus, au point de vue rapidit, lavan-tage de MKLivestatus est dtre directement intgr dans Nagios, de ce fait, les requtessont traites immdiatement.

Le tableau 4.1 montre un comparatif des temps dexcution mesurs avec lacommande UNIX time pour 100 requtes. La requte de la figure A.2 se trouvant enannexe A de ce rapport a t utilise pour effectuer ces tests. Chaque rponse contient1983 lignes.

7. Java Native Interface

37


time unixcat netcatRel 1m44.462s 1m42.129s

Utilisateur 0m0.372s 0m0.432sSystme 0m0.268s 0m0.404s

Table 4.1 Comparatif des temps dexcution entre la commande netcat et la commandeunixcat

Aprs 100 requtes, il est visible quutiliser une socket UNIX, pour une excu-tion systme, est presque deux fois plus rapide que lutilisation dune socket Internet. Ce-pendant, lapplication ne ncessite pas lexcution de nombreuses requtes simultanes.Une seule sera effectue chaque cycle comme dcrit au 4.3.1. De ce fait, lutilisationdune socket Internet convient dans la rcupration des informations de Nagios et vitelinstallation de bibliothques JNI.

Rcupration de linformation

Suite lexcution de la requte, linformation est retourne par Nagios, elle estensuite parse en fonction du type de la requte et les informations sont traites. Nagiosretourne les informations sous une forme bien spcifique :

une ligne correspond une ligne de la table demande ; la ligne contient toutes les colonnes de la table ou seulement celles demandesdans la requte. Chaque colonne est spare dune autre par un " ;" (point-virgule).

Des exemples de rponses correspondant aux requtes de lannexe A sont dis-ponibles dans lannexe B.

Nagios possde sa propre faon de nommer une salle ou encore un ordinateur.Les salles dans Nagios sont nommes comme suit :

abrviation du lieunom de la salle

Les diffrentes abrviations sont dfinies dans le tableau 4.2.

38

Fonctionnement du service Web Le projet Yuukou II

Abrviation Descriptione Electronics and Computer Scienceh Harrowl Little Tichtfield Streetm Marylebonen New Cavendish Streetr Regent Streetw Wells Street

Table 4.2 Abrviations et lieux utiliss par Nagios pour nommer les salles et ordina-teurs

Ainsi, la salle 4111 se trouvant sur le campus de New Cavendish sera identifiede cette manire : n-4111.Les ordinateurs sont nomme en suivant la mme logique :

abrviation du lieunom de la salletype ordinateurnumro ordinateur

Le type dordinateur peut tre de deux type : pc si cest un PC ou mc si cestun Macintosh. Ainsi, un ordinateur se trouvant dans la salle n-4111, tant un Macintoshet portant le numro 1 sera identifi comme suit : n-4111-mc-01.

4.3 Fonctionnement du service Web

Le service Web peut se dcomposer en deux grandes parties. La premireconsiste en un cycle principal qui a pour but de rcuprer les informations de Nagios etde les traiter. La deuxime consiste en de multiples fonctions pouvant tre accessiblessoit par un administrateur, soit par un utilisateur normal et permettant le retour dunepartie des informations accumules avec le cycle principal. Le principe tant quun clientlance de multiples requtes et puisse rcuprer toutes les informations dont il a besoinet ensuite directement les afficher, sans traitements supplmentaires. Suite ces deuxgrandes parties, il sera possible dobserver la faon dont les informations sont transmises un client en utilisant JSON avec des structures par dfaut.

4.3.1 Le cycle principal

Cest en quelque sorte le moteur du projet. Il collecte des informations de Na-gios, et effectue diverses oprations sur la base de donnes pour la maintenir jour. Uncycle est lanc toutes les minutes et dure entre 5 et 7 secondes pour ajouter, retirer oumettre jour les informations sur les 1983 ordinateurs surveills par Nagios ainsi que lenombre variable dutilisateurs qui sont connects sur ces dits ordinateurs. La figure 4.15permet de voir les diffrentes tapes qui composent le cycle principal du service Web.

39


Figure 4.15 Schma du droulement du cycle principal du service Web

Dans un premier temps, la premire excution du cycle, les diffrents scriptscris en LQL sont chargs en mmoire. Ensuite, une vrification de la cohrence desdonnes contenues dans les tables permettant de grer larchivage des donnes est effec-tue. Cette vrification a pour but de sassurer quil ny a pas des donnes absurdes deconnexion : les donnes de connexion dates de plus de 6 heures pour la table yuukou_whoet les donnes de connexion dont la diffrence entre la date de dbut de connexion et la

40


date de fin de connexion est de plus de 6 heures pour la table yuukou_last. Si de tellesdonnes sont trouves, elles sont automatiquement effaces de la table auxquelles ellesappartiennent.

Ltape suivante entre dans le dbut du cycle proprement parler. Elle a pourobjectif de vrifier si des donnes de la table yuukou_last ont besoin dtre dplaces.Des explications sur la migration des donnes se trouvent au 4.4.5.

Suite cette vrification, les scripts LQL sont envoys et les informations rcu-pres sont transmises ltape de traitements des donnes Nagios.

Cette tape commence par ajouter les machines qui nexistent pas dans la basede donnes. Ensuite, ce sont les utilisateurs qui sont traits. Sils nexistent pas dans labase de donnes, une recherche LDAP est effectue pour obtenir les informations lesconcernant (nom, prnom, photo, rle). Ils sont ensuite, leur tour, ajouts dans la tablecorrespondante. Le couple ordinateur-utilisateur est ensuite ajout, mis jour ou retirdes tables darchivage. Ici aussi, si une donne de connexion dpasse les 6 heures, ellesera ignore.

Suite ce traitement, une vrification est effectue sur tous les ordinateursconnus. En effet, un ordinateur possde un statut particulier : fonctionnel, teint ou enattente deffacement. Ce statut est fix dune part avec ltape prcdente des rsultats,dautre part avec ltape actuelle. Si le statut dun ordinateur reste teint pendant unesemaine, son statut change et passe : en attente deffacement.

Une vrification des emplois du temps est ensuite effectue. Des explications surla rcupration des emplois du temps se trouvent au 4.4.3. Cette vrification a pourrle de mettre jour les donnes sur les emplois du temps de faon journalire. De cefait, tous les jours, les diffrents emplois du temps sont rcuprs automatiquement. la suite de cette dernire tape, le cycle se met en pause pendant une minute.

Diffrentes scurits ont t mises en place pour viter les appels successifs aucycle principal. En effet, quand un administrateur lance le cycle principal, il lance unprocessus annexe qui se charge deffectuer le cycle indfiniment. Le seul moyen darrterce processus ou dviter les conflits est lutilisation de la table yuukou_settings. Cettetable permet de savoir quand un cycle a t effectu pour la dernire fois et sil estou non en cours. Agir sur cette table permet donc de stopper le processus mais aussidavoir une assurance qualit sur les informations qui seront retournes par les mthodesaccessibles pour le client. Si un cycle date de 5 heures, alors il ne faut pas tenir comptedes informations retournes.

4.3.2 Les fonctions accessibles

Les fonctions publiques

Ces fonctions sont accessibles par tous les utilisateurs appartenant lUniver-sit. Elles ne retournent aucune information pouvant porter atteinte aux utilisateurs ou

41


pouvant donner accs ladministration du service Web.

healthForRoom (String idRoom) retourne toutes les informations concernant unesalle : emploi du temps, nombre dutilisateurs, description de la salle, . . . Cettefonction donne des informations dtailles sur une salle informatique ;

healthForAllRooms () retourne des informations simplifies concernant lensembledes salles surveilles, cette fonction donne une vue densemble de loccupation dessalles ;

getListRooms () retourne la liste de toutes les salles ;getSitesInformation () retourne les informations concernant les diffrents campus de

lUniversit ;getRoomsType (String typeRoom) retourne la liste des salles en fonction dun type

de machine (PC ou MAC).

Les fonctions prives

Ces fonctions sont un complment aux fonctions publiques. Elles permettentun contrle sur le cycle principal du service Web et des informations retournes pluscompltes.

launchCycle () permet de lancer le cycle du service Web ;checkConfigHealth () compare les diffrences entre la table des salles informatiques

(yuukou_rooms) et la configuration dans Nagios, et retourne les diffrences ;who () retourne la liste de tous les utilisateurs connects, sur quel ordinateur et depuis

quand (yuukou_who) ;lastDefault () retourne la table complte yuukou_last ;last (int numberDays) retourne la table yuukou_last mais pour un nombre de jours

dfinis ;searchHistoryUser (String idUser, boolean who, boolean last, int number-

Last) retourne lhistorique de connexion actuel (who) ou pass (last) dun utili-sateur, possibilit de fixer le nombre dinformations retournes ;

searchHistoryResource (String idResource, boolean who, boolean last, intnumberLast) retourne lhistorique dutilisation en cours (who) et pass (last)dun ordinateur, possibilit de fixer le nombre dinformations retournes ;

getGraphWithRequestUsingJson (String rqtLabel, String label, String start-Time, String endTime, String addToRqt, int factor) retourne un flux doc-tets contenant une image gnre partir de la frquence dutilisation des sallesinformatiques entre un temps de dbut et de fin (startTime et endTime), les don-nes servant construire le graphe sont aussi retournes. Lchelle du graphe peuttre fixe avec factor : heures, semaines, mois, annes. Il est possible de personnali-ser la requte (addToRqt), de personnaliser la lgende (label) et de choisir llmentrecherch (rqtLabel) ;

42


healthResourcesReportForAllRooms () retourne ltat des ordinateurs de toutesles salles informatiques surveilles ;

healthResourcesReportForRoom (String idRoom) retourne ltat des ordina-teurs dune salle spcifique ;

actualiseLDAPInfo () permet dactualiser les donnes LDAP des utilisateurs quisont inconnus dans la base de donnes ;

isCycleRunning () donne ltat du cycle, sil est en cours ou non ;askMaintenance () si le cycle nest pas en cours, modifie la table de configuration pour

stopper le cycle sa prochaine itration. Tout lancement de cycle est impossibleensuite ;

endMaintenance () met fin la maintenance, le cycle peut ensuite tre relanc ;isMaintenanceScheduled () permet de savoir si une maintenance est en cours ou non.

4.3.3 Retour des fonctions

tant dans un cadre de travail collaboratif comme expliqu au 4.5.2, il estncessaire dadopter de la rigueur dans le retour dinformation. Encore plus du fait quenJSON, le fichier ne peut pas tre vrifi comme un fichier XML et son schma. Cestpourquoi, deux manires spcifiques ont t choisies pour retourner les informations : lecas o les informations ont t correctement transmises et le cas o elles ne lont past. Des exemples de retours concrets sont disponibles en annexe D.

Retour de fonction pour une excution correcte

La structure dun retour dune fonction suit toujours le mme schma. Le boutde code JSON 4.16 montre un exemple de structure de retour lorsquaucune erreur nestdtecte pendant lexcution dune mthode du service Web.

1 { " JSONState " : "OK" ,2 " JSONMaintenance " : "NO" ,3 " JSONLastCycle " : " 20120528 17 : 59 : 36 " ,4 " JSONContents " : . . .5 }

Figure 4.16 Structure gnrale de retour de fonction JSON sans erreur

Retour de fonction pour une excution incorrecte

Le bout de code JSON 4.17 montre un exemple de structure de retour lorsquuneerreur est dtecte pendant lexcution dune mthode du service Web.

43

Fonctionnalits en place Le projet Yuukou II

1 { " JSONState " : "KO" ,2 " JSONReason " : " Problem detec ted "3 }

Figure 4.17 Structure gnrale de retour de fonction JSON avec erreur

4.4 Fonctionnalits en place

4.4.1 Scurisation du service Web

Explications

La scurit est un point important dans laccs un service Web. Les don-nes transmises par Yuukou II contiennent des informations sur la structure des diff-rents campus mais aussi des informations sur les tudiants (nom, prnom, photo parexemple). Il est donc important de limiter laccs aux donnes mais aussi de scurisertoutes les communications. Cest dans cette optique, quil a t dcid de mettre en placele protocole SSL entre le service Web et toute application voulant communiquer avec.

Le protocole Secure Sockets Layer, ou SSL, est conu pour assurer la confiden-tialit, lauthentification et lintgrit des donnes lors des changes entre un client etun serveur Web, sur diffrents protocoles de transport (en gnral HTTP). SSL met enplace un chiffrement cls publiques, cest--dire, une combinaison de deux cls : une clpublique servant au chiffrement des donnes et une cl prive servant au dchiffrement.Les sites Internet bnficiant de ce protocole sont reconnaissables du fait de leurs URL 8commenant par https:// o le s signifie secured.

Fonctionnement

La mise en place dun tunnel SSL entre client et serveur se fait en 4 tapes :

1. le client fait une demande de connexion scurise, il demande donc le certificatgarantissant la cl publique du serveur ;

2. le serveur lui envoie son certificat dauthentification dlivr par lautorit de cer-tification, ce certificat contient la cl publique. Une autorit de certification estun organisme charg de dlivrer des certificats et de leur attribuer une date devalidit, ainsi que de les rvoquer avant la fin de la date en cas de compromission ;

3. si lautorit de certification et le certificat sont valides, alors le client envoie unecl secrte, cre partir de la cl publique ;

4. le client et le serveur possde maintenant une cl secrte qui sera encrypte laidedun algorithme de hachage pour plus de scurit. Si la connexion est perdue, une

8. Uniform Resource Locator

44

https://


nouvelle cl secrte sera ngocie.

Mise en place

La mise en place dun protocole SSL sur un service Web via NetBeans et Glass-Fish est trs simple une fois que la dmarche suivante est connue. Il faut cependantdisposer de plusieurs fichiers : une autorit de certification et un couple cl priv-clpublique, tous deux fournis par lUniversit. partir de ces deux fichiers, un certificatde scurit est gnr. Ensuite, lautorit de certification et le nouveau certificat sontajouts la configuration de GlassFish.

La configuration avec NetBeans consiste prciser que le service Web utiliseraune connexion scurise de type SSL sur toutes les mthodes HTTP (Get, Post, . . .).Aprs dploiement, le service Web ne sera accessible quavec HTTPS et le certificat seradiffus.

4.4.2 Gnration de graphes dutilisation

Afin de rajouter des fonctionnalits au service Web, il a t mis en place unemthode permettant de gnrer des graphes dutilisation sous forme dune image. Basi-quement, une requte est excute sur la table yuukou_last, les donnes sont compteset la gnration dun graphe est effectue.

La gnration de graphes utilise lAPI RRD4J. Cette API est en fait limpl-mentation Java de RRDtool. RRDtool est un outil de gestion de base de donnes RRD(Round-Robin Database). Cest un outil open source permettant le stockage et la gnra-tion de graphes partir de donnes chronologiques. RRDtool est utilis avec notammentNagios et Cacti par exemple.

Dans le cadre du projet, lutilisation relle de ce logiciel a t dtourne du faitque normalement, les donnes sont constamment archives. En fait, chaque demandede graphes, une nouvelle table RRD est cre, remplie, exploite pour obtenir une imagede graphe puis efface. Le but ntait pas une intgration parfaite au service Web, maisun aperu des possibilits quoffre RRDtool.

La figure 4.18 prsente un exemple de graphe dutilisation des salles informa-tiques de lUniversit laide de lAPI RRD4J pendant une journe.

45


Figure 4.18 Exemple de graphe dutilisation des salles informatiques de lUniversitgnr avec RRD4J

4.4.3 Gestion des emplois du temps

Les flux RSS de lUniversit

Pouvoir donner le statut dune salle informatique un tudiant est un point cldu service Web. En effet, donner la disponibilit dune salle sans prendre en compte lefait quun cours puisse sy drouler nest pas suffisant. Il est ainsi ncessaire de connatreloccupation dune salle : le nombre dordinateurs libres, mais aussi si lemploi du tempsde cette salle permet de venir y travailler.

LUniversit met disposition 4 flux RSS contenant toutes les informations surloccupation des salles. Ces 4 flux correspondent aux 4 grands campus de lUniversit :Harrow, New Canvendish, Marylebone et Regent. Ils prsentent lavantage dtre critsen XML, de ce fait, le contenu des flux peut tre rcupr. Les informations permettantdidentifier un vnement sont extraites laide dun parseur de type DOM. Chaquevnement est ensuite ajout dans la base de donnes.

Correspondance des salles

Les noms des salles informatiques contenus dans les flux RSS et ceux prsentsdans Yuukou II ne sont pas les mmes. Cela vient du fait que les flux existent depuislongtemps, de ce fait, les quipes charges de leurs maintenance ont adopt leur propresystme de nommage des salles. Une table intermdiaire a donc t cre pour faire larelation entre une salle de Yuukou II et une salle de lemploi du temps. Cependant, lenommage ambigu des salles dans les diffrents flux demploi du temps fait que seules

46


quelques salles ont une correspondance dans le projet. Une discussion a eu lieu ce sujetdans le but dadopter un systme logique permettant de faire une correspondance plusfacile avec toutes les salles surveilles. Mais la mise en place dun tel systme nest pasprvue dans limmdiat.

4.4.4 Catalogue logiciels des salles

Un des objectifs de Yuukou II est de fournir un tudiant une liste des logicielspouvant tre utiliss dans chaque salle. Le but tant, quun tudiant, voulant travaillerdans une salle libre sur un logiciel spcifique comme Visual Studio, puisse trouver rapi-dement les salles qui correspondent ses attentes.

Il existe un MediaWiki mettant disposition des membres de lUniversit, desinformations sur les salles telles quune photo de la salle, une description, les responsableset la configuration logicielle de la salle. Un MediaWiki est un logiciel permettant deraliser des sites Internet de type wiki. Il sagit dun systme de gestion de contenu desites Web qui rend les pages Web librement modifiables par tous les visiteurs autoriss.Le site Web Wikipdia (http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal) a t dvelopp avec MediaWiki.

Afin de faciliter la gestion de sites Web de ce genre, de nombreuses APIexistent. Cest donc en utilisant une de ces API que la configuration logicielle de chaquesalle a t rcupre. Les diffrents logici

Rapport de stage - Bienvenue sur la page d'accueil · MAGHEZZI venus me rejoindre en cours de stage...

Documents

Transcript of Rapport de stage - Bienvenue sur la page d'accueil · MAGHEZZI venus me rejoindre en cours de stage...