Rapport de Stage de Master M2 INFORMATIQUE Mise en place d
Transcription
Rapport de Stage de Master M2 INFORMATIQUE Mise en place d
Département de Mathématiques et Informatique Université de la Réunion Le Conseil Général de la Réunion Rapport de Stage de Master M2 INFORMATIQUE Mise en place d'un outil de supervision et de contrôle distant réalisé par Patrick IRSAPOULLE 28000541 Entité Académique : Université de la Réunion Responsable Pédagogique : Fred Mesnard Nom de la Société : Le Conseil Général de la Réunion Tuteur de Stage : François Boyer Dates du stage : 6 Janvier au 7 Juillet 2014 <[email protected]> Saint Denis, île de la Réunion, 20 juin 2014 Université de la Réunion 15, avenue René Cassin B.P. 7151 97715 Saint-Denis Messag CEDEX 9 2 Présentation du Stage de M2 Informatique Contexte Ce stage se déroule dans le contexte de la n du cycle d'études du Master Informatique au sein de l'Université de la Réunion. Il s'insère directement à notre cursus pédagogique (à savoir le second semestre de notre cinquième année d'études supérieures). Chaque étudiant doit se mettre à la recherche d'une entreprise au plus tôt, rappelons que ce stage est à temps plein pour une durée de six mois. Un sujet pertinent doit être choisi par l'entreprise d'accueil, proposé à l'étudiant, puis validé par l'équipe pédagogique. Une convention est alors signée, liant l'étudiant, l'entreprise d'accueil et l'entité pédagogique. Objectifs Son objectif principal est de permettre de bénécier d'une véritable expérience de professionnalisation et ainsi de faciliter notre insertion vers le monde du travail. Découvrir l'univers professionnel, un secteur d'activité, participer à la vie de l'entreprise et surtout s'adapter à ses exigences font partie intégrantes de nos objectifs en tant que stagiaire. Concrétisant les savoirs acquis durant le parcours scolaire, il est nécessaire d'accomplir ce stage dans une secteur présentant des intérêts personnels, an de se spécialiser dans le domaine souhaité. 3 Résumé L'architecture représente la structure générale inhérente à un système informatique, et plus particulièrement l'organisation des diérents éléments, que ceux-ci soient de type matériel ou logiciel. Le principe de la supervision est de s'assurer du bon fonctionnement d'un système, sa mise en place permet d'eectuer des actions pro-actives et ainsi de détecter d'éventuels problèmes, avant que ceux-ci n'interviennent. Outre les éléments classiques à superviser, tels que les serveurs, switchs... Un nouveau type d'élément fait son apparition : L'imprimante (ou Multifonction) en Réseau. La politique actuelle visant à mutualiser ce type de périphérique, il devient plus qu'essentiel de garder un contrôle permanent sur celui-ci an d'éviter tout problème au sein des services concernés. Les postes de travail (environ 3500) sont les éléments les plus sensibles étant donné qu'ils sont dotés aux utilisateurs. Ils restent donc actuellement le type de matériel qui nécessite le plus d'interventions de la part des techniciens. C'est dans ce contexte que se situe l'objectif de ce stage qui est de coupler la puissance d'un outil de supervision à diérents outils d'administration, au travers d'une interface web simpliée, an de permettre aux techniciens d'eectuer un Diagnostic de premier niveau à distance, sur les imprimantes/multifonctions en réseau ainsi que les postes de travail avant toute intervention sur site. [Mots-clés : Microsoft, Linux, requêtes, programmation, SNMP, imprimante, poste de travail, réseau] Abstract The architecture represents the overall structure inherent in an IT system, especially the organization of the dierent elements that they are hardware or software based. The aim of monitoring is to ensure the correct functioning of a system, its implementation can perform proactive actions and thus to detect potential problems before these do occur. In addition to the conventional elements to monitor, such as servers, switches ... A new type of element is introduced : Network Printer (or Multifunction). The current policy aimed at pooling this type of device, it's more than essential to keep a permanent check on it to avoid any problems in the services concerned. Desktop computers (3500) are the most sensitive since they are elements equipped to users. They are currently the type of hardware that requires more intervention by technicians. It's in this context that is located the goal of this internship, which is to combine the power of a monitoring tool with dierent administration tools, through a simple web interface, to allow technicians to make a remotely rst-level diagnosis of network printer/multifunction and desktop computers before proceeding. [Keywords : Microsoft, Linux, queries, programming, SNMP, printer, desktop computer, network] 4 Remerciements Merci à toutes les personnes qui ont su contribuer au bon déroulement de ce stage de Master de deuxième année. J'adresse mes remerciements à Laurent PRUNELLA, pour m'avoir permis d'eectuer ce stage au SSU. J'exprime ma reconnaissance à mon responsable pédagogique, Fred MESNARD, pour sa disponibilité et ses conseils qui m'ont guidé tout au long de mon cursus universitaire. Je remercie François BOYER, mon tuteur de stage, pour ses qualités en tant qu'encadrant à la DEMS. Merci à Vincent Beauval, administrateur systèmes et réseaux du SAR, qui de part son expérience dans le domaine de la supervision, a réussi à me pousser à toujours eectuer les bons choix, tout en respectant l'architecture en place. Merci également à Florent PAYET qui m'a permis de développer mes connaissances dans le domaine de la virtualisation. Je tiens à exprimer ma gratitude envers toutes les personnes qui m'ont suivi et soutenu tout le long de mon parcours, une pensée particulière à mon collègue et ami Kévin TAOCHY, sans qui ce travail d'équipe n'aurait pas pu aboutir. 5 Table des matières 1 Introduction 1.1 1.2 1.3 1.4 Présentation de l'organisme d'accueil . . . . . . . . . . . . . 1.1.1 Le Conseil Général de la Réunion . . . . . . . . . . . 1.1.2 La Direction de l'E-administration et Modernisation 1.1.2. A Service Ressources et Méthodes . . . . . . 1.1.2. B Service Architecture et Réseaux . . . . . . 1.1.2. C Service APplications . . . . . . . . . . . . 1.1.2. D Service Support Utilisateur . . . . . . . . . Objectifs du stage . . . . . . . . . . . . . . . . . . . . . . . Problématique . . . . . . . . . . . . . . . . . . . . . . . . . Présentation du Rapport . . . . . . . . . . . . . . . . . . . . 2 Analyse des besoins et spécications 2.1 2.2 2.3 2.4 2.5 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . Les enjeux du projet . . . . . . . . . . . . . . . . . . . . . . Les informations pertinentes pour le technicien . . . . . . . Étude de l'existant . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Architecture du SI . . . . . . . . . . . . . . . . . . . 2.4.1. A Le serveur DNS . . . . . . . . . . . . . . . 2.4.1. B Le serveur DHCP . . . . . . . . . . . . . . 2.4.1. C Le contrôleur de domaine Active Directory 2.4.2 Easy Vista . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Le parc Imprimantes . . . . . . . . . . . . . . . . . . 2.4.3. A Panel Top Access . . . . . . . . . . . . . . . 2.4.4 Convention de nommage . . . . . . . . . . . . . . . . Gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Équipe Projet . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Planning Prévisionnel . . . . . . . . . . . . . . . . . 2.5.3 Cycle de vie du Projet . . . . . . . . . . . . . . . . . 2.5.4 Spécication des exigences . . . . . . . . . . . . . . . 2.5.5 Exemple d'un scénario et d'un cas d'utilisation . . . 3 État de l'art 3.1 3.2 . . . . . . . . . . . . . . . . des Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L'aspect Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Que peut-on superviser ? . . . . . . . . . . . . . . . . . . 3.2.2 Méthodes de Supervision . . . . . . . . . . . . . . . . . . 3.2.3 Les diérentes solutions . . . . . . . . . . . . . . . . . . 3.2.3. A Les solutions propriétaires . . . . . . . . . . . . 3.2.3. B Les solutions Open Source . . . . . . . . . . . 3.2.3. C Comparatif général des solutions Open Source 3.2.4 La solution retenue : Centreon Enterprise Server . . . . 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 9 10 10 11 12 12 12 13 13 14 14 14 15 16 16 17 18 18 18 19 20 20 20 21 22 22 23 23 24 24 24 25 25 27 27 28 29 30 3.2.5 Le protocole de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Le protocole solution pour la supervision en réseau 4.1 4.2 4.3 4.4 4.5 Présentation de Simple Network Management Protocol Les principaux éléments . . . . . . . . . . . . . . . . . 4.2.1 Le Manager . . . . . . . . . . . . . . . . . . . . 4.2.2 Agent SNMP . . . . . . . . . . . . . . . . . . . Des informations structurées . . . . . . . . . . . . . . . 4.3.1 Management Information Base . . . . . . . . . 4.3.2 Structure d'une MIB et Object IDentier . . . Les paramètres d'interrogations . . . . . . . . . . . . . 4.4.1 Les paquets à installer . . . . . . . . . . . . . . 4.4.2 Les diérentes versions de SNMP . . . . . . . . 4.4.3 Les communautés . . . . . . . . . . . . . . . . . Les requêtes SNMP . . . . . . . . . . . . . . . . . . . . 4.5.1 Les formats de requêtes . . . . . . . . . . . . . 4.5.2 SnmpWalk . . . . . . . . . . . . . . . . . . . . 4.5.3 SnmpGet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Réalisation 5.1 5.2 5.3 5.4 5.5 5.6 Les outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . De la supervision des imprimantes... . . . . . . . . . . . . . 5.2.1 Notion d'hôte/de groupe d'hôtes . . . . . . . . . . . 5.2.2 Dénition de commande . . . . . . . . . . . . . . . . 5.2.3 Dénition de service . . . . . . . . . . . . . . . . . . 5.2.4 Installation de plugins pour Nagios . . . . . . . . . . 5.2.5 Architecture de CES . . . . . . . . . . . . . . . . . . 5.2.6 Le combo Nagios et ndOutils . . . . . . . . . . . . . ... Au diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 La remontée d'informations dans la base de données En passant par la découverte réseau . . . . . . . . . . . . . Du serveur de développement au serveur de Production . . Les dicultés rencontrées . . . . . . . . . . . . . . . . . . . 5.6.1 Protection du réseau . . . . . . . . . . . . . . . . . . 5.6.2 Respect des conventions de nommage . . . . . . . . . 5.6.3 Livrables . . . . . . . . . . . . . . . . . . . . . . . . 5.6.3. A Architecture générale de l'outil . . . . . . . 5.6.3. B Machines virtuelles . . . . . . . . . . . . . . 5.6.3. C Documentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 32 32 33 33 33 34 34 35 36 36 36 37 37 37 37 38 39 39 40 40 40 40 41 41 42 42 42 44 45 46 46 47 47 47 48 48 6 Conclusion 49 A Webographie 54 B Annexes techniques 57 6.1 6.2 6.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Apport personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Perspectives futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1 Tableau de Bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.1 B.2 B.3 B.4 Création d'une machine virtuelle . . . . . . Installation de CES . . . . . . . . . . . . . . Suite de l'installation de CES via navigateur Les diérents éléments de Centreon . . . . . 7 . . . . . . Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 50 50 56 57 61 66 68 TABLE DES MATIÈRES B.5 Migration de la machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . B.6 V1 de l'interface Web de notre application . . . . . . . . . . . . . . . . . . . . . . 8 69 70 Chapitre 1 Introduction 1.1 Présentation de l'organisme d'accueil Ce premier chapitre est dédié à la présentation globale de l'organisme d'accueil. Des organigrammes illustreront les diérentes hiérarchies établies au sein des directions et services présents. Suite à la description du service auquel j'ai été aecté, seront introduits les objectifs de mon stage, la problématique xée et une présentation assez sommaire du rapport en lui-même. 1.1.1 Le Conseil Général de la Réunion Le Conseil Général est l'Assemblée Délibérante d'un Département, composée d'un ensemble de conseillers généraux. Ses membres, les Conseillers Généraux, sont élus au Surage Universel Direct uninominal à deux tours et chaque Canton dispose de son propre conseiller. Leur mandat est de 6 ans, avec renouvellement par moitié tous les 3 ans. Le Conseil Général est une collectivité qui agit pour le développement du Département et pour le bien-être de ses habitants. Il exerce des missions qui touchent tous les aspects de la vie des habitants de son Département. C'est par exemple, la construction et la rénovation de collèges publics... Ce sont également les politiques menées en faveur de l'insertion des personnes sans emploi, l'aide sociale en faveur de l'enfance, de la famille, des personnes âgées et des personnes handicapées. Son siège social est situé à l'hôtel du Département (2 Rue de la Source à Saint-Denis), le Conseil Général de la Réunion est composé de 49 conseillers généraux. Le quotidien et l'organisation des travaux du Conseil Général sont gérés par la Commission Permanente, qui se réunit chaque semaine. Sont présents : La présidente du Conseil Général, les 14 vice-présidents et les 16 membres permanents. Ses principaux domaines de compétence : Social Insertion Santé Enfance Éducation Environnement et Énergie Culture Sport Laboratoires Aménagement 9 1.1. PRÉSENTATION DE L'ORGANISME D'ACCUEIL Coopération Agriculture Transports et Routes Figure 1.1 Organigramme du Conseil Général de la Réunion 1.1.2 La Direction de l'E-administration et Modernisation des Services La DEMS (anciennement appelée "Direction Informatique") est la Direction dont la mission est d'assurer la maintenance évolutive, préventive et corrective du Système d'information et Télécommunications des services du Conseil Général, ainsi que de développer l'administration électronique et l'ouverture du Système d'information aux partenaires et usagers. En plus de sa Direction (composée du Directeur et de la cellule Animation/Formation), la DEMS regroupe 4 grands services : SRM SAR SAP SSU 1.1.2. A Service Ressources et Méthodes Le Service Ressources et Méthodes a pour vocation de faciliter le travail des services opérationnels en mettant à leur disposition les moyens nécessaires à la conduite de leurs missions et en assurant la gestion des ressources transversales. 10 1.1. PRÉSENTATION DE L'ORGANISME D'ACCUEIL Figure 1.2 Organigramme DEMS fonctionnel et nominatif Les principales missions : assurer le suivi des marchés de la direction gestion comptable et nancière gestion logistique : moyens gestion du courrier de la direction accueil physique et téléphonique suivi et coordination des projets transversaux 1.1.2. B Service Architecture et Réseaux Le service Architecture Réseaux a pour vocation de construire l'infrastructure du Système d'information. Ses missions : concevoir,maintenir et moderniser l'architecture du SI administrer et exploiter les équipements conduire les projets techniques fournir une assistance technique aux autres services veille technologique an d'anticiper les évolutions technologiques 11 1.2. OBJECTIFS DU STAGE 1.1.2. C Service APplications Le Service Applications assure la mise en place de solutions ou d'outils informatiques modernes et d'assurer leur fonctionnement et leur évolution. Ce service se décompose en deux parties, une équipe " Mission Développement", et le service SAPMA. L'équipe Mission Développement (placée sous la responsabilité d'un chef de projet) participe à l'analyse fonctionnelle du besoin ainsi qu'à l'élaboration du modèle conceptuel des données. Elle participe à la mise en oeuvre : paramétrages, formation... L'équipe Service APplications Maintenance Applicative fait partie de l'unité SAP et est composée de 6 agents. Cette équipe a pour mission première d'assurer la maintenance, l'administration technique et l'évolution des applications métiers du Département de la Réunion. Cependant elle a également en charge de développer des applications lorsque la mise en place d'un progiciel ne s'avère pas nécessaire. 1.1.2. D Service Support Utilisateur Le Service Support Utilisateurs (auquel j'ai été aecté) est l'un des plus actifs parmi tous les Services. En eet de part sa cellule d'interventions, ses diérents membres sont constamment en action sur le terrain (les diérents sites du Conseil Général) et doivent maintenir un contact permanent avec les utilisateurs. Pour plus d'ecacité cette équipe d'intervention est répartie selon des secteurs : Est, Nord, Sud/Ouest plus une équipe placée constamment au niveau du Palais de la Source. Passer des marchés publics de matériels, évaluer les besoins, préparer des postes pour les utilisateurs, faire du dépannage sur site...toutes ces tâches rythment le quotidien du SSU. 1.2 Objectifs du stage Initialement 3 thèmes ont été proposés comme sujet de stage. 1. Un thème principal (celui qui sera développé dans ce rapport, à savoir : "La mise en place d'un outil de supervision des imprimantes et postes de travail ". 2. Une période d'un mois a été déni pour le second thème "Interventions sur site ", an de travailler avec l'équipe d'intervention de la zone Nord. Ceci an d'appréhender l'architecture, les contraintes du quotidien du monde professionnel et également de développer la relation client. Pendant cette période j'ai également préparé des postes clients (préparation multi-postes en réseau grâce à un serveur WDS 1 ). Pour nir j'ai été en charge d'une dizaine de stagiaires qui provenaient de diérents centres de formation, an de faciliter leurs insertions dans le SSU. 3. Le troisième thème : "Formation " avait pour but une visée nettement plus pédagogique que technique. En eet suite à la décision de la Présidente du Conseil Général de doter les travailleurs sociaux d'ordinateurs portables, ceux-ci n'ont malheureusement pas eu d'accompagnements sur les diérents éléments installés sur leurs postes. 1. Windows Deployment Services 12 1.3. PROBLÉMATIQUE Un système d'exploitation plus récent (Windows 7), des logiciels de bureautique mis à jour (Microsoft Oce Word/Excel 2007), ainsi que la modernisation des services(webmail plutôt qu'un client lourd...), tous ces éléments nécessitent un certain suivi avec les utilisateurs. Qualié par la suite comme étant une "Aide à la prise en mains de l'outil informatique" plutôt qu'une formation à proprement parlé, tout simplement car aucun document ociel n'atteste que je suis un formateur. Pas moins de 90 agents de la Collectivité ont été formés correctement grâce à Kévin TAOCHY et moi-même. Outre l'aspect pédagogique ce mini-projet m'a permis de développer le côté logistique, à savoir : Mise en place de groupes Mise en place de sessions Coordination des moyens (techniques, humains...) Un mois entier a été nécessaire pour la réalisation de ce projet qui a été un réel succès, tellement que les demandes de participations aux sessions se poursuivent actuellement. 1.3 Problématique An de réaliser correctement ce projet conséquent, un binôme a été formé : mon collègue Kévin TAOCHY et moi-même. Kévin s'occupant de la partie développement de l'interface web ainsi que de la partie sécurité informatique. Quand à moi j'ai été en charge de la mise en place de l'outil de supervision, de l'étude d'un protocole de communication menant à la rédaction de scripts an de récupérer des informations sur les imprimantes (et multifonctions) en réseau ainsi que la recherche de diérentes commandes et outils existants an de réaliser un diagnostic de premier niveau sur les postes de travail. Notre étude préliminaire a donné naissance à la problématique suivante : Est-il possible d'intégrer un outil de supervision à la structure déjà en place ? Quel est l'intérêt de le coupler à des outils d'administration au sein d'une interface web ? Le fait de maximiser les interventions à distance peut-il inuer sur la réduction des coûts de déplacement liés aux interventions sur site ? 1.4 Présentation du Rapport Dans une première partie, ce rapport présente le cahier des charges qui a été établi suite à la proposition de ce thème de stage. Ainsi seront détaillés l'étude des besoins, les solutions existantes, puis enn les solutions choisies tout en respectant l'architecture réseau déjà en place. La seconde étape concerne la présentation des diérents outils, à la fois ceux mis à notre disposition et également ceux mis en place par la suite, sans oublier les dicultés rencontrées. Enn nous terminerons avec la conclusion qui décrira l'apport personnel à ce stage ainsi que les perspectives futures pour ce projet. 13 Chapitre 2 Analyse des besoins et spécications 2.1 Introduction Une fois la problématique posée, l'étape suivante logique, était l'analyse des besoins. Cette étape qui peut s'avérer assez longue est une phase préparatoire qui va mener à la réussite du projet. En eet les statistiques ont montré que dans 70 % des cas un échec sur un projet était dû à une analyse des besoins bâclée ou quasi inexistante et non pas à un mauvais développement ou une mauvaise conception. 2.2 Les enjeux du projet Ce projet a été initié par le SSU, et plus particulièrement par notre tuteur qui a lancé l'idée : François BOYER pour les agents du SSU. Il faut comprendre que les membres du SSU et plus particulièrement les techniciens d'interventions sont constamment sur le terrain et se doivent de maintenir un bon relationnel avec les agents du Conseil Général, leur quotidien est très agité et ils ont un quota d'interventions à respecter par mois. Chaque intervention est listée et répertoriée via un outil appelé EasyVista (dont la description sera donnée dans l'étude de l'existant). On comprend tout de suite que chaque intervention doit être valorisée et la plus eciente possible (rendu vis-à-vis du temps passé à eectuer cette intervention). C'est dans cette optique qu'intervient la mise en place de notre outil de supervision et de contrôle distant. Dans le respect de ma problématique, ce projet doit inuer sur les paramètres suivants et donc les améliorer : Ecience de l'intervention L'ecience regroupe à la fois la vitesse d'intervention ainsi que la qualité de l'intervention. Si le technicien bénécie d'informations pertinentes (dès lors se pose le problème de la dénition d'une information pertinente) il n'aura sans doute pas à passer autant de temps sur une intervention. S'il sait à quel endroit il devra agir, il devient évident qu'il pourra alors préparer les outils nécessaires et procéder plus rapidement. Un outil de diagnostic répond à ce besoin, en fournissant à la demande les informations jugées nécessaires sur un bien matériel. L'intervention à distance Une intervention sur site mobilise des moyens, de type humain (le technicien doit se rendre sur place), de type matériel (il prend un des véhicules de service du SSU), un des objectifs du SSU cette année est de maximiser les interventions à distance. Un outil de contrôle résout en partie ce problème, lorsque l'on peut intervenir à distance selon la nature du problème évidemment. 14 2.3. LES INFORMATIONS PERTINENTES POUR LE TECHNICIEN 2.3 Les informations pertinentes pour le technicien Grâce à l'outil EasyVista évoqué précédemment, les techniciens se voient attribuer des interventions à traiter dans les plus brefs délais. Il faut bien évidemment établir un ordre de priorité dans ces interventions. Les problèmes les plus fréquents sont ceux liés aux postes de travail (le type de matériel le plus nombreux), ils peuvent être d'ordre matériel (écran qui ne s'allume plus par exemple), logiciel (impossibilité de faire une mise à jour) etc... Lorsque le problème est d'ordre logiciel il est plus qu'essentiel de procéder à une intervention à distance, soit par téléphone avec l'agent concerné, soit en prenant le contrôle de son poste et ainsi de corriger la défaillance constatée. En cas de problème concernant un progiciel 1 , l'intervention sera rapatriée à SAPMA. Dans la section précédente, j'ai évoqué la notion d'information pertinente pour augmenter l'ecience d'une intervention, voyons à présent comment dénir ces informations. 1. Les postes de travail Le ping Le ping permet de déterminer la première information logique, à savoir si le poste est présent ou non sur le réseau (suivant si le ping est positif ou non) Stratégie de groupe Windows Grâce à Active Directory, des stratégies peuvent s'appliquer aux postes clients, celles-ci peuvent aller des restrictions systèmes (impossibilité d'installer des programmes), aux permissions serveurs (accès à tel ou tel serveur de stockage en fonction de l'appartenance à un service). Ceci permet de garder un contrôle sur l'utilisateur et son environnement. DNS Permet la correspondance entre une adresse ip et un nom plus simple à retenir et à dénir. Exemple de base si un utilisateur ne peut se connecter à un serveur de stockage, il est possible que ses paramètres de DNS soient erronés. Paramètres de proxy Le proxy installé à la DEMS est "ProxySquid", pour rappel un proxy permet de faire la liaison entre le réseau interne (intranet) et internet, sans conguration au préalable de ces informations, il est alors impossible à l'utilisateur de se connecter à internet, et d'utiliser des services tel que le web par exemple. 2. Les imprimantes/multifonctions en réseaux Le Ping Comme pour les postes de travail, ceci nous permettra de vérier si le matériel est présent ou non sur le réseau Le niveau d'encre Sans doute la problème le plus récurent étant donné que les niveaux d'encre ne sont pas vériés, un état d'alerte (par exemple 15 % d'encre restant) pourra être installé, pour prévenir ce problème Absence de papier dans le/les bac(s) concerné(s) Le technicien pourra déterminer si l'imprimante/multifonction dispose d'un ou plusieurs bacs et si l'en d'entre eux voire plusieurs sont vides Modèle, nom et serial number Cela peut sembler anodin mais certains modèles disposent de caractéristiques bien spéciques, qu'il faudra peut-être prendre soin de vérier (dans des ches techniques) au préalable avant d'intervenir Localisation physique Pour m'être déjà rendu à plusieurs reprises dans certains locaux du Conseil Général, il n'est pas chose facile de s'y retrouver, une localisation physique du matériel avec indication sur le service concerné sera la bienvenue Statut Le matériel est-il sous tension, est-il occupé au moment où on l'interroge (en cours d'impression par exemple)... 1. Contraction de Produit et Logiciel qui fait référence à des applications métiers par exemple 15 2.4. ÉTUDE DE L'EXISTANT 2.4 Étude de l'existant Cette section traite de l'architecture réseau en place actuellement au Conseil Général, ainsi que des serveurs et/ou des diérents outils desquels nous dépendrons (donc pas de la totalité des serveurs et outils présents) lors de la réalisation de notre projet. Ces éléments sont à prendre en considérations, c'est à nous de nous adapter et de respecter ce qui est déjà en place, en aucun cas nous ne pourrons nous permettre d'imposer un choix qui touche aux politiques déjà établies, que celles-ci soient de sécurité ou autre. 2.4.1 Architecture du SI L'architecture du Conseil Général est de type réseau maillé hébergé par l'opérateur historique. Il Dispose de plus de 150 sites interconnectés avec des débits variés. Le c÷ur du SI 2 est un DataCenter sous VMWare. Les principaux OS sont Microsoft Windows Server, Debian et Ubuntu pour les Serveurs. Les postes de travail ont Microsoft Windows XP à 7. Figure 2.1 C÷ur de réseau du Conseil Général Le c÷ur de réseau du Conseil Général est composé de la manière suivante : Sécurité Deux rewalls protègent en permanence le système d'information. Un rewall dit "rewall interne" protège les serveurs internes, le second, appelé "rewall internet" sert de rempart contre les attaques provenant de l'extérieur. Connexion Deux connexions 10 Mbits en bre sont utilisées pour avoir accès aux applications métiers et/ou aux sites hébergés par le Conseil Général. Une connexion de 50 Mbits est dédié uniquement aux connections avec Internet. DMZ 3 Pour rappel une DMZ ou zone démilitarisée est un sous réseau distinct du réseau local, lié à celui-ci et à internet par le biais du rewall, en cas d'attaques externes le pirate n'aura 2. Système d'Information 16 2.4. ÉTUDE DE L'EXISTANT accès qu'aux machines placées en DMZ et non au réseau local. Dans la DMZ on retrouve donc les serveurs et les applications pouvant être accédés depuis l'extérieur, comme le serveur ftp 4 ou l'application de messagerie. Figure 2.2 C÷ur de LAN Connexion Les diérents sites du Conseil Général sont reliés à la direction informatique par des liaisons BVPN 5 allants de 2 Mbits à 10 Gbits. Les médias utilisés peuvent être de la SDSL 6 ou de la bre optique. Site Chaque site possède son propre sous-réseau et communique avec les autres sous-réseaux grâce au switch c÷ur de réseau. Le réseau du Conseil Général est composé donc de VLAN 7 qui correspondent chacun à un site ou une solution technologique (exemple : wi placé sur le VLAN ***). Enn sur chaque site un serveur de stockage est placé an que les agents puissent régulièrement eectuer des sauvegardes de leurs documents de travail. Voici une liste non exhaustive des serveurs qui me paraissent les plus importants (d'autres tels que les serveurs d'applications etc... n'ont pas été évoqué volontairement) : 2.4.1. A Le serveur DNS Un serveur DNS 8 ou serveur de système de nom de domaine est comparable à un annuaire. En eet lorsque l'on souhaite joindre une machine distante (poste de travail ou serveur) qui se trouve sur le réseau, notre ordinateur va requêter le serveur DNS pour récupérer l'adresse IP 9 de 4. 5. 6. 7. 8. 9. File Transfer Protocol Broadband Virtual Private Network Symmetric Digital Subscriber Line Virtual Local Area Network Domain Name System Internet Protocol 17 2.4. ÉTUDE DE L'EXISTANT la machine à joindre. Tout simplement le serveur DNS permet de faire la relation entre le nom de la machine et son adresse IP. Ce service a été conguré sous Windows Server 2003 R2. 2.4.1. B Le serveur DHCP Un serveur DHCP 10 a pour rôle de distribuer des adresses IP à des clients sur le réseau pour une durée déterminée (un bail DHCP). Cela permet de délivrer automatique des adresses en fonction de l'endroit où l'on se connecte. Également ce serveur a été conguré comme l'un des rôles sous Windows Server 2003 R2. Par convention, seuls les postes de travail bénécient d'un bail DHCP, et donc d'une durée eective de l'adresse IP aectée à chaque poste, une fois ce bail dépassé, la machine se verra attribuer une nouvelle adresse IP. A contrario les autres éléments placés en réseau doivent absolument avoir une adresse IP xe, notamment les serveurs ainsi que les imprimantes/multifonctions en réseau. En eet pour des raisons évidents, ces machines sont sollicitées et requêtées régulièrement, il faut donc une adresse xée. Des plages d'adresses IP sont donc réservées : Les serveurs sont adressés en 10.2.1.* Les imprimantes et multifonctions en réseaux sont adressés en 10.*.2.* 2.4.1. C Le contrôleur de domaine Active Directory Active Directory est le service d'annuaire de Microsoft. Il faut prendre le terme d'annuaire au sens large, Les services de domaine Active Directory stockent les données d'annuaire et gèrent les communications entre les utilisateurs et les domaines, y compris le processus d'ouverture de session utilisateur, l'authentication et les recherches dans l'annuaire. Le but étant d'orir des services centralisés. Donc un utilisateur enregistré peut se connecter sur n'importe quel poste du Conseil Général avec ses propres logins, tant que ce poste est placé correctement sur le domaine. Autre particularité les utilisateurs font partie de groupes que l'on appelle des OU 11 , qui permettent ainsi d'identier les droits de chacun, et donc les stratégies qui sont appliquées. Un contrôleur de domaine Active Directory est un serveur qui exécute les services de domaine Active Directory. LDAP 12 est le protocole qui permet d'interroger cet annuaire AD. 2.4.2 Easy Vista EasyVista permet de recenser le matériel actif (gestion de l'inventaire) et de l'associer grâce à un lien symbolique à des agents et aux services concernés. Le logiciel intègre également la gestion des logiciels installés sur les équipements informatiques, et surtout les licences associées. Autre fonctionnalité intéressante et largement exploitée au sein de la DEMS : La gestion des problèmes, en eet au sein de l'interface se trouve une partie spécialisée dans la création de ches de signalements d'incidents (chaque che est associée à un ticket unique), qui seront visibles par les techniciens et seront répertoriées comme étant des interventions. 10. Dynamic Host Conguration Protocol 11. Organizational Unit 12. Lightweight Directory Access Protocol 18 2.4. ÉTUDE DE L'EXISTANT Figure 2.3 Exemple de che de signalement d'incident 2.4.3 Le parc Imprimantes Le parc imprimantes du Conseil Général, se compose d'imprimantes classiques (qui ne disposent pas d'interface réseau, mais elles sont très rares), d'imprimantes monochromes en réseau, d'imprimantes couleurs en réseau et également de multifonctions en réseau. Suite au dernier recensement du matériel en réseau il s'avère que 448 imprimantes/multifonctions sont placées en réseau. Elles sont réparties de la sorte : Figure 2.4 Hétérogénéité du parc d'imprimantes Ce qui attire tout de suite l'÷il est donc la forte hétérogénéité de ce parc, ceci s'explique tout simplement car des marchés publics sont établis assez régulièrement lorsqu'une nouvelle demande est en cours d'exécution, donc il est impossible de privilégier telle ou telle marque de matériel. Cependant je constate l'énorme pourcentage occupé par la marque HP (une trentaine de modèles diérents tous confondus) qui représente 273 exemplaires, suivi de près par Kyocera (cinq modèles ) avec ses 104 exemplaires, puis de Toshiba (trois modèles) composé de 59 exemplaires. 19 2.5. GESTION DE PROJET Les autres marques ne sont pas vraiment signicatives en terme d'eectifs , à savoir : Lexmark, Canon et Sharp. Bon nombre des simples imprimantes sont destinées à disparaitre dans un futur proche, remplacées par des multifonctions au sein des services ( par exemple un service où se trouvent une imprimante couleurs, une imprimante monochrome et un scanner, se verra attribuer une multifonction remplaçant tout ce lot de matériels). 2.4.3. A Panel Top Access Le Panel Top Access est une application Web, permettant d'administrer, de paramétrer ou de surveiller à distance l'état de la machine. Ce Panel est disponible sur l'ensemble des imprimantes et multifonctions en réseau. 2.4.4 Convention de nommage En informatique une convention de nommage, est une ou plusieurs règles à respecter, en général une suite de caractères qui formalise (dans notre cas d'utilisation) un bien matériel. En eet chaque bien matériel au Conseil Général possède un identiant unique que l'on appelle un "code matériel" présent sous la forme d'une étiquette avec un code barre, collée sur chacun d'entre eux. Lors de la préparation des postes, une étape essentielle est donc le renommage du matériel pour l'identication sur le réseau (****** représente le code matériel disponible sur l'étiquette qui est collée) : PC****** pour les postes de travail PT****** pour les ordinateurs portables PR****** pour les imprimantes En respectant ce nommage, l'inventaire du parc sera facilité et une fois l'ensemble ramené dans l'outil EasyVista, cela permettra de mieux identier chaque matériel. Des sessions de recensement sont organisées régulièrement an de maintenir le parc à jour. Kévin et moi-même avons participé à ses recensements dans le cadre de notre intégration au SSU. Si concernant les postes de travail et les portables, le renommage est respecté (vis à vis de la procédure à suivre pour la préparation des postes), pour les imprimantes c'est une toute autre paire de manches, en eet seulement 70 imprimantes/multifonctions en réseau sont nommées correctement à l'aide du Top Access sur près de 450 matériels. Des mesures seront à prendre très prochainement an de maintenir l'uniformité du parc des imprimantes. 2.5 Gestion de projet Figure 2.5 Gestion de Projet 20 2.5. GESTION DE PROJET Il est nécessaire de mener une conduite de projet, et donc d'instaurer une certaine trame à suivre pour le bon déroulement de ce projet. Il faut prendre en compte le contexte (environnement), les fournisseurs (service interne, prestataire...) et l'impact qu'aura notre outil sur les utilisateurs (référence au besoin). 2.5.1 Équipe Projet Figure 2.6 Graphe systémique de Patrick IRSAPOULLE La réussite d'un projet passe par une organisation rigoureuse et ecace de l'équipe projet. Deux notions sont à identier à présent : la MOA 13 et la MOE 14 .Les techniciens du SSU représentent la MOA, car ils sont à l'origine de l'expression du besoin. Durant ce stage, Kévin TAOCHY et moi-même avons joué le rôle de chef de projet, nous avons donc formé la MOE, c'est-à-dire le personnel chargé de prendre connaissance du besoin exprimé et d'y répondre en y apportant des solutions. Bien entendu, nous avons dû quotidiennement faire appel à nos collègues de la DEMS, qui nous ont apporté leur aide, ou cas inverse, nous-même aider ces personnes. Ce graphe représente les relations professionnelles entre les diérents acteurs, ces relations sont exprimées par des èches dont la taille est proportionnelle à l'intensité des interactions entre ces acteurs. 13. Maîtrise d'ouvrage 14. Maîtrise d'oeuvre 21 2.5. GESTION DE PROJET 2.5.2 Planning Prévisionnel Figure 2.7 Planning prévisionnel 2.5.3 Cycle de vie du Projet Du planning prévisionnel précédent découle le cycle de vie du projet, il a semblé évident que celui-ci serait un modèle en cascade. Plus simplement à chaque phase d'avancement du projet une étape de vérication était nécessaire. Chaque n de mois une réunion mensuelle est organisée au SSU, an d'évaluer les tâches du prochain mois, ce qui a été réalisé pendant le mois etc... Figure 2.8 Modèle en Cascade Ces mensuelles nous ont permis de résumer notre avancement dans le projet à chacune de ses phases, une fois que la phase actuelle était validée par notre chef de service, notre tuteur ainsi que les techniciens, nous avons pu progresser petit à petit. Évidemment ce modèle sous-entend de terminer à une date précise et de produire les livrables que si ils sont correctement dénis au préalable. Figure 2.9 Validation mensuelle de la progression du projet 22 2.5. GESTION DE PROJET 2.5.4 Spécication des exigences J'ai dû me consacrer principalement à ces imprimantes et multifonctions pendant que mon collègue, Kévin, s'occupait des postes de travail. Avant toute étude des technologies à utiliser (le chapitre suivant) nous avons dû remettre en considération le sujet de stage. En eet si le terme supervision s'accorde parfaitement avec les imprimantes en réseau, ce n'est pas le cas pour les postes de travail. Il faut avouer en eet que superviser près de 3500 postes de travail ne serait pas très judicieux. En revanche après m'être concerté avec mon collègue Kévin TAOCHY et notre tuteur François BOYER, il a été convenu que le terme approprié pour les postes de travail serait uniquement "diagnostic", vu la nature des outils à utiliser. Les états des postes seront achés et les techniciens pourront se connecter à distance sur ceux-ci grâce à l'interface web uniée. 2.5.5 Exemple d'un scénario et d'un cas d'utilisation Durant ma période de stage, j'ai pu moi-même assister à un des cas évoqués par notre tuteur lors de la présentation des thèmes de stage. En eet les agents du CG ne possèdent que peu voire pas de connaissances concernant la gestion d'un bien matériel telle qu'une imprimante en réseau, et de toute façon ce n'est pas leur domaine de compétence. Un scénario classique : Un agent du Conseil Général lance une impression d'un document, rien ne se passe. Cet agent poste alors une demande d'intervention , en remplissant un formulaire qui se trouve sur l'intranet. Un des techniciens présents ce jour-là indique sur EasyVista qu'il va se charger de cette intervention. Il prend donc une des voitures du SSU (le nombre de véhicules étant assez limité) se rend sur le site concerné an de dépanner cet agent, et une fois sur place, se rend compte qu'une cartouche couleur était totalement vide et donc empêcher le lancement de l'impression. Reprenons dans l'ordre, pour cette intervention superue : Temps de travail perdu pour une pseudo-intervention Un technicien mobilisé alors que d'autres interventions n'ont pas pu être résolues Un véhicule a été mobilisé, ce qui obligera peut-être un autre technicien à attendre le retour de celui-ci Du carburant a été consommé lors de ce trajet, et représente donc une dépense non indispensable Si une application telle que celle que nous allons mettre en place était déjà disponible, le niveau d'alerte d'encre aurait pu être remonté et un technicien aurait pu prévenir le service concerné an de changer la cartouche dont il est question. Cette situation semble exagérée à première vue, mais selon les techniciens ces cas arrivent tellement souvent, que nous ne pouvons les négliger. Il faut prendre un peu de recul an d'observer la situation actuelle, en anticipant ce genre de problèmes et donc d'établir un diagnostic de premier niveau (matériel et/ou logiciel), nous pourrons sur le court terme, augmenter les interventions à distance, et surtout les rendre plus ecientes. Sur le long terme, le problème des restrictions budgétaires qui est évoqué actuellement, ne sera certes pas résolu en évitant ces trajets et donc ces dépenses non essentielles, mais il n'y a pas de petites économies. Ainsi cumulés ces fonds pourront servir à d'autres missions plus nécessiteuses. 23 Chapitre 3 État de l'art 3.1 Introduction Une fois l'environnement de travail étudié, il fallait trouver des solution pour répondre à notre problématique. Intervient alors l'étape de l'état de l'art, c'est-à-dire l'état des techniques existantes dans le domaine étudié, sans que nous ayons besoin de faire preuve d'une activité inventive. "Il ne faut pas réinventer la roue." Les sources peuvent être diverses : journaux, revues et publications scientiques, articles, rapports de recherches... Cette démarche m'a permis de dénir les technologies à utiliser et à appliquer. 3.2 L'aspect Monitoring Le terme Monitoring couramment utilisé, provient de l'anglais, il signie supervision. Cependant une précision est à apporter, en eet ceci est un abus de langage, car en vérité le Monitoring est composé de deux disciplines : la métrologie et la supervision. La métrologie permet de créer des historiques de données, d'y appliquer un traitement (des ltres par exemple) an d'extraire les données qui nous intéressent et de les présenter sous forme de graphiques. Cet historique des données permet si besoin d'apporter des correctifs au niveau des paramétrages des services, le juste pourcentage des ressources à utiliser... Cet aspect du Monitoring est tout aussi important car il va permettre d'améliorer le service, et donc ainsi le rendu de l'utilisateur. Concentrons-nous à présent sur la véritable notion qui est dénie dans ce rapport à savoir la supervision. Une dénition récurrente sur le Web indique que : "la supervision est une technique de suivi de pilotage informatique de procédés de fabrication automatisés. La supervision concerne l'acquisition de données (mesures, alarmes, retour d'état de fonctionnement) et des paramètres de commande des processus généralement conés à des automates programmables." En résumé la supervision est la surveillance du bon fonctionnement d'un système ou d'une activité. En eet quel que soit le secteur d'activité, l'informatique est devenue l'épine dorsale de l'entreprise. Plus particulièrement le système d'information qui est au centre de l'activité de diérentes entités métiers, doit fonctionner correctement et en permanence an de garantir l'efcacité de l'entreprise. Les problèmes liés à l'informatique doivent donc être réduits le plus que possible, car l'indisponibilité d'un ou plusieurs éléments, quel que soit son niveau signicatif (réseau, serveurs d'applications, serveurs de données, terminal utilisateur...) inuera sur la qualité de service et donc le bon fonctionnement de l'entreprise. 24 3.2. L'ASPECT MONITORING Deux enjeux majeurs sont à noter : garantir la disponibilité et les niveaux de service du système en cas de panne ou de baisse des performances tenter de prévenir l'administrateur des diérents problèmes et au besoin assurer une remontée des informations an de garantir une durée d'intervention minimale 3.2.1 Que peut-on superviser ? La supervision est un vaste domaine de l'informatique qui reprend plusieurs activités dont les principales sont : Surveiller Visualiser Analyser Piloter Alerter La véritable question à se poser serait " est-ce qu'un système d'information peut ne pas avoir de faille ? " Concrètement an de maintenir un fonctionnement optimal, tout devrait être supervisé, ou du moins peut-être supervisé du moment que l'on peut déterminer un état : réseau serveurs périphériques postes client applications... Libre à l'administrateur de placer des niveaux de priorités entre les diérents éléments pour dénir ce qui doit ou ce qui ne doit pas être supervisé selon diérents critères (charge du réseau, manque de moyens...). Actuellement à la DEMS, ne sont supervisés que les switchs, serveurs et tout ce qui touche à l'état du réseau en lui-même (trac eectif). Il sera important de rajouter les diérentes imprimantes et multifonctions en réseau parmi les périphériques à superviser. Concernant les postes de travail, ils sont trop nombreux et les remontées d'informations sur ceux-ci ne seraient pas assez pertinentes pour évaluer les problèmes. Des outils d'administration plutôt que de supervision seront à adopter pour ce type de matériel. 3.2.2 Méthodes de Supervision Deux grandes méthodes s'opposent lorsque l'on parle de supervision. le polling le heartbeat Le Polling est un sondage réalisé périodiquement (à intervalle de temps régulier) par un superviseur. 25 3.2. L'ASPECT MONITORING Avantages Polling A l'initiative du superviseur Permet un véritable suivi Inconvénients Des échanges pour rien Temps de réaction Possibilité de ne pas voir certains changements Figure 3.1 Méthode du Polling Le HeartBeat est un signal émis par un équipement à chaque changement d'état. Avantages HeartBeat Des échanges si nécessaire Temps de réaction Tous les changements d'états sont remontés Inconvénients Suivi moins complet A l'initiative de l'équipement actif Figure 3.2 Méthode du heartbeat En conclusion il n'y a pas de meilleure ou de moins bonne solution, mais il faut penser à orienter le concept en fonction du projet que l'on veut mener. Suite à une longue réexion an de déterminer lequel des deux concepts était le plus approprié à notre projet, nous avons ni par conclure que celui-ci se rapprochera le plus du Polling, il faudra qu'un serveur central interroge régulièrement les périphériques, et stocke les données, cependant aucune notication particulière ne sera renvoyée. L'outil sera à utiliser au besoin et donc sur demande, uniquement lorsque les pannes seront référencées et indiquées. C'est pour cela que l'on couple la notion de Supervision à celle de Diagnostic. 26 3.2. L'ASPECT MONITORING 3.2.3 Les diérentes solutions Un outil de supervision doit répondre aux critères suivants : des mécanismes pour déterminer l'état d'une ressource/process une console de monitoring des remontées d'alertes 3.2.3. A Les solutions propriétaires Commençons par les solutions dites propriétaires. Quatre grosses sociétés se partagent le marché de la supervision, elles sont appelées le "Big4". Figure 3.4 HP Openview Figure 3.3 Ibm Tivoli Software Figure 3.5 Computer Associates Technologies Unicenter Figure 3.6 HP Openview Le but n'était évidemment pas d'acheter une ou plusieurs licences de logiciels propriétaires. Même si ceux-ci proposent des solutions confortables, avec des atouts tels que le support et la maintenance. Il faut comprendre qu'à l'heure actuelle, les anciens critères (abilité, support...) qui opposaient les logiciels propriétaires aux logiciels Open Source ne sont plus valables. En effet aujourd'hui il est tout à fait possible d'avoir un Système d'Information dans une entreprise composé uniquement de logiciels Open Source. Leur principal atout ? Non pas la gratuité comme beaucoup le pense, mais bel et bien les réelles communautés sur lesquelles s'appuient les solutions. Universitaires, développeurs reconnus, professionnels tous s'associent désormais et forment les principaux contributeurs du monde Open Source. Mieux encore les développeurs de logiciels propriétaires se séparent de leurs précédentes rmes dans le but d'orir leurs propres solutions libres. Ces solutions qui ont vu les jour et qui sont testées maintes et maintes fois avec des correctifs réguliers, sont totalement ables, orent une modularité (plugins etc...) et une compatibilité totale. En eet nit le problème des protocoles propriétaires, les normes sont adoptées et respectées, ce qui permet d'établir une certaine souplesse et donc cela autorise l'hétérogénéité du matériel à acheter. L'administrateur ayant adopté une telle solution ne verra qu'une seule et véritable contrainte, le besoin constant de rester informé sur la technologie, il faudra régulièrement se rendre sur les forums, les blogs tout ce qui est capable de rééchir l'aspect communautaire, et ainsi d'orir des réponses aux questions posées. Cet échange de bon procédé, permettra de mettre à jour régulièrement les solutions et de les adapter en fonction du besoin utilisateur. Voyons à présent les solutions disponibles dans le monde de l'Open Source concernant le domaine de la supervision. 27 3.2. L'ASPECT MONITORING Figure 3.7 Métrologie ou Supervision ? 3.2.3. B Les solutions Open Source Il faut savoir qu'il existe des dizaines de solutions Open Source dédiées au Monitoring, le principal critère de choix réside dans les diérents cas d'utilisation. Dans cette partie sont présentées quatre solutions parmi les grands noms du Monitoring, à savoir : Zabbix, Cacti,Nagios et Centreon (d'autres solutions telles que "Munin" ont été volontairement ignorées car elles sont décrites comme présentant uniquement le côté métrologie du Monitoring). Ainsi un comparatif sera établi an de dénir correctement quelle solution sera la plus appropriée en terme de supervision et non de métrologie. 1. Zabbix est une application libre (open source) de supervision des systèmes et des réseaux. Par sa polyvalence, Zabbix peut superviser et vérier les statuts d'une multitude de services réseaux, ou systèmes, ce qui fait de lui un outil complet proposant des fonctionnalités relatives à la supervision (alertes, mesures, actions sur conditions...). Le principal reproche vient de l'aspect graphique où dans certains cas la lisibilité laisse à désirer. Certains lui reprochent également son interface web dite un peu "vieillotte" et la prise en main initiale n'est pas forcément intuitive. 2. Cacti est un outil de monitoring qui a la particularité d'avoir une " Plugin architecture" qui va lui permettre l'ajout de fonctionnalités grâce à l'importation et à la congurations de plugins via l'interface web. L'aspect supervision proposé ici ne sera pas aussi développé que dans les autres logiciels (nagios par exemple), on notera par exemple l'absence de panel de msesures, de groupes d'utilisateurs... Donc Cacti reste un outil de métrologie intégrant de nombreuses possibilités grâce aux plugins, avec la possibilité d'une mise en place de supervision mais uniquement dans les cas les plus simples. 3. 28 3.2. L'ASPECT MONITORING Nagios est ce que l'on appelle un ordonnanceur , c'est-à-dire qu'il va lancer les diérents tests de supervision, appelés contrôles, sur les hosts et services. Il reste l'outil de supervision le plus utilisé à l'heure actuelle, sa conguration sous forme de chiers, peut s'avérer vite repoussante mais en fait cependant un candidat idéal pour l'automatisation. L'inconvénient de Nagios reste son IHM 1 très basique. Il faut avouer que son interface ne donne pas spécialement envie d'être consultée, en eet au delà de la pertinence de l'information, il faut de la compréhension et de l'interprétation. C'est sur ce constat que vient se greer la prochaine solution décrite : Centreon. 4. Centreon, une interface à Nagios. Première précision à apporter, le coeur de Centreon est basé sur Nagios. Centreon propose une interface web diérente de celle de Nagios et y ajoute des fonctionnalités (génération de la conguration de Nagios, stockage des données de performance, interface ergonomique...). En résumé, Centreon est considéré comme un outil à part entière même si il est basé sur Nagios comme ordonnanceur. Il propose donc au sein d'une même interface tout ce qui est nécessaire à la surveillance de l'infrastructure et donc à faire de la supervision pure et dure. Malgré tout il ne propose que le minimum concernant la métrologie, on ne pourra pas par exemple remonter des informations orientées services comme celle d'une base de donnée, que l'on pourrait avoir sous Cacti ou Munin. 3.2.3. C Comparatif général des solutions Open Source Solution Zabbix Cacti Nagios Centreon Avantages - Outil complet - Polyvalent (supervision + métrologie) - Outil de métrologie complet - Multitude de fonctionnalités grâce aux plugins - Outil de supervision par excellence - Automatisation (templates) - Mesure des ressources - IHM agréable et intuitive - Basé sur le c÷ur de Nagios Inconvénients - Prise en main complexe - Manque de lisibilité sur certains écrans - Création complexe des templates - Insusant pour une supervision d'un grand parc matériel - IHM à améliorer - Conguration par chier - Pas d'exploitation graphique des mesures - L'aspect Métrologie est des plus simples - Pas de graphes corrélant les performances (utilisation d'un Apache par exemple) - Zabbix propose une interface uniée, avec des fonctions avancées, la partie métrologie présente présente vraiment des notions intéressantes (graphes complexes de mesures...), sa prise en main n'est pas assez intuitive pour compenser son IHM qui est moins agréable que Centreon par exemple. - Il s'avère qu'au nal, Cacti soit un outil de métrologie avancée (pas autant que Munin), même si il présent un aspect de supervision, pas assez développé malheureusement pour conduire à son choix. 1. Interface Homme Machine 29 3.2. L'ASPECT MONITORING - Nagios semble parfait pour l'automatisation des congurations et la gestion centralisée de l'infrastructure, son gros désavantage est et restera son interface graphique qui repoussera tous les débutants dans le domaine de la supervision. Mon choix s'est donc porté sur Centreon, an de bénécier d'une supervision complète, avec également des possibilités de métrologie simple (ceci ne nous intéresse pas vraiment), les générations de congurations automatiques, et son interface intuitive en font un outil de choix à mettre en place. 3.2.4 La solution retenue : Centreon Enterprise Server Centreon est une marque de la société Meréthis. Outre les arguments présentés précédemment et qui ont conditionné mon choix, il fallait se décider sur la version à installer. Suite à des recherches plus approfondies et aux conseil de Vincent BEAUVAL, je me suis penché sur une variante de la solution, à savoir : Centron Entreprise Server. Finit les installations "brique par brique", rappelons qu'à la base Centreon est une surcouche de Nagios, et donc logiquement il fallait procéder à une installation complète de Nagios (plugins..) puis à l'installation de Centreon. Grâce à CES, on retrouve le meilleur de la suite Centreon dans une solution ecace, complète et maintenue au sein d'un même package. L'intérêt est bien entendu de déployer rapidement les outils nécessaires à notre supervision vis-à-vis de notre infrastructure. La solution est présentée sous la forme d'une image ISO, on peut alors la graver pour procéder à l'installation, ou tout simplement créer une machine virtuelle basée sur celle-ci. Une fois installée (comptez une vingtaine de minutes), CES est prêt à l'emploi. Il est composé des diérents outils suivants : 1. Un noyau Linux CES est basé sur la distribution Centos 6.5, elle-même basée sur RedHat Enterprise Linux (REHL). Le principal avantage vient de l'outil YUM qui facilite l'exploitation et la gestion des paquets au format RPM a , toutes les dépendances sont automatiquement calculées par YUM, il n'est donc pas nécessaire de vérier les versions de chaque paquet. Un simple "yum update" permet de mettre à jour tous les éléments de CES. a. Redhat Package Management 2. Un Ordonnanceur (moteur central) Depuis sa dernière release en date (mars 2014),CES propose le choix de deux ordonnanceurs, le premier Nagios le plus classique connu de tous, et le second Centreon Engine, développé par les équipe de Meréthis. Celui-ci ore une alternative au moteur central Nagios, mais est cependant basé su Nagios 3.2. C'est un véritable challenge que se sont lancés les équipes de Meréthis, en ne cachant pas qu'ils souhaitent à long terme remplacer Nagios par leur propre ordonnanceur. 30 3.2. L'ASPECT MONITORING 3. Un Broker Un Broker est un module chargé de remonter les informations dans la base de données. Initialement CES ne proposait que ndOutils, qui allait de pair avec Nagios. Mais depuis l'arrivée de Centreon Engine, Meréthis a également développé son propre module, à savoir Centreon Broker. 4. Une IHM intuitive Ne nous attarderons pas ici, une description a déjà été faite au préalable, il s'agit bien évidemment de Centreon lui-même, qui fournit une interface simpliée, pour rendre la consultation de l'état du système accessible aux utilisateurs, également à présent les informations et l'administration des ordonnanceurs sont inclus dans l'interface (sous le nom de Monitoring Engine). 5. Un Serveur HTTP CES propose la version propose la version la plus récente de APACHE (la version 2) qui est actuellement le serveur HTTP le plus utilisé pour le développement. Son support Multi-plateformes ainsi que les processus légers UNIX en font un incontournable. 6. Une base de données et son SGBD Une base de données est installée an de permettre la remontée des données à l'aide du Broker. An d'innover et de changer du classique Mysql Server, Meréthis décide d'inclure suite à une conférence sur MySQL et MariaDB, le second à sa suite CES pour des raisons de qualité et de performances. MariaDB se base sur le code source de MySQL 5.1, il est donc 100 % compatible avec celui-ci et dispose des mêmes dépendances (par exemple si l'on veut que PHP5 dialogue avec le serveur MariaDB il faut installer le paquet " php5-mysql"). Diérentes versions du package CES sont ainsi proposées. La version Standard est Open Source, elle est donc libre et gratuite. Les autres versions quand à elles nécessitent une souscription annuelle, ces versions proposent un support et donnent également accès à des sondes et des modèles complémentaires touchant la partie matérielle. Nous nous contenterons de la version Standard qui semble parfaitement répondre à nos attentes. 3.2.5 Le protocole de supervision An de superviser des hôtes, il faut bien évidemment un serveur central relié à la totalité des hôtes. Le véritable problème qui se pose par la suite, comment faire communiquer ecacement ce serveur central avec les hôtes à superviser ? Entre en jeu la notion de protocole de supervision, qui indépendamment de la plateforme et/ou du type de matériel devra assurer la communication entre les acteurs précédents. SNMP nous avait été plus que suggérée lors de la présentation du sujet de stage par notre tuteur. Le chapitre suivant explique les diérents mécanismes qui entrent en jeu lors de l'utilisation du protocole SNMP, ainsi que ses avantages qui ont conduit à son utilisation. 31 Chapitre 4 Le protocole solution pour la supervision en réseau 4.1 Présentation de Simple Network Management Protocol Un chapitre entier est dédié à l'étude de ce protocole sur lequel repose l'ensemble des requêtes eectuées lors de la collecte des informations concernant les imprimantes (et multifonctions) en réseau. SNMP est un protocole de gestion de réseaux proposé par l'IETF 1 , un groupe informel et international, ouvert à tout individu et participant à l'élaboration de standards Internet). Il reste actuellement le protocole le plus couramment utilisé pour la gestion des équipements en réseaux. SNMP est écrit en ASN.1 2 , un standard international spéciant une notation qui est destinée à décrire des structures de données. Comme son nom l'indique SNMP est un protocole assez simple, mais sa principale force réside dans le fait de pouvoir gérer des périphériques hétérogènes et complexes sur le réseau. De ce fait ce protocole peut également être utilisé pour la gestion à distance des applications : bases de donnée,serveurs, logiciels... L'environnement de gestion SNMP est constitué de plusieurs composantes : Le Manager (station de supervision) exécute les applications de gestion qui contrôlent les éléments réseaux, la plupart du temps le manager est un simple poste de travail Les éléments actifs du réseau, sont les équipements que l'on cherche à gérer (switchs, serveurs...) La MIB (Management Information Base), est une collection d'objets résidant dans une base d'information virtuelle Le Protocole, qui eectue la relation entre le Manager et les éléments actifs Chaque élément actif dispose d'une entité que l'on appelle un "agent", qui répond aux requêtes du Manager. 32 4.2. LES PRINCIPAUX ÉLÉMENTS Figure 4.1 Schéma SNMP de communication de base 4.2 Les principaux éléments 4.2.1 Le Manager Rappelons que le Manager se trouvera sur un machine d'administration (un poste de travail en général). Il reste un client avant tout, étant donné que c'est lui qui envoie les diérentes requêtes aux agents. Il devra disposer d'une fonction serveur, car il doit également rester à l'écoute des alertes que les diérents équipements sont susceptibles d'émettre à tout moment. Si l'on se base sur le schéma précédent, l'administrateur peut observer correctement le comportement de ses diérents équipements en réseau. Le Manager dispose d'un serveur qui reste à l'écoute sur le port UDP 162 ainsi que d'éventuels signaux d'alarme appelés des "traps". Le Manager peut tout autant être installé sur une machine de type Windows, qu'une machine de type UNIX. 4.2.2 Agent SNMP L'agent est un programme qui fait partie de l'élément actif du réseau. L'activation de cet agent permet de recueillir la base de données d'informations et la rend disponible aux interrogations du Manager SNMP. Ces agents peuvent être standards (Net-SNMP par exemple) ou encore spécique à un fournisseur (HP insight agent par exemple). 1. Internet Engineering Task Force 2. Abstract Syntax Number 1 33 4.3. DES INFORMATIONS STRUCTURÉES Cet agent doit rester à l'écoute d'un port particulier, le port UDP 161. Les principales fonctions d'un agent SNMP : Collecter des informations de gestion sur son environnement local Récupérer des informations de gestion tel que déni dans la MIB propriétaire Signaler un évènement au gestionnaire Par ailleurs même si la principale fonction de l'agent est de rester à l'écoute des éventuelles requêtes du Manager et y répondre si il y est autorisé, il doit également être capable d'agir de sa propre initiative, s'il a été conguré. Par exemple, il pourra émettre une alerte si le débit d'une interface réseau, atteint une valeur considérée par l'administrateur comme étant critique. Plusieurs niveaux d'alertes peuvent ainsi être dénis, selon la complexité de l'agent (température du processeur, occupation disque dur, utilisation CPU...). Figure 4.2 Les échanges entre le Manager et l'Agent 4.3 Des informations structurées 4.3.1 Management Information Base Chaque agent SNMP maintient une base de données décrivant les paramètres de l'appareil géré. Le Manager SNMP utilise cette base de données pour demander à l'agent des renseignements spéciques. Cette base de données commune partagée entre l'agent et le Manager est appelée Management Information Base (MIB). Généralement ces MIB contiennent l'ensemble des valeurs statistiques et de contrôle dénis pour les éléments actif du réseau. SNMP permet également l'extension de ces valeurs standards avec des valeurs spéciques à chaque agent, grâce à l'utilisation de MIB privées. Un chier MIB est écrit en utilisant une syntaxe particulière, cette syntaxe s'appelle SMI 3 , basée sur ASN.1 tout comme SNMP lui-même. En résumé, les chiers MIB sont l'ensemble des requêtes que le Manager peut eectuer vers l'agent. L'agent collecte ces données localement et les stocke, tel que déni dans la MIB. Ainsi le Manager doit être conscient de la structure (que celle-ci soit de type standard ou privée)de la MIB an d'interroger l'agent au bon endroit. 3. Structure of Management Information 34 4.3. DES INFORMATIONS STRUCTURÉES 4.3.2 Structure d'une MIB et Object IDentier Rappelons que la MIB est une collection d'informations pour la gestion des éléments du réseau. Sa structure est une arborescence hiérarchique dont chaque noeud est déni par un nombre ou un Object IDentier (OID). Chaque identiant est unique et représente les caractéristiques spéciques du périphérique géré. Lorsqu'un OID est interrogé, la valeur de retour n'est pas un type unique (texte,entier,compteur,tableau...) Un OID est donc une séquence de chires séparés par des points. Une MIB est un arbre très dense, il peut y avoir des milliers d'OID dans la MIB. Figure 4.3 Structure de l'arborescence d'une MIB Cet exemple illustre d'ailleurs un object typique qui est déclaré dans la RFC1213, à savoir le "sysDescr" (une description du périphérique interrogé) dont l'OID s'écrit .1.3.6.1.2.1.1.1. Une petite particularité est à signaler dans la MIB il s'agit de la branche "private" aussi appelée "private enterprises" (dont l'OID est 1.3.6.1.4.1). Cette branche permet à chaque entreprise de gérer sa MIB spécique. Chaque entreprise se voit attribuer un OID unique et se retrouve alors à la charge de la gestion de sa branche. Les diérents OID d'entreprises sont alloués par l'IANA 4 qui est l'organisation dont le rôle est la gestion de l'espace d'adressage IP d'Internet, ainsi que d'autres ressources partagées de numérotation qui sont requises par des protocoles de communication sur Internet. 4. Internet Assigned Numbers Authority 35 4.4. LES PARAMÈTRES D'INTERROGATIONS 4.4 Les paramètres d'interrogations 4.4.1 Les paquets à installer Nous avons vu au préalable,quels éléments nous avons besoin an d'eectuer des requêtes SNMP, il faut s'assurer que notre Manager dispose d'une environnement SNMP, pour se faire le mieux est d'installer et de congurer un serveur SNMP en utilisant la solution open-source "net-snmpd". La suite CES dispose déjà d'un serveur SNMP installé et les congurations sont déjà eectuées de manière à ce le package puisse être déployé immédiatement, et que les requêtes puissent se faire sans problème. 4.4.2 Les diérentes versions de SNMP Depuis la création de SNMP, ce protocole a connu des améliorations importantes. Cependant les précédentes versions (la V1 et la V2C) sont encore les versions les plus utilisées actuellement. Un support de SNMP V3 a récemment été lancé car il est plus sécurisé si on le compare à ses prédécesseurs. 1. SNMP V1 : C'est la première version du protocole. La sécurité de cette version est minimale, car elle basée uniquement sur la chaîne de caractère appelée "communauté". Cette version du protocole est dénie dans les RFC 1155 et 1157. 2. SNMP V2C : C'est un protocole révisé, qui comprend les améliorations de SNMP V1 dans diérents domaines tels que : Les types de paquets Les éléments de structure MIB Les requêtes protocolaires MIB Cependant ce protocole utilise la structure d'administration de SNMP V1 ( à savoir "communauté") d'où le terme SNMP V2C 3. SNMP V3 : Aussi connu sous le nom de version sécurisée de SNMP. SNMP V3 facilite la conguration à distance des entités SNMP. Ces trois versions sont les principales, même si des versions intermédiaires ont vu le jour (SNMP Sec, SNMP V2, SNMP V2U,SNMP V2P), celles-ci ne présentent que des mises à jours mineures plutôt que de véritables améliorations. Actuellement les versions les plus utilisées (par ordre d'utilisation) sont : SNMP V1, SNMP V3 puis SNMP V2C. Malgré tout la version SNMP V1 perdure encore sur les périphériques, plusieurs facteurs explique ce phénomène : Les infrastructures déployées en V1 ne sont plus modiées, tout simplement car cela fonctionnait susamment à l'époque, du coup aucune modication n'y est appliquée Les autres versions de SNMP ont été implémentées tardivement par les diérents constructeurs SNMP V1 demande très peu de ressources sur des petits équipements tels qu'une imprimante ou un Hub 36 4.5. LES REQUÊTES SNMP 4.4.3 Les communautés La notion de communauté est utilisée dans les réseaux administrés à l'aide du protocole SNMP. Elle réunit à la fois le Manager et les diérents agents. Chaque communauté est identiée par un nom de communauté. Par défaut seules les communautés "public" et "private" sont dénies, cependant il est possible de nommer sa propre communauté, ceci à des ns évidents de sécurité et donc de créer son propre domaine d'administration. Ces dénitions de communautés permettent : L'authentication : Consiste à envoyer une requête avec comme mot de passe le nom de la communauté, permettant au récepteur de vérier l'authenticité de ce dernier La politique d'accès : Pas d'accès, read-only ou read-write Le service Proxy : Si les périphériques sont gérées par l'intermédiaire d'un proxy, ce dernier connait les objets utilisés pour gérer la machine mandatée, et gère la politique d'accès adéquat 4.5 Les requêtes SNMP 4.5.1 Les formats de requêtes Commande get-request get-next-request set-request get-reponse trap Action Le Manager SNMP demande une information à un agent Le Manager SNMP demande l'information suivante à un agent Le Manager SNMP met à jour une information sur un agent SNMP L'agent SNMP répond à un get-request ou à un set-request L'agent SNMP envoie une alerte au Manager Les commandes get-request, set-request et get-next-request sont toutes émises par le Manager à destination d'un agent, elles attendent une réponse de type get-response de la part de l'agent. La commande trap quand à elle est une alerte, c'est-à-dire qu'elle sera toujours émise par l'agent vers le Manager, cependant elle n'attend aucune réponse. 4.5.2 SnmpWalk An de tester les requêtes SNMP, le plus simple est de commencer par les requêtes à eectuer en ligne de commande plutôt que de se lancer dans l'exécution de plugins etc... Deux commandes standard existent : SnmpWalk et SnmpGet. Commençons par SnmpWalk. Cette commande permet de récupérer toutes les valeurs d'un OID de type n÷ud, rappelons que la structure est une arborescence donc, si l'OID interrogé n'est pas une feuille, nous allons récupérer toutes les valeurs du sous-arbre (d'où le terme "walk" qui signie parcourt). SnmpWalk obtient ces informations car la commande est dénie comme étant une suite de séquences au format "get-next-request" Pour utiliser cette commande, voici les paramètres à respecter : Listing 4.1 Format de commande SnmpWalk 1 snmpwalk −v < l a v e r s i o n > −c < lacommunaute > < a d r e s s e i p > < o i d > 37 4.5. LES REQUÊTES SNMP Figure 4.4 Exemple de requête SnmpWalk 4.5.3 SnmpGet SnmpGet quand à lui permet de récupérer la valeur d'un OID feuille spécique, donc nous obtiendrons une seule et unique valeur. La syntaxe de la commande est identique à celle de SnmpWalk. Si le SnmpWalk nous permet de trouver les sous-arbres disponibles, la contrainte évidente avec SnmpGet est qu'il faut impérativement savoir quel OID interroger. Pour cette raison, nous utiliserons uniquement la commande SnmpWalk dans la suite de ce projet. Listing 4.2 Exemple d'exécution de la commande SnmpGet 1 2 s n m p g e t −v 2 c −c d e m o p u b l i c t e s t . n e t −snmp . o r g SNMPv2−MIB : : sysUpTime . 0 SNMPv2−MIB : : sysUpTime . 0 = T i m e t i c k s : ( 5 8 6 7 3 1 9 7 7 ) 67 days , 2 1 : 4 8 : 3 9 . 7 7 38 Chapitre 5 Réalisation 5.1 Les outils utilisés La phase de réalisation et de mise en ÷uvre a nécessité l'installation de plusieurs outils dont voici un aperçu : VMware Workstation 10 est ce que l'on appelle un hyperviseur, c'est-à-dire une 1. plate-forme de virtualisation qui permet de faire cohabiter diérents systèmes d'exploitation sur une même machine physique. Il intègre une gestion complète des périphériques ainsi que du son, de la vidéo, la prise en charge réseau...Je me suis servi de cet hyperviseur pour créer ma machine virtuelle avec comme base l'iso CES 3.0, la procédure est détaillée en annexe technique à la n de ce rapport. Pourquoi ne pas utiliser le serveur déjà en production ? Pour des raisons évidentes de sécurité, l'utilisation du serveur existant était à proscrire. De même une duplication aurait pu être eectuée pour les premiers tests, mais CES a bénécié d'une mise à jour au cours de cette année. J'ai donc entrepris l'installation de la dernière version en date tout en m'assurant qu'il serait possible de migrer mon serveur et de le placer en production sans qu'il n'altère celui déjà en place. 2. 3. Notepad ++ est l'un des éditeurs de code source les plus connus, sa coloration syntaxique et sa simplicité en font un outil de choix à garder constamment sous la main. PuTTY est un émulateur de terminal UNIX qui permet de se connecter à distance à une machine ou un serveur, en utilisant les protocoles SSH, Telnet ou Rlogin. L'ensemble des sessions peuvent être automatiquement enregistrées sous forme de rapport an d'être consultées ultérieurement. 39 5.2. DE LA SUPERVISION DES IMPRIMANTES... 4. WinSCP, visuellement il se présente comme un outil de transfert FTP, il permet de lire le contenu des répertoires, d'éditer ou de supprimer des chiers, et surtout d'assurer des copies ou des déplacements de chiers entre la machine hôte, et le poste sur lequel nous sommes connectés, tout cela en se basant sur le protocole SSH. 5. Nmap est un scanneur de port réseau, disponible sous Unix et Windows. Ce logiciel a pour but de détecter les ports réseau ouverts sur une machine, ainsi il permet de détecter si la machine en question est bien présente sur le réseau, et également d'identier les services qui tournent dessus. 6. phpMyAdmin est une interface pour gérer les base de données MySQL, il faut avouer qu'explorer une ou plusieurs base de données dans un terminal n'est pas chose facile. Cette interface permet de naviguer entre les bases, les tables et même d'eectuer des requêtes au format SQL. 5.2 De la supervision des imprimantes... 5.2.1 Notion d'hôte/de groupe d'hôtes Un hôte est un bien matériel que l'on souhaite superviser, dans notre cas une imprimante ou une multifonction en réseau. Auparavant il fallait impérativement congurer les hôtes par le biais de chier de conguration en ligne de commande, ces opérations assez fastidieuses ont été simpliées grâce à Centreon qui à l'aide de champ pré-remplis nous génère le chier de conguration automatiquement. Il sura alors de redémarrer Nagios (par le biais de Centreon également) an que le nouvel ajout soit pris en compte par le serveur. Chaque dénition d'hôte se base sur un template (un modèle pré-créé), il est intéressant de modier un template an de répliquer ses spécications (intervalle de check, notications...) aux hôtes que l'on dénira plus tard s'appuyant sur celui-ci. Un groupe d'hôte à présent, considérons nos imprimantes, il est pertinent de dénir un groupe d'hôte selon chaque marque d'imprimante étant donné que celles-ci partagent des caractéristiques communes et donc se verront attribuer des services communs (cette notion sera dénie dans la section suivante). Tout simplement, prenons un peu de recul, il sera plus simple de dénir un service à un groupe d'hôtes, plutôt que de dénir le même service à chaque hôte. Entre en jeu la notion de parent et d'enfant. 5.2.2 Dénition de commande Une commande sous Nagios, est similaire à une commande UNIX que l'on taperait en ligne de commande an de récupérer des informations. La plupart des commandes s'appuient sur des scripts déjà en place ou à télécharger. 5.2.3 Dénition de service Un service est l'application d'une commande, il faut la congurer avec les arguments à prendre en compte, les intervalles de check et les éventuelles notications à envoyer, si notications il doit 40 5.2. DE LA SUPERVISION DES IMPRIMANTES... y avoir. Il sut ensuite d'appliquer une relation entre le service et un groupe d'hôte, an que tous les hôtes concernés soient check en temps voulu. 5.2.4 Installation de plugins pour Nagios Comme le dit l'adage, il ne faut pas réinventer la roue, de nombreux plugins existent déjà, un site communautaire les recense d'ailleurs : http://exchange.nagios.org/directory/Plugins La majorité des plugins sont écris en Php ou en Perl, des dépendances sont à installer si Nagios ne reconnait pas ces plugins. L'installation est très simple il sut de placer le plugin dans le bon répertoire : "usr/lib/nagios/plugins/", de restart Nagios, puis de dénir une nouvelle commande basée sur le nom du plugin. 5.2.5 Architecture de CES Figure 5.1 Architecture globale de CES Ce schéma illustre parfaitement le mode de fonctionnement, ainsi que les interactions entre les diérents composants de la solution. Centreon notre interface web permet non seulement d'acher les diérents statuts du matériel supervisé, mais surtout de congurer et d'administrer Nagios sans avoir à passer par un terminal. Quelques clics susent à charger une conguration, à rajouter des hôtes, créer des services et des commandes, et également redémarrer le service Nagios. 41 5.3. ... AU DIAGNOSTIC Nagios notre serveur central, ici conguré en mode architecture simple RRDtool quand à lui ne nous intéresse pas vraiment, sa principale fonctionnalité est d'établir des graphes sur les données de performances (utiles pour des serveurs supervisés par exemple). 5.2.6 Le combo Nagios et ndOutils Figure 5.2 Nagios et ndOutils Ndomod et Ndo2db sont deux éléments plus qu'essentiels à la suite CES, leurs rôles principal est la communication entre l'interface web (Centreon) et notre ordonnanceur (ici Nagios). Ils sont regroupés au sein de NdOutils. Ndo2db est un daemon 1 qui permet de récupérer les données remontées par par Ndomod et de les stocker dans une base de données (notre base MariaDb). Ndomod est un module qui permet de remonter les informations d'un ou plusieurs ordonnanceur(s) (selon si le modèle choisit est l'architecture simple ou l'architecture distribuée, avec plusieurs pollers). Attention seules les données de supervision et l'état de l'ordonnanceur seront remontées, les données de performances et les logs, seront quand à eux récupérés via CentCore, et ramener à la base de données via CentStorage (qui ne sont pas représentés sur le graphe précédent). 5.3 ... Au diagnostic 5.3.1 La remontée d'informations dans la base de données Figure 5.3 Base de données Centreon 1. Processus qui s'exécute en arrière-plan 42 5.3. ... AU DIAGNOSTIC Suite à l'installation de CES, et lors de la conguration de la base de données (voir Annexe technique) je remarque que celle-ci se décompose en deux sous-bases : Centreon_ status, et Centreon_ storage. Il est conseillé de ne pas renommer ces bases et de laisser les paramètres par défaut même si les liens symboliques sont correctement établis lors de la conguration. D'ailleurs en cas de nouvelle installation ou de migration du superviseur il sura de migrer ces deux bases de données. La base Centreon_ storage contient les données de performances si le besoin est, d'établir des graphes de performances par exemple. Figure 5.4 Centreon status La base Centreon_ status est celle qui m'intéresse, elle regroupe les dénitions d'hôtes, de commandes, de services, et surtout les informations de supervisions stockées. 60 tables composent cette base de données, il m'a fallu un peu de temps pour trouver où étaient stockées précisément les données recherchées vis-à-vis des plugins utilisés. Il s'avère que les données intéressantes se trouvent dans trois tables séparées : nagios_ services, nagios_ hosts et nagios_ servicestatus. Le but était de remonter ces informations en entrant l'adresse IP d'une imprimante, la jointure m'a semblé la plus adaptée. Pour rappel la commande " INNER JOIN" est un type de jointure commune pour lier des tables entre elles, elle permet de retourner les enregistrements lorsqu'il y a au moins une ligne de chaque colonne qui correspond à la condition donnée en entrée. Concrètement dans notre cas si une adresse IP est donnée (10.1.2.14 par exemple) Listing 5.1 Requête de récupération des données brutes 1 2 3 4 5 s e l e c t output from n a g i o s _ s e r v i c e s t a t u s INNER JOIN n a g i o s _ s e r v i c e s ON ( n a g i o s _ s e r v i c e s t a t u s . s e r v i c e _ o b j e c t _ i d = n a g i o s _ s e r v i c e s . s e r v i c e _ o b j e c t _ i d ) 43 5.4. 6 7 8 EN PASSANT PAR LA DÉCOUVERTE RÉSEAU INNER JOIN n a g i o s _ h o s t s ON ( n a g i o s _ s e r v i c e s . h o s t _ o b j e c t _ i d = n a g i o s _ h o s t s . h o s t _ o b j e c t _ i d ) where a d d r e s s = ’ 1 0 . 1 . 2 . 1 4 ’ Figure 5.5 Données brutes en sortie Ces données brutes peuvent à présent être exploitées par mon collègue, une mise en forme sera à eectuer avant de retranscrire les données au sein de l'interface web. 5.4 En passant par la découverte réseau Appelé Discover SNMP, le principe est simple, à partir d'une plage d'adresses ip (les sous réseaux du Conseil Général) le script va lancer un balayage réseau an de déterminer toutes les imprimantes/multifonctions qui s'y trouvent. Je ne suis pas l'auteur de ce script, je tiens à remercier Pierre-Louis Corrion qui l'a rédigé, qui a été un des précurseurs de l'utilisation du protocole SNMP au sein de la DEMS. En eet ce script couple l'outil NMAP aux OID de descriptions des diérentes marques d'imprimantes et se décompose donc en deux étapes : 1. Scanner les ports avec Nmap an de détecter la présence d'un matériel 2. Si le matériel détecter est une imprimante, interroger l'oid de description an de récupérer son nom An d'assurer une certaine cohérence et dans un souci de compréhension, un chier texte appelé sites.txt (qui regroupe l'ensemble des noms donnés aux sites du Conseil Général, et les ip correspondantes à ces sites) est requit par le script shell. Nous avons entrepris d'utiliser ce script comme base d'outil pour eectuer le discover SNMP, un travail préliminaire a dû être eectué, en associant chaque site (adresse IP) à une variable. Parallèlement l'interface web devra présenter les diérents sites comme une sorte de ltre par régions. Voici un exemple de chier de sortie pou r un discover SNMP eectué à la DEMS : Listing 5.2 Discover SNMP 1 2 3 4 5 6 10.1.0.0 10.1.0.0 10.1.0.0 10.1.0.0 10.1.0.0 DI DI DI DI DI Lan1 ; 1 0 . 1 . 2 . 1 0 ; p r 1 5 6 2 1 0 . i n t r a n e t . cg974 . f r ; HP L a s e r J e t 400 c o l o r M451dw ; Lan1 ; 1 0 . 1 . 2 . 1 4 ; n p i 1 6 4 2 6 8 . i n t r a n e t . cg974 . f r ; HP L a s e r J e t 400 MFP M425dn ; Lan1 ; 1 0 . 1 . 2 . 1 5 ; e t 0 0 0 4 0 0 d 1 5 5 7 7 . i n t r a n e t . cg974 . f r ; Lexmark T640 7919 C76 LS Lan1 ; 1 0 . 1 . 2 . 5 2 ; mfp07678474 . i n t r a n e t . cg974 . f r ; TOSHIBA e−STUDIO356 ; Lan1 ; 1 0 . 1 . 2 . 7 0 ; km8165d5 . i n t r a n e t . cg974 . f r ;KM−2560; L'intérêt d'une telle requête est tout simplement de rechercher les imprimantes actives sur un des sous-réseaux du Conseil Général, placé en paramètre, et également de s'apercevoir si celles-ci sont correctement nommées ou non. A plus grande échelle on pourrait établir un mapping de ces imprimantes. 44 5.5. DU SERVEUR DE DÉVELOPPEMENT AU SERVEUR DE PRODUCTION 5.5 Du serveur de développement au serveur de Production On appelle serveur de production, le serveur sur lequel sera installé l'application une fois terminée, donc accessible aux utilisateurs naux. Par opposition, le serveur de développement, celui sur lequel j'ai eectué mes diérents tests, qui n'était ni plus ni moins que mon poste de travail personnel. Il faut procéder à la migration de la machine sur Vcenter. Voyons quelques petites notions avant de procéder : vSphere est un hyperviseur "bare-metal" c'est-à-dire directement installé sur le serveur physique qu'il partitionnera en plusieurs machines virtuelles. Sur chaque LAME 2 est installé vSphere. 5 LAME sont présents dans la salle serveur donc 5 vSphere. VMware vCenter Server est un logiciel de gestion de serveurs et de virtualisation qui ore une plate-forme centralisée. vCenter regroupe donc la totalité des vSphere au sein d'une même interface de contrôle et d'administration. Le plus gros avantage est la répartition des charges entre les vSphere, si un serveur consomme trop de CPU il sera automatiquement basculé sur un autre vSphere, tout ceci est bien évidemment transparent aux utilisateurs, pour qui les applications continuent de fonctionner. C'est l'un des principes de la prévention de pannes. Figure 5.6 Centralisation des serveurs virtuels La première étape de la migration est la modication de la compatibilité matérielle, rappelons que le serveur CES était stocké en local sur ma machine personnelle , il fallait donc la migrer 2. serveur physique 45 5.6. LES DIFFICULTÉS RENCONTRÉES vers le DataCenter 3 . Le fait d'avoir créé et paramétré cette machine sous Workstation 10 est un avantage, en eet la migration (upload) est simpliée depuis cette version. Ne pas oublier de créer un clone de la machine qui possèdera les modications matérielles de compatibilité, ne surtout pas altérer sa machine existante. Il faut se rendre ensuite dans la partie upload, et indiquer les informations du serveur sur lequel je souhaite migrer la machine, une fois que cela est indiqué je peux sélectionner l'emplacement d'hébergement sur le Vcenter, et plus particulièrement un ESX-LUN. L'upload se lance, la migration s'eectue assez rapidement. 5.6 Les dicultés rencontrées 5.6.1 Protection du réseau La progression des attaques est en croissance exponentielle sur Internet, peu importe l'échelle de son entreprise, la protection du réseau est plus que jamais à l'ordre du jour. Il va de soi qu'avec les services oerts par la DEMS (le serveur de gestion des bourses par exemple), il faut éviter toutes intrusions ou menaces potentielles , que celles-ci viennent de l'extérieur (DDOS..) ou de l'intérieur (prenons le cas d'une clé usb infectée qui en étant branchée à un poste de travail, lancerait une contamination et une propagation de malwares sur le réseau). Des politiques de sécurité ont du être appliquées que cela soit par choix personnel ou par nécessité. Ces règles sont dénies par les administrateurs du SAR et une fois mises en place à appliquer la tolérance zéro. En eet malgré nos types de comptes sur l'AD (malgré l'OU dans lequel nous nous trouvons, qui nous attribue un certain nombres de droits sur nos postes par rapport aux utilisateurs "lambda"), nous devons faire face aux mêmes contraintes que les autres agents du CG dès lors que l'on touche au réseau. Je ne peux pas considérer que ces contraintes soient de la sur-protection réseau, elles sont justes. Vincent Beauval m'a rapporté qu'en eet, il y avait des journées où des centaines d'intrusions étaient lancées contre le réseau du Conseil Général, j'ai alors pris conscience réellement de la nécessité d'appliquer ces termes de sécurité. J'avais commencé à installer mon serveur de supervision sur la même machine virtuelle que Kévin TAOCHY, en voulant lancer mes premières requêtes, je me suis aperçu que rien ne passait, à part les requêtes vers Localhost. Rapidement j'ai compris qu'il s'agissait alors d'un problème de ports UDP qui n'étaient pas ouverts, et comme ce serveur se trouvait sur un réseau isolé, j'ai dû entreprendre alors l'installation sur ma machine personnelle et d'envisager une migration future sur un serveur de production (ce qui a été validé et eectué). Une fois que ma machine a été placée sur le serveur de production, je me suis retrouvé avec un souci assez particulier, même si la conguration réseau avait été placée sur DHCP, je n'avais aucune adresse IP, la solution a été de dénir une seconde interface réseau, de la placer en DHCP, et de forcer le lancement de la conguration au démarrage, il aurait été dommage de perdre la conguration réseau à chaque reboot serveur (merci à Florent PAYET pour son aide). De ce fait nous avons dû interagir assez régulièrement avec les membres de SAR dès lors qu'un problème lié au réseau était soupçonné. 3. Centre de traitement des données où sont regroupés les équipements 46 5.6. LES DIFFICULTÉS RENCONTRÉES 5.6.2 Respect des conventions de nommage Si les conventions de nommage ont été établies assez récemment, elles ne sont malheureusement pas respectées. La première étant le renommage des imprimantes sur le réseau, seule une soixantaine d'imprimantes a été nommée correctement, je me suis concerté avec François BOYER, pour nalement décider qu'on ne superviserait dans un premier temps que les imprimantes correctement nommées. De même une communauté SNMP a été dénie par SAR, malheureusement la majorité reste encore actuellement sur la valeur par défaut à savoir "public", j'ai dû grâce à l'outil Top-Access, me connecter en session administrateur sur ces périphériques an de changer la communauté par celle qui était nécessaire pour mes requêtes. 5.6.3 Livrables Nous avons nommé notre projet DiagMoustik, un petit jeu de mots entre le mot diagnostic et le petit insecte des tropiques tant détesté. Les livrables représentent le résultat nal de notre prestation, c'est-à-dire tout ce que nous avons produit pendant ces 6 mois de stages et qui sera remis entièrement à la DEMS. 5.6.3. A Architecture générale de l'outil Regroupons à présent le travail de mon collègue et ce que j'ai produis. Les deux schémas suivants très explicites ont été réalisé par Kévin TAOCHY, ils illustrent parfaitement la jonction entre ses travaux et les miens. Figure 5.7 Architecture de l'application DiagMoustik 47 5.6. LES DIFFICULTÉS RENCONTRÉES Figure 5.8 Illustration du principe de fonctionnement 5.6.3. B Machines virtuelles Déjà placé sur un serveur en production, la machine virtuelle où est installé le serveur central CES possède à présent une adresse IP xe, et eectue ses requêtes régulièrement. Le serveur physique sur lequel elle est placée a largement les ressources nécessaires ainsi que l'espace de stockage. Cette machine a été fournie avec ses plugins, les paramètres, les hôtes, les diérentes commandes et services. La seconde machine virtuelle (celle de mon collègue) été déjà placée sur un sous-réseau (qui était isolé certes), mais les ports sont à présent ouverts, et les communications avec ma machine virtuelle ne posent plus aucun problème. 5.6.3. C Documentations An de pérenniser l'outil il faut que d'autres que Kévin TAOCHY et moi-même soient capable de l'utiliser lorsque nous serons partis, dans cette optique plusieurs documentations sont en cours de rédactions. Également des commentaires ont été écris dans les diérents scripts, an que ceux-ci puissent être modiés au besoin. Documentation technique, qui reprend l'ensemble des schémas d'architecture ainsi que les technologies utilisées Manuel d'utilisation, qui dénit les diérentes vues côté utilisateur (les techniciens) an que ceux-soient soient parfaitement au courant des fonctionnalités présentes, quels boutons utiliser pour arriver à tel ou tel résultat... Procédure d'installation qui détaille pas à pas comment arriver à avoir un serveur stable, fonctionnel et donc prêt à être déployé 48 Chapitre 6 Conclusion 6.1 Bilan Ce stage à la DEMS a commencé le 6 janvier 2014 et se terminera le 7 juillet de la même année (en eet ce rapport sera rendu deux semaines avant la n de mon stage), j'ai été placé sous la tutelle de François Boyer au sein du Service Support Utilisateurs. Ce stage de n d'études a été ma première véritable expérience en entreprise, en eet jusqu'à présent notre cursus universitaire nous avait oert de nombreuses notions dans divers domaines, que j'ai enn pu mettre en pratique sur le terrain. Les premiers jours furent assez complexes, le temps de trouver mes marques sans doute, il a fallu réaménager le bureau de l'assistant de manager de notre chef de service : Laurent Prunella an de nous attribuer un bureau xe à Kévin TAOCHY et moi-même. Malgré cela, mon intégration fut très rapide, notamment grâce à Anise FONTAINE et à Marie-Paule CRESCENCE qui se sont comportées comme de véritables mères pour nous à la DEMS. En l'espace d'une semaine nous avons visité l'ensemble des services, été présentés aux agents de la DEMS qui étaient présents (une bonne majorité était encore en congé lors de ce début de mois de janvier), et visités également le Data-Center du Conseil Général. Une fois intégré, j'ai fait face au quotidien rythmé du SSU, des journées dynamiques avec pleins d'imprévus, gérées parfaitement par les agents du service, habitués à ce genre de situations. Nous avons été placés à deux sur ce projet, Kévin TAOCHY et moi-même, j'avais pour ma part lors de mon entretien mis l'accent sur mes capacités et ma volonté à mettre en pratique mes notions sur l'administration des systèmes et des réseaux, j'ai donc été ravi lorsque l'on m'a annoncé que cela serait la partie dont je serais en charge. J'étais loin de me douter de l'ampleur et surtout de l'échelle de l'architecture que je devais respecter. Pour rappel le Conseil Général est réparti sur environ 150 sites avec près de 5000 agents. J'avais déjà créé des machines virtuelles (linux pour me parfaire dans les systèmes UNIX) et Mac-OsX Lion (an de développer des applications pour Ios via Xcode), le projet de mise en place d'un serveur CES ma permis d'utiliser une autre version de Linux (Centos), diérente de celle que j'avais l'habitude d'utiliser (Debian). J'ai appris qu'au sein d'une entreprise on ne peut se permettre de tester une solution dont on ne connait pas les résultats ni l'ecacité, il faut se baser sur l'existant, et à ce niveau, forts de leur expérience passée, Vincent BEAUVAL et Florent PAYET ont su me guider. J'ai pu constaté également que les diérents agents de la DEMS doivent constamment rester à la pointe des technologies qu'ils étudient ou utilisent, forcés dans un monde où l'informatique est en plein essor d'assurer la qualité de service dont dépend la collectivité. 49 6.2. APPORT PERSONNEL Plus qu'un outil, l'informatique fait désormais partie intégrante du quotidien des agents, la DEMS tend à favoriser son utilisation, an que tous voient le côté ludique et pratique et non une contrainte. Concernant le projet en lui-même il a été intéressant de constater que l'intérêt ne venait pas uniquement des techniciens du SSU, mais de toutes les personnes qui nous ont posés des questions sur l'évolution de ce projet, et qui ont su trouver un côté positif à cette mise en place, je pense notamment à Chris RAMASSAMY du SRM. Je n'ai pas à me plaindre des conditions de travail, bien au contraire, en réalité je ne m'attendais pas à trouver des agents aussi joviaux qui prennent plaisir à travailler et à instaurer une ambiance aussi conviviale, merci à Jean-Pierre JOB et à François BOYER pour leur bonne humeur, la DEMS est un peu comme une grande famille dont les membres se côtoient et interagissent chaque jour, et savent qu'ils peuvent compter les uns sur les autres. Les échanges et partages de connaissances ont favorisé l'entente avec les autres services, une petite pensée à Jimmy OMERALY, Bertrand CHANE et Maurice REVEL avec qui chaque jour, un petit débat était lancé concernant les technologies actuelles. Pour conclure cette partie, je dirais que ce stage a été non seulement une expérience professionnelle, mais également une expérience humanisante. 6.2 Apport personnel Anticiper les besoins, voilà les maitres-mots que je retiendrais de ce stage. Au fur et à mesure du cheminement et de l'avancée de ce projet, j'ai commencé à raisonner autrement, étant placé chef de projet en binôme avec mon collègue, cela a permis de développer notre esprit d'équipe. Avoir une vision d'ensemble et une prise de recul susante pour aborder une situation concrète, sont à présent ce que j'estime être non pas des qualités, mais des compétences élémentaires pour un ingénieur. Il a été plus qu'enrichissant pour moi de toucher à des technologies et solutions propriétaires, moi qui étais convaincu que l'open-source remplacerait la plupart des solutions payantes à l'heure actuelle, je me suis rendu compte que ces logiciels sur mesure facilitaient le travail des administrateurs, surtout en matière de maintenance, en eet une fois mis en place, les débogages sont très rares, et on peut ainsi se consacrer à la valeur ajoutée et à la qualité de services à apporter. Ce stage m'a permis de me concilier avec l'idée de devenir administrateur systèmes et réseaux, la mise en place de serveurs, la gestion de parc informatique, l'établissement de diagnostics, la mise en oeuvre de sécurité... tant de notions qui permettent de valoriser ce métier à part entière. Je pense d'ailleurs qu'il serait judicieux que je passe des certications telles que Microsoft, Linux et Cisco, an d'établir un véritable preuve sur mon niveau et mes aptitudes en plus de mon bagage technique qui s'est peauné durant mes six mois de stage. 6.3 Perspectives futures Je pense qu'il faudra compter deux bons mois de test, avec le serveur de supervision et l'application en production, an de s'apercevoir des réels bienfaits de leur mise en place. Je regrette que nous nous soyons fait rattraper ainsi par le temps, les périodes estimées dans le planning prévisionnelle étaient plus ou moins correctes, mais les projets secondaires ont été très 50 6.3. PERSPECTIVES FUTURES chronophages. Malheureusement la version web mobile n'a pas pu être abordée, il n'était pas convenu à la base de développer à la fois une version pour Ios et une version sous Android, mais bien une version web mobile, basée sur un framework tel que " Jquery mobile" que j'ai déjà eu l'occasion d'utiliser lors de mon parcours universitaire. Le fait d'utiliser la technologie "responsive design" aurait été un véritable atout, pour qu'à la fois l'application fonctionne sous postes de travail, smartphones, voire également les tablettes. Si les mérites de ce projet sont correctement remontés, il faudra développer cette version. Autre chose, en prenant un peu de recul vis-à-vis du parc des imprimantes, je me suis rendu compte que sur le long terme même en mutualisant au maximum les imprimantes pour les remplacer par des multifonctions, il arrivera un moment où le nombre de sites physiques augmentera considérablement, et il sera alors intéressant d'installer un second serveur poller Nagios, an de répartir correctement les charges et d'instaurer ainsi une architecture distribuée. Également si un réel engouement se présente pour le projet, pourquoi ne pas mettre en place le système de Trap SNMP, an que des alertes soient remontées en cas d'états anormaux ou de défaillances sur les biens matériels, évidemment il faut se projeter dans l'avenir, cette solution serait pertinente uniquement si le parc des imprimantes augmenterait de manière signicative, ne pas oublier la contrainte humaine, si des alertes sont envoyées il faut bien que quelqu'un les reçoive, serait-il alors judicieux d'associer un agent du SAR, ou plutôt la totalité des techniciens du SSU ? 51 Table des gures 1.1 1.2 Organigramme du Conseil Général de la Réunion . . . . . . . . . . . . . . . . . . Organigramme DEMS fonctionnel et nominatif . . . . . . . . . . . . . . . . . . . 10 11 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 C÷ur de réseau du Conseil Général . . . . . . . . C÷ur de LAN . . . . . . . . . . . . . . . . . . . . Exemple de che de signalement d'incident . . . Hétérogénéité du parc d'imprimantes . . . . . . Gestion de Projet . . . . . . . . . . . . . . . . . . Graphe systémique de Patrick IRSAPOULLE . . Planning prévisionnel . . . . . . . . . . . . . . . . Modèle en Cascade . . . . . . . . . . . . . . . . . Validation mensuelle de la progression du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17 19 19 20 21 22 22 22 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Méthode du Polling . . . . . . . . . . . . . . . Méthode du heartbeat . . . . . . . . . . . . . Ibm Tivoli Software . . . . . . . . . . . . . . HP Openview . . . . . . . . . . . . . . . . . . Computer Associates Technologies Unicenter HP Openview . . . . . . . . . . . . . . . . . . Métrologie ou Supervision ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 26 27 27 27 27 28 4.1 4.2 4.3 4.4 Schéma SNMP de communication de base Les échanges entre le Manager et l'Agent . Structure de l'arborescence d'une MIB . . Exemple de requête SnmpWalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 34 35 38 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 Architecture globale de CES . . . . . . . . Nagios et ndOutils . . . . . . . . . . . . . Base de données Centreon . . . . . . . . . Centreon status . . . . . . . . . . . . . . . Données brutes en sortie . . . . . . . . . . Centralisation des serveurs virtuels . . . . Architecture de l'application DiagMoustik Illustration du principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 42 42 43 44 45 47 48 A.1 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 B.1 B.2 B.3 B.4 B.5 B.6 57 57 58 58 58 59 Créer une nouvelle machine, sélectionner "avancée" . . . . . . . . . . . . . . Laisser la compatibilité matériel par défaut . . . . . . . . . . . . . . . . . . Sélectionner " I will install the operating system later" . . . . . . . . . . . Congurer le nombre de processeurs : 1 processeur double coeur est susant Congurer la mémoire vive : 512 Mo sont amplement susant . . . . . . . . Sélectionner le mode Bridge, an d'avoir une véritable adresse ip à xer . . 52 . . . . . . . . . . . . . . . . . . TABLE DES FIGURES B.7 B.8 B.9 B.10 B.11 B.12 B.13 B.14 B.15 B.16 B.17 B.18 B.19 B.20 B.21 B.22 B.23 B.24 B.25 B.26 B.27 B.28 B.29 B.30 B.31 B.32 B.33 B.34 B.35 B.36 B.37 B.38 B.39 B.40 B.41 B.42 B.43 B.44 B.45 B.46 B.47 B.48 Créer un nouveau disque virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Go sont recommandés pour un CentOs . . . . . . . . . . . . . . . . . . . . . . Finaliser l'installation, ne pas démarrer la machine . . . . . . . . . . . . . . . . . Éditer les paramètres de la machine et dans la partie CD/DVD, sélectionner l'iso de CES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lancer une nouvelle installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Première interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sélectionner la langue et le clavier du système . . . . . . . . . . . . . . . . . . . . Sélectionner périphériques de stockage basiques . . . . . . . . . . . . . . . . . . . Abandonner les données, an de procéder au partitionnement automatique . . . . Sélectionner le fuseau horaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remplacer le système actuel (même si aucun n'est présent) . . . . . . . . . . . . Installer un serveur central avec base de données . . . . . . . . . . . . . . . . . . Choisir le duo Nagios/ndOutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . L'installation des dépendances commence . . . . . . . . . . . . . . . . . . . . . . L'installation est enn terminée . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redémarrer la machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CES est bien basé sur CentOs 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . Une fois connecté à la session, repérer l'adresse ip . . . . . . . . . . . . . . . . . . Le paramétrage se poursuit dans un navigateur web (taper l'adresse ip dans la barre d'url) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les diérents modules se chargent . . . . . . . . . . . . . . . . . . . . . . . . . . Sélectionner Nagios comme serveur central . . . . . . . . . . . . . . . . . . . . . . Laisser les répertories par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . Vérier que ndOutils est le Broker sélectionné . . . . . . . . . . . . . . . . . . . . Dénir ses paramètres d'administration . . . . . . . . . . . . . . . . . . . . . . . Dénir les informations de la base de données . . . . . . . . . . . . . . . . . . . . Vérication des paramètres entrés . . . . . . . . . . . . . . . . . . . . . . . . . . . On peut à présent se connecter à Centreon . . . . . . . . . . . . . . . . . . . . . . Modication d'un hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les diérents groupes d'hôtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemple de commande s'appuyant sur un plugin . . . . . . . . . . . . . . . . . . Modication d'un service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relation entre un service et un groupe d'hôtes . . . . . . . . . . . . . . . . . . . . Modication de la compatibilité hardware . . . . . . . . . . . . . . . . . . . . . . Clone de la machine avec modications . . . . . . . . . . . . . . . . . . . . . . . . Sélection d'un emplacement sur le DataCenter . . . . . . . . . . . . . . . . . . . . Sélection d'un ESX-LUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagnostic imprimante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagnostic poste de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lancement d'une commande de controle à distance . . . . . . . . . . . . . . . . . Discover SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Résultat d'un discover à la DEMS . . . . . . . . . . . . . . . . . . . . . . . . . . 53 59 59 60 61 61 61 62 62 62 63 63 63 64 64 64 65 65 65 66 66 66 66 67 67 67 67 67 68 68 68 69 69 69 70 70 70 71 71 72 72 73 73 Annexe A Webographie Developpez.com http://caleca.developpez.com/tutoriels/protocole-snmp/ WIKI MONITORING-FR.ORG http://wiki.monitoring-fr.org/zabbix/zabbix-snmp-host SUGAR.BUG http://eric.coquard.free.fr/atelier/supervision/reseau/supervision_ snmp.html LoriotPro http://www.loriotpro.com/ServiceAndSupport/How_to/InstallWXPAgent_FR. php OCS inventory-ng http://forums.ocsinventory-ng.org php http://www.php.net/manual/en/function.snmp2-walk.php Decrypt http://decrypt.ysance.com/ slideshare http://fr.slideshare.net/labynocle/ infoscience http://infoscience.epfl.ch/record/49953/files/Rei02.pdf debian https://www.debian.org/releases/wheezy/ MEMO-LINUX.COM http://memo-linux.com/ Centreon http://www.centreon.com/Content-products/centreon-entreprise-server nicolargo http://blog.nicolargo.com/2009/02/utilisation-de-centreon.html Journal d'un Admin Linux http://journaldunadminlinux.fr/installer-et-configurer-centreon WEBLOG de CEDRIC TEMPLE http://blog.cedrictemple.net/ ZIONETRIX http://wiki.zionetrix.net/informatique:systeme:monitoring:nagios linuxpedia.fr http://www.linuxpedia.fr/doku.php/serveurs/nagios_centreon Nagios Exchange http://exchange.nagios.org/directory/Addons/Database-Backends/NDOUtils/ details 54 PC SOFT http://doc.pcsoft.fr/fr-FR/?2034007 smnet.fr http://www.smnet.fr/ocsglpi/ocs-snmp.html easeo http://blog.easeo.fr/aides-howto/ HARDWARE.FR http://forum.hardware.fr/hfr/systemereseauxpro/Logiciels-entreprise/ nagios-imprimantes-reseau-sujet_1612_1.html HACKERS ARE US http://blog.hackersare.us/2011/06/checkhpjdnew-nagios-plugin. html ouieuhtoutca.org http://wiki.ouieuhtoutca.org/doku.php?id=nagios-centreon-part1 MG Monitoring http://www.mark-gadi.fr/supervision/ LinuxQuestions.org http://www.linuxquestions.org/questions/linux-networking-3/snmp-snmpwa doc.monitoring-fr http://doc.monitoring-fr.org/3_0/html/gettingstarted-monitoring-routers. html yyovkov http://mwiki.yyovkov.net/index.php/SNMPHelp:SNMP_Mibs_for_%28HP%29_Printers L'Internet Rapide et Permanent http://irp.nain-t.net/doku.php/215snmp:40_les_mibs Blog de Victor Héry http://blog.héry.com/article9/ Blog Olivier Delort http://blog.olivierdelort.net/?p=270 ubuntu-fr http://doc.ubuntu-fr.org/installer_un_serveur_debian StackExchange http://security.stackexchange.com/questions/36198/ Linux-France http://www.linux-france.org/article/gvallee/snmp/snmp.html#ref7 FrameIp http://www.frameip.com/snmp/ mibDepot http://www.mibdepot.com 55 A.1. TABLEAU DE BORD A.1 Tableau de Bord Figure A.1 Diagramme de Gantt 56 Annexe B Annexes techniques B.1 Création d'une machine virtuelle Figure B.1 Créer une nouvelle machine, sélectionner "avancée" Figure B.2 Laisser la compatibilité matériel par défaut 57 B.1. CRÉATION D'UNE MACHINE VIRTUELLE Figure B.3 Sélectionner " I will install the operating system later" Figure B.4 Congurer le nombre de processeurs : 1 processeur double coeur est susant Figure B.5 Congurer la mémoire vive : 512 Mo sont amplement susant 58 B.1. CRÉATION D'UNE MACHINE VIRTUELLE Figure B.6 Sélectionner le mode Bridge, an d'avoir une véritable adresse ip à xer Figure B.7 Créer un nouveau disque virtuel Figure B.8 20 Go sont recommandés pour un CentOs 59 B.1. CRÉATION D'UNE MACHINE VIRTUELLE Figure B.9 Finaliser l'installation, ne pas démarrer la machine 60 B.2. INSTALLATION DE CES B.2 Installation de CES Figure B.10 Éditer les paramètres de la machine et dans la partie CD/DVD, sélectionner l'iso de CES Figure B.11 Lancer une nouvelle installation Figure B.12 Première interface 61 B.2. INSTALLATION DE CES Figure B.13 Sélectionner la langue et le clavier du système Figure B.14 Sélectionner périphériques de stockage basiques Figure B.15 Abandonner les données, an de procéder au partitionnement automatique 62 B.2. INSTALLATION DE CES Figure B.16 Sélectionner le fuseau horaire Figure B.17 Remplacer le système actuel (même si aucun n'est présent) Figure B.18 Installer un serveur central avec base de données 63 B.2. INSTALLATION DE CES Figure B.19 Choisir le duo Nagios/ndOutils Figure B.20 L'installation des dépendances commence Figure B.21 L'installation est enn terminée 64 B.2. INSTALLATION DE CES Figure B.22 Redémarrer la machine Figure B.23 CES est bien basé sur CentOs 6.5 Figure B.24 Une fois connecté à la session, repérer l'adresse ip 65 B.3. SUITE DE L'INSTALLATION DE CES VIA NAVIGATEUR WEB B.3 Suite de l'installation de CES via navigateur Web Figure B.25 Le paramétrage se poursuit dans un navigateur web (taper l'adresse ip dans la barre d'url) Figure B.26 Les diérents modules se chargent Figure B.27 Sélectionner Nagios comme serveur central Figure B.28 Laisser les répertories par défaut 66 B.3. SUITE DE L'INSTALLATION DE CES VIA NAVIGATEUR WEB Figure B.29 Vérier que ndOutils est le Broker sélectionné Figure B.30 Dénir ses paramètres d'administration Figure B.31 Dénir les informations de la base de données Figure B.32 Vérication des paramètres entrés Figure B.33 On peut à présent se connecter à Centreon 67 B.4. LES DIFFÉRENTS ÉLÉMENTS DE CENTREON B.4 Les diérents éléments de Centreon Figure B.34 Modication d'un hôte Figure B.35 Les diérents groupes d'hôtes Figure B.36 Exemple de commande s'appuyant sur un plugin 68 B.5. MIGRATION DE LA MACHINE VIRTUELLE Figure B.37 Modication d'un service Figure B.38 Relation entre un service et un groupe d'hôtes B.5 Migration de la machine virtuelle Figure B.39 Modication de la compatibilité hardware 69 B.6. V1 DE L'INTERFACE WEB DE NOTRE APPLICATION Figure B.40 Clone de la machine avec modications Figure B.41 Sélection d'un emplacement sur le DataCenter Figure B.42 Sélection d'un ESX-LUN B.6 V1 de l'interface Web de notre application 70 B.6. V1 DE L'INTERFACE WEB DE NOTRE APPLICATION Figure B.43 Interface générale Figure B.44 Diagnostic imprimante 71 B.6. V1 DE L'INTERFACE WEB DE NOTRE APPLICATION Figure B.45 Diagnostic poste de travail Figure B.46 Lancement d'une commande de controle à distance 72 B.6. V1 DE L'INTERFACE WEB DE NOTRE APPLICATION Figure B.47 Discover SNMP Figure B.48 Résultat d'un discover à la DEMS 73