RAPPORT DE STAGE. de 3 e année de la licence d'informatique parcours Informatique soutenu par. Marine Landrieux. le 1er septembre 2011

Dimension: px
Commencer à balayer dès la page:

Download "RAPPORT DE STAGE. de 3 e année de la licence d'informatique parcours Informatique soutenu par. Marine Landrieux. le 1er septembre 2011"

Transcription

1 UNIVERSITÉ D'ÉVRY VAL D'ESSONNE Département d'informatique RAPPORT DE STAGE de 3 e année de la licence d'informatique parcours Informatique soutenu par Marine Landrieux le 1er septembre 2011 Un outil de monitoring pour le Grid Observatory Directeur de stage Julien Nauroy Établissement d'accueil LRI Année universitaire

2 Table des matières 1 Le contexte de mon stage Présentation du LRI L'European Grid Initiative La tâche qui m'a été conée Réalisations Le fonctionnement du Grid Observatory Recherches sur le monitoring informatique Dénition Les divers outils de monitoring existants Les particularités de Shinken Mise en uvre de Shinken Création d'une conguration propre au Grid Observatory Création de sondes propres au Grid Observatory Réalisation d'une batterie de tests adaptée aux erreurs identiées dans le Grid Observatory Tests des vérications sur le système de chiers Tests des vérications de contenu de chiers Déploiement de Shinken sur la machine Grid Observatory

3 Introduction J'ai débuté mon stage au sein du LRI le 6 juin 2011 et il s'achèvera le 26 août. Au cours de ce stage, j'ai participé au projet de l'european Grid Initiative, plus particulièrement le Grid Observatory. Mon travail à consisté en l'étude des besoins de détection de panne du Grid Observatory, pour cela il m'a fallu évaluer les solutions existantes, concevoir et développer un outil adapté, principalement en Perl (langage que je ne connaissais pas avant ce stage) et m'assurer du bon fonctionnement de l'outil au sein d'un environnement de production. Ce stage s'est avéré être une expérience nouvelle pour moi. En eet, je connaissais le monde du travail en entreprise mais pas celui du travail en laboratoire de recherche. Même si mon projet n'était pas un projet de recherche, le fait qu'il soit à échelle européenne et qu'il servira pour la communauté de chercheurs m'a beaucoup impressionnée et m'a donné envie de faire un travail d'autant plus ecace. Le Grid Observatory m'a permis d'utiliser mes connaissances acquises durant mon parcours universitaire mais à une plus grande échelle. J'ai ainsi pu améliorer les compétences que j'avais déjà, en développer d'autres et en acquérir de nouvelles (notamment le langage Perl). Dans ce rapport, je commencerai par décrire le cadre de mon stage : je présenterai le LRI puis l'european Grid Initiative ainsi que la tâche qui m'a été conée. Puis j'exposerai comment j'ai rempli cette tâche en commençant par l'étude des besoins du Grid Observatory, puis mon travail de recherche en matière de surveillance informatique et comment j'ai intégré au Grid Observatory un outil de surveillance informatique déjà existant nommé Shinken. 3

4 1 Le contexte de mon stage 1.1 Présentation du LRI Le Laboratoire de Recherche en Informatique (LRI) a été créé il y a environ une trentaine d'années et est rattaché au Centre National de la Recherche Scientique (CNRS), à l'institut National de Recherche en Informatique et en Automatique (INRIA) et à l'université Paris-Sud-11. Actuellement, le LRI quitte progressivement le bâtiment 490 situé sur le Campus d'orsay pour emménager dans le Pôle Commun de Recherche en Informatique (PCRI) situé sur le plateau du Moulon. Plus de 260 personnes y travaillent, dont environ 115 permanents et 110 doctorants, le tout étant organisé en 12 équipes de recherche, une équipe administrative et une équipe technique. Les recherches du LRI abordent aussi bien des aspects fondamentaux (algorithmique, complexité, calcul quantique, optimisation combinatoire...) que des aspects appliqués (clusters et grilles de calcul, bioinformatique, systèmes d'inférence, programmation...). Le laboratoire est présent dans de nombreux projets nationaux et internationaux, notamment les projets nancés par l'agence Nationale de la Recherche (ANR) et ceux nancés par l'union Européenne. L'équipe Apprentissage et Optimisation (A&O) que j'ai rejointe dans le cadre de mon stage, travaille justement sur un de ces projets d'envergure européenne : L'European Grid Initiative. 1.2 L'European Grid Initiative L'European Grid Initiative (EGI) est une grille de calcul européenne de 100 Po de stockage et de c urs qui est le support des expériences du Large Hadron Collider (LHC). Chaque mois, l'infrastructure EGI permet la réalisation de 25 millions d'unités de calcul (ou jobs). Un job est un programme autonome traitant une sous-partie d'une expérience. L'utilisation de jobs de courte durée (typiquement 2 jours maximum, un seul c ur, quelques Go de mémoire, quelques Go d'espace disque) permet de répartir un calcul beaucoup plus important sur des milliers de machines en même temps sans avoir un besoin important de synchronicité. Un job peut concerner par exemple le traitement d'une partie des données du LHC. L'EGI est principalement utilisée pour les expériences du LHC mais est également le support de beaucoup d'autres expériences, notamment en biologie, médecine, cosmologie, etc. Le Grid Observatory est un fournisseur de services pour le projet EGI ayant pour partenaires le Laboratoire de Recherche en Informatique (LRI), l'imperial College London, l'università degli Studi del Piemonte Orientale Amedeo Avogadro et l'academia Sinica Grid Computing. D'autres institutions telles que le Laboratoire de l'accélérateur Linéaire (LAL), le GDR Architecture-Réseaux-Systèmes du CNRS, l'université Paris-Sud-11, la Région Île-de-France et la fondation Digiteo contribuent au projet du Grid Observatory. 4

5 L'objectif du Grid Observatory est de développer une vision scientique de la dynamique du comportement du réseau et de son utilisation : il réalise l'acquisition à partir de la grille des traces d'utilisation et de l'activité middleware, les anonymise et les publie sur la grille pour les rendre disponibles aux informaticiens. Ils sont publiés sous forme d'archive hebdomadaire par thème dont une copie (backup) est placée dans un espace de stockage au centre de calcul de Lyon. Le Grid Observatory comprend deux serveurs, bientôt trois, et 250 machines à partir desquelles il acquiert des données ; parmi ces 250 machines, il y en a une vingtaine sur lesquelles il a des accès plus importants. Il a une production de données de 100 à 150 Go par mois. Lorsque j'ai débuté mon stage, il n'y avait aucun moyen de détecter dans l'immédiat certains problèmes, ce qui pouvait entraîner de très grosses pertes de données, d'où la nécessité d'un outil de surveillance. Pour tenter de remédier à cela, des outils ad hoc ont été créés tels qu'une vérication de l'accessibilité du site et de surveillance d'une partie des données mais ces outils sont jugés insuisants par l'administrateur du Grid Observatory. Le système avait besoin d'un complément de surveillance manuel, ce qui nécessitait beaucoup de temps et cela pouvait générer des erreurs. 1.3 La tâche qui m'a été conée Dans le cadre de mon stage au LRI, il m'a été demandé d'étudier la faisabilité d'un outil permettant de surveiller le fonctionnement de la chaîne d'acquisition, traitement et publication du Grid Observatory, détecter les pannes et défaillances et déclencher des avertissements progressifs en fonction de la panne détectée (pouvant aller jusqu'à l'envoi d'alertes ). Les vérications doivent porter sur des informations susceptibles de trahir un problème dans le fonctionnement du système telles que l'espace disque utilisé, la date du dernier journal d'exécution, la quantité de chiers en attente de publication. Ce type d'outil est connu dans l'industrie sous le nom de monitoring informatique. 5

6 2 Réalisations Mon travail pour le Grid Observatory s'est déroulé en plusieurs étapes, que reprendra le plan de ce chapitre : tout d'abord, il a fallu analyser les besoins en surveillance spéciques à ce projet et étudier les solutions existantes an d'établir des préconisations quant au développement d'un outil adapté. Le résultat de l'analyse des besoins du Grid Observatory est présenté en section 3.1 ; l'étude des solutions existantes est présentée en section 3.2. la solution retenue a ensuite dû être développée pour répondre aux besoins du Grid Observatory puis une batterie de test adaptée aux erreurs identiées dans le Grid Observatory a été réalisée dans le but tester mon travail et de montrer le bon fonctionnement de l'outil. Les étapes du développement sont présentées en section 3.3 : la réalisation de la batterie de test est présentée en section 3.4. pour nir, la solution a été déployée sur la machine du Grid Observatory pour qu'il commence son travail de surveillance. La description du déploiement est présentée en section Le fonctionnement du Grid Observatory Figure 1 Architecture générale du Grid Observatory 6

7 Le Grid Observatory récupère régulièrement les traces d'utilisation et de l'activité middleware des diérents services de l'egi (Torque, BDII, RTM...), les anonymise et les publie une fois par semaine. La Figure 1 représente son architecture. Chaque publication est également conservée sous forme de backup. Pour chaque traitement, les scripts écrivent au fur et à mesure les actions qu'ils eectuent dans des chiers journaux (log) et les erreurs qu'ils rencontrent dans des chiers log d'erreur (err) pour permettre d'avoir un suivi de chaque traitement. Une sous partie du Grid Observatory, le Green Computing Observatory, surveille un sousensemble des machines de la grille, situées au LAL. Le Green Computing Observatory fonctionne avec les services IPMI et Ganglia : IPMI acquiert les données de la carte mère telles que la température du processeur, la consommation électrique, la vitesse des ventilateurs, etc. Ganglia permet de visualiser ces données, mais aussi de récupérer les données du système d'exploitation comme la quantité de mémoire utilisée, le débit réseau ou le nombre de programmes en exécution. La Figure 2 montre le processus d'acquision du Green Computing Observatory. Figure 2 Acquisition du Green Computing Observatory Le problème majeur du Grid Observatory est le fait qu'on ne puisse pas détecter rapidement les pannes ou les erreurs. Pour s'en rendre compte, il faut parcourir régulièrement les chiers log ainsi que les chiers produits ce qui est très coûteux en temps et peu pratique. Il est donc nécessaire de trouver ou créer un outil vériant et permettant de visualiser rapidement les états des divers services et composants du Grid Observatory. Mon premier travail a consisté à identier les sources d'informations susceptibles de poser problème sur lesquelles allaient porter les vérications : les chiers log : est-ce que le chier log existe et a un contenu, est-ce que son contenu est correct, est-ce un log récent, est-ce que le script est terminé, en cours d'exécution ou a eu un problème? 7

8 les chiers err : est-ce que le chier err existe et a un contenu, est-ce que son contenu contient des lignes qui ne sont pas reconnues comme étant des fausses erreurs? la présence de chier dans les répertoires de mise en ligne : est-ce qu'il y a bien au maximum un seul chier dans chaque répertoire, est-ce que ces chiers sont là depuis plus d'une semaine, est-ce que les chiers ont un nom correct et est-ce qu'ils ont une taille correcte? la présence de chiers dans les répertoires de backup : est-ce qu'il y a bien un seul et unique chier dans le répertoire de backup, est-ce que le chier backup a un nom correct et un contenu, est-il récent? les chiers de la grille : est-ce qu'il y a eu des chiers publiés sur la grille récemment et est-ce que ces chiers ont une taille correcte? disponibilité de l'espace disque local : est-ce qu'il reste susamment d'espace libre sur le disque et est-ce que les chiers locaux ne prennent pas trop de place sur le disque? charge CPU d'une machine : le CPU d'une machine est-il surchargé? l'accessibilité des machines via ssh : est-ce que l'on peut se connecter en ssh à toutes les machines ou à une machine gurant dans le chier de conguration? visibilité des machines sur le réseau : est-ce que les machines répondent à la commande ping? l'accessibilité de la base de données : est-ce que l'on peut se connecter à la base de données? 2.2 Recherches sur le monitoring informatique Mes recherches sur le monitoring informatique m'ont d'abord amenée à dénir ce qu'est le monitoring. J'ai ensuite fait une liste regroupant la plupart des outils de monitoring existant actuellement puis je me suis documentée sur le fonctionnement de l'un d'eux, celui qui paraissait être le plus adapté pour répondre aux besoins du Grid Observatory : Shinken Dénition Depuis l'essor de l'informatique dans les années 90, les systèmes d'information permettent de rendre de plus en plus de services. Il a donc fallu apprendre à superviser les services et les serveurs de façon plus précise. Avant, le monitoring était proposé par les opérateurs dans le cadre de leurs ores commerciales mais maintenant il peut être pris en charge par les entreprises à moindre coût grâce à des outils gratuits. Le monitoring permet notamment de surveiller ([Mon]) : l'état physique d'une machine (température, disques). la charge d'une machine (nombre d'utilisateurs, de requêtes, la CPU, débit réseau). la disponibilité applicative (présence de processus). les messages inscrits en log systèmes. les performances du réseau (débit, latence, taux d'erreur). la nature des protocoles d'un réseau et leur taux relatif (UDP, TCP, ICMP...). les attaques connues sur un Pare-feu. les réponses protocolaires (simulation partielle d'une session). les modications. 8

9 D'après [Fau11], on peut subdiviser les outils de monitoring en deux catégories bien distinctes : la métrologie ([Met]) : correspond à de la prise de mesures et à une historisation de données à partir de ces mesures pour éventuellement en faire des graphiques, cela permet d'avoir une vision statistique du système informatique pour connaitre ses performances, son trac, détecter des situations de congestion, etc. la supervision ([Sup]) : correspond à l'analyse et au traitement des données ainsi que l'alerte en cas de situations critiques, cela permet de vérier l'état du système pour détecter des pannes ou mauvais fonctionnement Les divers outils de monitoring existants Les outils de monitoring sont très nombreux ; des recherches m'ont permis d'établir la liste des principaux outils utilisés actuellement. 1. Les outils de métrologie Cacti ([Cac]) : créé aux alentours de 2001 par The Cacti Group sous licence GNU GPL pour mesurer les performances réseau et serveur ; ses scripts sont codés en Bash, PHP, Perl, VBs... ; Cacti correspond à de la métrologie de réseau et de service, il permet de générer des alertes mais, seulement si le plugin spécique est installé et il donne la possibilité de créer ses propres scripts. Munin ([Mun]) : créé en 2004 sous licence GNU GPL pour surveiller les systèmes et les réseaux ; Munin en lui-même est codé en Perl mais ses plugins peuvent être écrits dans n'importe quel langage ; Munin correspond à de la métrologie de réseau et de service. Multi Router Trac Grapher (MRTG) ([MRT]) : créé en 2006 par Tobi Oetiker sous licence GNU GPL pour surveiller et mesurer la charge de trac sur les réseaux ; il est codé en Perl exclusivement ; MRTG correspond à de la métrologie de réseau. 2. Les outils de supervision Nagios ([Nag], [Wikb]) : créé en 1999 par Ethan Galstad sous licence GNU GPL pour assurer la surveillance des hôtes et des services en prévenant lorsqu'il y a des pannes ou des erreurs ; ses scripts sont codés en shell, C++, C#, Perl, Python, Ruby, PHP... ; Nagios correspond à de la supervision de réseau et de service, il permet de générer des alertes et il donne la possibilité de créer ses propres scripts. Voici son complément et ses forks : Centreon ([Cen]) : créé en 2005 par Merethis sous licence GNU GPL2 pour fournir à Nagios une interface d'apparence plus simple ; l'interface est codée en PHP ; Centreon correspond à de la supervision de réseau et de service, il permet de générer des alertes et il donne la possibilité de créer ses propres scripts. Icinga ([Ici]) : créé en 2009 par d'anciens développeurs de Nagios sous licence GNU GPL et a le même but que Nagios ; il est codé dans les mêmes langages que son parent Nagios ; Icinga correspond à de la supervision de réseau et de service, il permet de générer des alertes et donne la possibilité de créer ses propres scripts. Shinken ([Shi], [Wikd]) : créé en 2010 par Jean Gabès sous licence GNU GPL, car, selon son créateur, il n'y a eu aucune amélioration réelle de Nagios durant les trois dernières années, essentiellement des corrections de bugs ; il est codé en Python et ses 9

10 scripts sont en Perl ou en Python ; Shinken correspond à de la supervision de réseau et de service, il permet de générer des alertes et il donne la possibilité de créer ses propres scripts. Xymon ([Xym], [Wika]) : créé en 2002 par Henrik Storner sous licence libre pour surveiller les serveurs, applications et réseaux ; il est codé en C ; Xymon correspond à de la supervision de réseau et de service, il permet de générer des alertes. Monit ([Mmo]) : créé aux alentours de 2007 par Tildeslash Ltd sous licence GNU GPL pour surveiller des services locaux installés sur une machine Unix ; il est codé en C ; Monit correspond à de la supervision de réseau et de service, il permet de générer des alertes et l'automatisation d'action. NetCrunch ([Net]) : créé en 2007 par AdRem Software sous licence shareware pour gérer et surveiller des réseaux de plusieurs milliers de n uds ; NetCrunch correspond à de la supervision de réseau, il permet de générer des alertes. OpenNMS ([Ope]) : créé aux alentours de 2008 par The OpenNMS Group sous licence GNU GPL dans le but de servir de plate-forme applicative de gestion de réseau ; il est codé en Java ; OpenNMS correspond à de la supervision de réseau et de service, il permet de générer des alertes et il donne la possibilité de créer ses propres scripts. Vericoh ([NG10]) : créé en 2009 par Philippe Gauron pour vérier le comportement pour l'acquisition et la publication de l'ensemble des données du Grid Observatory selon les besoins de l'époque ; il est codé en en Python ; Vericoh correspond à de la supervision de service. 3. Les outils de supervision et de métrologie Zabbix ([Zab]) : créé en 2006 par Alexei Vladishev sous licence GNU GPL pour surveiller le statut de divers services réseau, serveurs et autres matériels réseau ; Zabbix correspond à du monitoring de réseau et de service. Server Monitor ([Ser]) : créé en 2008 par Kalimoni sous licence commerciale pour surveiller et monitorer un serveur en mode hébergé ; Server Monitor correspond à du monitoring de réseau et de service. BoardVisor ([Boa]) : créé par IDCWARE sous licence commerciale pour apporter un reporting réel de la qualité de service, un tableau de bord permettant de visualiser immédiatement l'activité de l'entreprise et d'en déduire les tendances à moyen et long termes ; BoardVisor correspond à du monitoring de service, il permet de générer des alertes, de corréler des données, mais il ne traite pas avec les événements terminés et demande la participation de l'utilisateur pour éviter les ruptures de service. Le Grid Observatory n'a pas besoin d'un outil de métrologie mais d'un outil de supervision. En eet, les graphiques et l'historisation ne correspondent pas aux besoins qu'a le Grid Observatory, contrairement à l'analyse et au traitement des données et les alertes en cas de problème. La supervision de réseau ne convient pas pour le Grid Observatory, il faut un outil de supervision de service qui soit facilement adaptable pour qu'il soit possible de rajouter les vérications dont le Grid Observatory a besoin (si elles ne sont pas déjà dans l'outil). De part sa capacité à eectuer une surveillance aussi bien passive qu'active ainsi que de part la possibilité d'y ajouter ses propres scripts, Shinken semble être le candidat idéal pour monitorer 10

11 le Grid Observatory Les particularités de Shinken L'idée principale de Shinken est de découpler les diérents rôles de Nagios. J'ai étudié son fonctionnement pour savoir s'il est vraiment l'outil idéal pour le Grid Observatory. Shinken est composé de six parties selon [Val11] : l'arbiter : il est chargé de lire la conguration, de la découper en autant de parties qu'il y a de Schedulers dans l'architecture et de l'envoyer aux éléments de l'architecture. Il est également garant de la haute disponibilité : si un élément tombe, il envoie la conguration qu'il avait en charge à un élément non actif déni par l'administrateur. Enn, son dernier rôle est de lire les ordres des administrateurs et de les transmettre aux Schedulers concernés. les Schedulers : ils ont pour tâche la programmation des contrôles, l'analyse des résultats et le suivi des actions en conséquence. Ils ne lancent pas directement les vérications ni les alertes. Ils ne font que proposer un ordre de lancement. les Pollers : ils ont pour rôle de lancer les sondes demandées par les Schedulers au moment où les Schedulers les y autorisent. Une fois par seconde, ils vont retourner les résultats aux Schedulers pour que ces derniers puissent eectuer des actions supplémentaires si besoin (comme une alerte) et réordonnancer les tests. Ils sont en première ligne pour les performances et on peut en avoir autant que l'on a besoin. les Reactionners : ils sont responsables du lancement des vérications et des actions correctrices. Ils sont découplés des Pollers car il est plus pratique d'avoir un unique Reactionner (avec un élément non actif) pour n'avoir qu'un seul lieu où se remplissent les ux d'information d'alerte. les Brokers : ils doivent récupérer les informations d'état des Schedulers et les traiter. Ces traitements sont faits par des modules. Diérents modules existent : un pour l'export en base MySQL, un pour l'export en base Oracle ou encore pour l'export en base CouchDB. les sondes : codées principalement en Perl, elles sont chargées d'eectuer des vérications ou des traitements sur les diérents services à contrôler et renvoyer leur état aux Pollers. Comme dans Nagios, les sondes ont les codes retour suivants : 0 : OK, 1 : WARNING, 2 : CRITICAL et 3 : UNKNOWN. Chaque démon a un chier de conguration et un port sur lequel écouter. L'architecture une tâche, un outil donne à Shinken une exibilité bien supérieure au Nagios originel, on a ainsi une mise en place et une conguration beaucoup plus faciles. La visualisation de Shinken peut se faire grâce à plusieurs outils, parmi lesquels les Interfaces Homme-Machine (IHM) web Ninja et Thruk ; c'est cette dernière que j'ai utilisé durant mon stage (voir Figure 3). 11

12 Figure 3 Capture d'écran de Thruk Shinken est donc l'outil idéal pour répondre au besoin de surveillance du Grid Observatory de part son installation simple et rapide, la facilité avec laquelle on peut créer et ajouter de nouvelles sondes, la possibilité d'envoyer des alertes et son IHM qui permet de visualiser uniquement ce dont on a besoin. Il a été proposé de reprendre et d'améliorer Vericoh mais, Vericoh étant une ébauche d'outil de supervision, tout ceci revenait quelque peu à recréer un outil de supervision à partir de Vericoh (faire une IHM web aurait été comme refaire Thruk, développer un analyseur revenait à refaire les Brokers et Reactionners de Shinken...) alors qu'il y en a déjà un bon nombre qui existe et que Shinken répondait à nos besoins. Une autre solution a également été proposée : développer un autre outil, tout à fait diérent de Shinken et d'une évolution de Vericoh. Cependant, j'ai montré que les besoins du Grid Observatory correspondaient tout à fait à un outil de supervision et Vericoh a montré les limites de la création d'un outil ad hoc, donc créer un outil spécique revenait à créer un outil de supervision là où nous aurions pu nous appuyer sur un outil déjà existant. Faire évoluer Shinken est donc apparu comme le choix le plus pertinent pour répondre à ce besoin d'un outil de surveillance. 2.3 Mise en uvre de Shinken Pour adapter Shinken aux besoins du Grid Observatory, je l'ai d'abord installé sur ma machine en suivant les instructions de [Gab10]. Alors, j'ai pu lui créer une conguration puis des sondes 12

13 spéciques au Grid Observatory. Il m'a ensuite fallu réaliser une batterie de tests adaptée aux erreurs identiées dans le Grid Observatory et, pour nir, j'ai déployé Shinken sur la machine du Grid Observatory Création d'une conguration propre au Grid Observatory Pour créer une conguration pour le Grid Observatory, j'ai dû ajouter ou modier les chiers suivants : /etc/shinken/conf-gridobs/gridobs-commands.cf g pour contenir les commandes pour lancer les sondes que j'allais créer par la suite. /etc/shinken/nagios.cfg pour qu'il sache où aller chercher les commandes pour lancer les sondes du Grid Observatory. /etc/shinken/resource.cf g pour qu'il sache où se situent les sondes en question. /etc/shinken/conf-gridobs/shinken-conf iguration.xml qui servira de référence pour les diérentes sondes du Grid Observatory. J'ai également créé le répertoire /usr/lib/nagios/plugins/gridobs/ pour contenir les sondes du Grid Observatory que j'ai créées an de les dissocier de celles qui sont de base dans Shinken Création de sondes propres au Grid Observatory Cette section présente les sondes en Perl que j'ai créées durant mon stage. Les sondes suivantes seront présentées : check_ssh pour vérier l'accessibilité en ssh. check_f ile_up pour vérier la présence de chiers dans les répertoires d'upload. check_service pour vérier si tout va bien pour un service du Grid Observatory. check_upload pour vérier la présence d'erreurs dans les log d'upload (un couple de chier log et de chier err). check_log pour vérier les autres chiers log. check_err pour vérier les autres chiers log d'erreurs. check_disk pour vérier l'espace disque. check_backup pour vérier la présence de chiers backup. 1. check_ssh Pour fonctionner, cette sonde a besoin qu'on lui donne soit l'option -m suivie du nom d'une machine, soit l'option --all. Elle écrit ses actions dans le chier /data/log/shinken/check_ssh.log. Si on lui donne l'option --all, elle parcourt toutes les machines gurant dans le chier xml de conguration et tente de se connecter en ssh à chaque machine. Son code retour est OK si elle a réussi à se connecter à toutes les machines, sinon son code retour est CRITICAL et elle écrit les noms des machines auxquelles elle n'a pas pu se connecter dans son chier log. 13

14 Si on lui donne l'option -m suivie d'un nom de machine, elle commence par regarder si les informations de connexion de la machine gurent dans le chier xml, si ce n'est pas le cas, son code retour est CRITICAL. Ensuite, elle essaye de se connecter en ssh à la machine. Si elle ne réussi pas, le code retour est CRITICAL sinon le code retour est OK. 2. check_f ile_up Cette sonde écrit ses actions dans le chier /data/log/shinken/check_f ile_up.log. Elle débute en vériant que chaque répertoire contenu dans le répertoire /data/up/ ait au maximum un chier (à part pour le répertoire /data/up/buggy/). Si ce n'est pas le cas, son code retour est CRITICAL. Ensuite elle vérie depuis combien de temps chaque chier est présent ici (sauf pour ceux du répertoire /date/up/buggy/). Si cela fait plus de sept jours qu'ils sont ici, son code retour est CRITICAL et elle écrit dans son chier log les chiers concernés, si cela fait plus d'un jour, son code retour est WARNING et elle écrit également dans son chier log les chiers concernés. Puis elle regarde si le répertoire /data/up/buggy/ ne contient pas de chier de moins de sept jours. S'il y en a, son code retour est CRITICAL et elle écrit dans son chier log les chiers concernés. Après cela, elle vérie le nom de chaque chier (hormis ceux du répertoire /data/up/buggy/). S'ils ne sont pas de ce type ganglia2011w 25.tar.gz, son code retour est CRITICAL. Pour nir, elle vérie la taille de chaque chier : elle parcourt les répertoires gurant dans le chier xml de conguration et pour chaque répertoire, elle récupère les bornes critiques et les bornes warning sur la taille de leur chier. S'il y a des chiers dont le répertoire ne gure pas dans le chier xml, le code retour est CRITICAL et elle écrit les chiers concernés dans son chier log. S'il y a des chiers qui ont une taille hors de bornes critiques, le code retour est CRITICAL et elle écrit dans son chier log les chiers concernés, s'il y en a qui ont une taille hors des bornes warning, le code retour est WARNING et elle écrit dans son chier log les chiers concernés. Sinon elle retourne OK. 3. check_service Pour fonctionner, cette sonde a besoin qu'on lui donne l'option -s suivie du nom d'un service du Grid Observatory. Elle écrit ses actions dans le chier /data/log/shinken/check_service.log. Elle commence par vérier que le service passé en paramètre fait bien partie de la liste des services du Grid Observatory stockée dans le chier xml de conguration. Si ce n'est pas le cas, son code retour est CRITICAL, sinon on récupère les noms des chiers log, des chiers log d'erreur et des chiers d'upload correspondant à ce service. Ensuite, pour chacun des chiers log, la sonde lance la sonde check_log et récupère les codes retour. Si le service n'a pas de chier log, alors le code retour est WARNING. Puis pour chacun des chiers log d'erreur, la sonde lance la sonde check_err et récupère les codes retour. Si le service n'a pas de chier log d'erreur, alors le code retour est WARNING. 14

15 Et pour chaque couple de chier d'upload (un chier log et un chier log d'erreur), la sonde lance la sonde check_upload et récupère les codes retour. Si le service n'a pas de couple de chier d'upload, alors le code retour est WARNING. Pour nir, la sonde a pour code retour CRITICAL si, parmi tous les codes retour récupérés il y a au moins un CRITICAL, elle retourne WARNING s'il y a au moins un WARNING et aucun CRITICAL et elle retourne OK s'il n'y a ni WARNING ni CRITICAL. 4. check_upload Pour fonctionner, cette sonde a besoin qu'on lui donne deux fois l'option -f suivie de chiers (le chier log d'upload et le chier log d'erreur correspondant). Elle écrit ses actions dans le chier /data/log/shinken/check_upload.log. Elle commence par tester l'existence du chier log. Si ce n'est pas le cas, son code retour est CRITICAL, si c'est le cas mais qu'il n'a pas de contenu, son code retour est WARNING. Elle fait les mêmes vérications pour le chier log d'erreur. Ensuite elle récupère le dernier log du chier log. Un log doit commencer par la ligne Running : nom du script. S'il n'y a pas un seul "Running : " dans le chier, alors le code retour est CRITICAL, s'il y a des "Running : " mais que leur syntaxe n'est pas correcte, alors le code retour est WARNING et elle écrit dans son chier log les lignes en question. La sonde fait le même traitement pour le chier log d'erreur. Puis elle vérie les lignes du log. Si le log a des lignes ne correspondant pas aux lignes types d'un chier log d'upload, alors le code retour est CRITICAL. Si le log a des lignes correspondant aux lignes types d'un chier log d'upload mais qu'elles ne sont pas dans le bon ordre, alors le code retour est WARNING. Elle regarde ensuite si le log d'erreur contient la ligne Using grid catalog : (null) ou non. Si oui alors son code retour est WARNING. Pour nir, elle regarde si le log contient la ligne prouvant que le chier a bien été mis en ligne. S'il ne la contient pas, son code retour est WARNING et elle écrit dans son chier log le contenu du chier log d'erreur pour expliquer pourquoi la mise en ligne a échoué. Sinon son code retour est OK. Si le premier chier passé en paramètre n'a pas une extension.log, le code retour de la sonde est UNKNOWN et si le deuxième chier passé en paramètre n'a pas une extension.err, le code retour de la sonde est UNKNOWN. 5. check_log Pour fonctionner, cette sonde a besoin qu'on lui donne l'option -f suivie du nom d'un chier log. Elle écrit ses actions dans le chier /data/log/shinken/check_log.log. Elle commence par tester l'existence du chier. S'il n'existe pas, son code retour est CRIT- ICAL, s'il existe mais qu'il n'a pas de contenu, son code retour est WARNING. Ensuite, elle cherche le dernier log : celui-ci doit débuter par la ligne Running : nom du script. 15

16 S'il n'y en a pas, son code retour est CRITICAL, s'il y en a mais que leur syntaxe n'est pas correcte, son code retour est WARNING et elle écrit les lignes concernées dans son chier log. Après cela, elle regarde si chaque ligne du dernier log commence par un TimeStamp correct ( T14 :11 :11Z par exemple), sinon, elle retourne CRITICAL et écrit dans son chier log les lignes concernées. Puis elle vérie la date du dernier log. Pour cela elle commence par chercher les informations relatives au chier dans le chier xml de conguration. Si ses informations ne sont pas dans le chier, son code retour est CRITICAL. Ensuite, elle compare la date d'aujourd'hui à la date du log. Si la diérence est négative, alors le log est daté dans le futur et le code retour est CRITICAL, si la diérence est positive mais supérieure à la durée critique récupérée dans le chier xml, alors le code retour est CRITICAL et si la diérence est positive mais supérieure à la durée warning, alors le code retour est WARNING. Elle vérie alors si le script est terminé en regardant si la dernière ligne du log est All done.. Si le script n'est pas terminé, elle regarde la date de la dernière ligne et la compare à la date d'aujourd'hui, si la diérence est supérieure à une heure, son code retour est CRITICAL, sinon son code retour est WARNING. Pour nir, elle regarde le temps de traitement du script. Si le temps de traitement est supérieur au temps critique récupéré dans le chier xml, alors le code retour est CRITICAL, s'il est supérieur au temps warning, alors le code retour est WARNING et sinon le code retour est OK. Si le chier passé en paramètre n'a pas une extension.log, le code retour de la sonde est UNKNOWN. 6. check_err Pour fonctionner, cette sonde a besoin qu'on lui donne l'option -f suivie du nom d'un chier log d'erreur. Elle écrit ses actions dans le chier /data/log/shinken/check_log.log. Pour commencer, elle vérie si le chier existe bien et s'il a un contenu. S'il n'existe pas, son code retour est CRITICAL. S'il existe mais qu'il n'a pas de contenu, son code retour est WARNING. Ensuite, elle vérie que chacun des log d'erreur commence bien par la ligne Running : nom du script. S'il n'y a aucun "Running : " dans tout le chier alors le code retour est CRITICAL. S'il y a des "Running : " mais mal orthographiés alors le code retour est WARNING. Pour nir, elle parcourt chacune des lignes du dernier log d'erreur et les compare aux expressions régulières des lignes considérées comme étant des fausses erreurs (elles sont stockées dans le chier xml de conguration). Si le dernier log d'erreur contient des lignes autres que des fausses erreurs, le code retour est CRITICAL, sinon le code retour est OK. Si l'extension du chier n'est pas.err alors le code retour de la sonde est UNKNOWN. 7. check_disk Cette sonde écrit ses actions dans le chier /data/log/shinken/check_disk.log. 16

17 Elle commence par lancer la commande df et elle récupère le résultat. Elle compare ensuite l'espace disque libre récupéré grâce à la commande à l'espace disque libre critique et à l'espace disque libre warning stockés dans le chier xml de conguration. Si l'espace disque libre est inférieur à l'espace disque libre critique alors le code retour est CRITICAL, s'il est inférieur à l'espace disque libre warning alors le code retour est WARNING. Enn elle compare l'espace disque utilisé récupéré grâce à la commande à l'espace disque utilisé critique et à l'espace disque utilisé warning. Si l'espace disque utilisé est supérieur à l'espace disque utilisé critique alors le code retour est WARNING, s'il est supérieur à l'espace disque utilisé warning alors le code retour est WARNING, sinon le code retour est OK. 8. check_backup Cette sonde écrit ses actions dans le chier /data/log/shinken/check_backup.log. Elle commence par parcourir le dossier /data/backup/ et elle regarde s'il y a bien un seul et unique chier dedans sinon, son code retour est CRITICAL. Ensuite, elle regarde si le nom du chier correspond bien à un nom de chier backup (backup2011w tar.gz), si ce n'est pas le cas, son code retour est CRITICAL. Puis, elle regarde s'il a un contenu ou non. S'il est vide, son code retour est CRITICAL. Pour nir, elle regarde l'âge du chier. S'il est âgé de plus de 28 jours (ou plus de 35 jours s'il s'agit du chier backup de la semaine 53 si elle existe), son code retour est CRITICAL, sinon son code retour est OK. 2.4 Réalisation d'une batterie de tests adaptée aux erreurs identiées dans le Grid Observatory Au cours de la création des sondes, il a fallu tester chaque cas et, pour chaque modication, s'assurer que la sonde fonctionne bien pour le nouveau cas et que la modication n'altère en rien les vérications des cas précédents : j'ai dû eectuer aussi bien des tests fonctionnels que des tests de non régression ([Evr10], [Wikc]). La batterie de tests que j'ai réalisée peut se décomposer en deux parties : les tests des vérications sur le système de chiers. les tests des vérications de contenu de chiers Tests des vérications sur le système de chiers Les tests sur les sondes eectuant des vérications sur le système de chiers ont nécessité des changements fréquents sur le système de chiers. Ce genre de tests a dû être fait sur les sondes check_backup, check_disk, check_f ile_up, check_service et check_ssh. check_backup : pour cette sonde, j'ai testé les cas suivants : la présence d'un seul chier dans le répertoire /data/backup/. si le nom du chier backup est correct. 17

18 si le chier backup n'est pas vide. l'âge du chier backup. check_disk : pour cette sonde, j'ai testé les cas suivants : la présence d'espace libre sur le disque. si les chiers ne prennent pas trop d'espace sur le disque. check_file_up : pour cette sonde, j'ai testé les cas suivants : la présence d'un chier au maximum dans chaque répertoire contenu dans le répertoire /data/up/. si chaque chier est âgé de moins d'une semaine. si les chiers du répertoire /data/up/buggy/ sont âgés de plus d'une semaine. si chaque chier a un nom correct. si chaque chier a une taille correcte. check_service : pour cette sonde, j'ai testé les cas suivants : si le service est bien dans le chier xml. si les codes retour des sondes lancées sur les chiers du service sont "OK". check_ssh : pour cette sonde, j'ai testé les cas suivants : si toutes les machines sont accessibles en ssh dans le cas de l'option --all. si les informations de la machine gurent dans le chier xml et que la machine est accessible en ssh dans le cas de l'option -m Tests des vérications de contenu de chiers Les tests sur les sondes vériant le contenu de chiers ont nécessité la création d'un chier pour tester chaque cas de gure. Pour tester un cas de gure, le chier créé doit bien évidemment passer avec succès tous les tests précédents. Ce genre de tests a dû être fait sur les sondes check_log, check_err et check_upload. check_log : pour cette sonde, j'ai un ensemble de chiers testant : si l'extension du chier est correcte. l'existence du chier. si le chier n'est pas vide. si la syntaxe interne au chier est correcte (chaque log commence par la ligne Running : nom du script ). la présence d'un TimeStamp correct en début de chaque ligne. si le chier gure dans le chier xml. si la date du dernier log est récente. si le script s'est correctement terminé (la dernière ligne est All done. ) ou s'il est encore en cours d'exécution ou s'il s'est anormalement arrêté. si le temps de traitement du script n'est pas trop long. check_err : pour cette sonde, j'ai un ensemble de chiers testant : si l'extension du chier est correcte. l'existence du chier. si le chier n'est pas vide. si la syntaxe interne au chier est correcte (chaque log commence par la ligne Running : nom du script ). si le dernier log d'erreur ne contient que des lignes recensées comme étant des fausses 18

19 erreurs. check_upload : pour cette sonde, j'ai un ensemble de chiers testant : si les extensions des deux chiers sont correctes. l'existence des deux chiers. si les chiers ne sont pas vides. si les syntaxes interne aux chiers sont correctes (chaque log commence par la ligne Running : nom du script ). si les lignes du chier log sont dans le bon ordre. s'il n'y a pas de problème de catalogue dans le dernier log du chier err. si le dernier log du chier log contient la ligne attestant que le chier a été mis en ligne. 2.5 Déploiement de Shinken sur la machine Grid Observatory Un essai de déploiement a été eectué sur une machine de test sur laquelle le système fonctionne parfaitement avec une installation "standard" de Shinken possédant la conguration personnalisée pour le Grid Observatory. Shinken doit prochainement être déployé sur une machine du Grid Observatory au LAL mais un gros problème de climatisation de la salle machine du LAL a engendré un grand retard dans leur calendrier de déploiement, ce qui fait qu'au moment de la nalisation de ce rapport le logiciel n'a pas encore pu être mis en production. Le déploiement est néanmoins prévu dans les prochains jours. 19

20 Conclusion Grâce au travail que j'ai réalisé dans le cadre de mon stage, le Grid Observatory dispose maintenant d'un outil de surveillance rapide, clair et ecace. L'administrateur n'a plus besoin de vérier manuellement si tout fonctionne, un simple coup d' il à Thruk sut pour vérier l'état de l'ensemble des services et composants du Grid Observatory. Durant mes douze semaines de stage, j'ai créé les sondes véricatrices les plus vitales pour le Grid Observatory, ce qui correspond aux 3/4 des vérications dont il a besoin actuellement. Le quart restant peut être créé et ajouté simplement de part la exibilité de Shinken ; de même, si les besoins de surveillance venaient à évoluer, la création de nouvelles sondes serait tout aussi aisée. Ce stage en laboratoire a été pour moi une expérience professionnelle intéressante et enrichissante. Il m'a permis de mettre en pratique mes connaissances théoriques acquises durant ma formation universitaire et d'en acquérir de nouvelles telles que le langage Perl et le monitoring. Cette expérience m'ore une préparation solide et valorisante pour mon insertion professionnelle. 20

ZABBIX est distribué sous licence GNU General Public License Version 2 (GPL v.2).

ZABBIX est distribué sous licence GNU General Public License Version 2 (GPL v.2). Nom du projet : Zabbix Description : ZABBIX est un logiciel open source créé par Alexei Vladishev. Zabbix permet de surveiller le statut de divers services réseau, serveurs et autres matériels réseau.

Plus en détail

Télécom Nancy Année 2013-2014

Télécom Nancy Année 2013-2014 Télécom Nancy Année 2013-2014 Rapport 1A Ajout du langage C dans la Programmer's Learning Machine GIANNINI Valentin Loria 615, rue du Jardin Botanique 54600, Villers-Lès-Nancy Maître de stage : QUINSON

Plus en détail

Supervision avec Shinken

Supervision avec Shinken Supervision avec Benoit Métrot benoit.metrot@math.univ-poitiers.fr UMR 7348 - Laboratoire de Mathématiques et Applications (Poitiers) Rencontres Mathrice Caen, Mars 2013 Rencontres Mathrice Caen, Mars

Plus en détail

Compte-rendu de projet de Système de gestion de base de données

Compte-rendu de projet de Système de gestion de base de données Compte-rendu de projet de Système de gestion de base de données Création et utilisation d'un index de jointure LAMBERT VELLER Sylvain M1 STIC Université de Bourgogne 2010-2011 Reponsable : Mr Thierry Grison

Plus en détail

NACIRI Mehdi. Rapport de stage : Mise en place d un moyen pour anticiper les pannes des serveurs de l IUT. Promotion 2011-2013 BTS SIO Option SISR

NACIRI Mehdi. Rapport de stage : Mise en place d un moyen pour anticiper les pannes des serveurs de l IUT. Promotion 2011-2013 BTS SIO Option SISR NACIRI Mehdi Rapport de stage : Mise en place d un moyen pour anticiper les pannes des serveurs de l IUT Promotion 2011-2013 BTS SIO Option SISR 1 Remerciements Je tiens particulièrement à remercier le

Plus en détail

Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies

Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies Charlier Fabrice 2è licence en informatique Année Académique 2005-2006 Plan

Plus en détail

SophiaConf 2012. Jean Gabès

SophiaConf 2012. Jean Gabès SophiaConf 2012 Jean Gabès Qui suis-je? Jean Gabès Administrateur système sur Bordeaux, auteur du livre Nagios3 aux éditions Eyrolles et de Shinken Pourquoi superviser? Quand l'it va mal, le business va

Plus en détail

PPE 5 SUPERVISION D UN PARC INFORMATIQUE AVEC NAGIOS + CENTREON

PPE 5 SUPERVISION D UN PARC INFORMATIQUE AVEC NAGIOS + CENTREON PPE 5 SUPERVISION D UN PARC INFORMATIQUE AVEC NAGIOS + CENTREON Antoine CAMBIEN BTS SIO Option SISR Session 2015 BTS SIO Services Informatiques aux Organisations Session 2014 2015 Nom du candidat : Antoine

Plus en détail

Table des matières 1. Chapitre 1 Introduction à Nagios et la supervision

Table des matières 1. Chapitre 1 Introduction à Nagios et la supervision Table des matières 1 Les exemples cités tout au long de cet ouvrage sont téléchargeables à l'adresse suivante : http://www.editions-eni.fr Saisissez la référence ENI de l'ouvrage EP3NAG dans la zone de

Plus en détail

Présentation : Aurelien.Bompard@c-s.fr Contact Commercial : Frederic.Murbach@c-s.fr Responsable Offre Logiciels Libres : Gilles.Lehmann@c-s.

Présentation : Aurelien.Bompard@c-s.fr Contact Commercial : Frederic.Murbach@c-s.fr Responsable Offre Logiciels Libres : Gilles.Lehmann@c-s. Présentation : Aurelien.Bompard@c-s.fr Contact Commercial : Frederic.Murbach@c-s.fr Responsable Offre Logiciels Libres : Gilles.Lehmann@c-s.fr Plan Présentation de Vigilo Architecture globale Composants

Plus en détail

ORACLE DIAGNOSTIC PACK 11G

ORACLE DIAGNOSTIC PACK 11G ORACLE DIAGNOSTIC PACK 11G PRINCIPALES CARACTÉRISTIQUES : Surveillance automatique des diagnostics (ADDM Automatic Database Diagnostic Monitor) Référentiel automatique de la charge (AWR Automatic Workload

Plus en détail

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C#

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# CHAPITRE 1 Introduction aux web services Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# NetBeans JavaScript Eclipse Objective C Xcode PHP HTML Objectifs du chapitre : Ce

Plus en détail

Nagios 3 pour la supervision et la métrologie

Nagios 3 pour la supervision et la métrologie Nagios 3 pour la supervision et la métrologie A Propos : - la connexion au reseau se fais de la maniére suivante : Se conecter sur le Vlan DSI : -Port 21,22 du commutateur, sur une machine debian en bridged

Plus en détail

Rapport d'audit. «Librairie Informatique»

Rapport d'audit. «Librairie Informatique» GL51 Rapport d'audit «Librairie Informatique» Code : BATSPETA-000 Maîtrise d'oeuvre Maîtrise d'ouvrage Responsables de l'audit M. Fischer M. Petrequin Melle Bats, M. Petazzoni Date rédaction : 05/01/04

Plus en détail

Communauté francophone de la supervision. http://www.monitoring-fr.org. J eudis du libre B ruxelles 02 septembre 2010

Communauté francophone de la supervision. http://www.monitoring-fr.org. J eudis du libre B ruxelles 02 septembre 2010 Communauté francophone de la supervision http://www.monitoring-fr.org J eudis du libre B ruxelles 02 septembre 2010 La communauté Historique 2007 : Olivier J A N publie ses notes de recherche autour de

Plus en détail

NICOLAS JAMIN Administrateur Système DSI de l Académie de LILLE

NICOLAS JAMIN Administrateur Système DSI de l Académie de LILLE Supervision Utilisation de Check-MK Réseau Min2Rien Journée Thématique «retour d expériences» - 13/02/2014 NICOLAS JAMIN Administrateur Système DSI de l Académie de LILLE Nicolas JAMIN DSI de l Académie

Plus en détail

2 Spécicités SVN. 3 Verrouiller ou copier-modier-fusionner. 4 Commandes SVN. 5 Références

2 Spécicités SVN. 3 Verrouiller ou copier-modier-fusionner. 4 Commandes SVN. 5 Références Table des matières Apache Subversion (SVN) 1 Michel Meynard UM2 2 Spécicités SVN 3 Verrouiller ou copier-modier-fusionner Univ. Montpellier 2 4 5 Références Michel Meynard (UM2) Apache Subversion (SVN)

Plus en détail

Serveur de travail collaboratif Michaël Hoste -

Serveur de travail collaboratif Michaël Hoste - Serveur de travail collaboratif Michaël Hoste - Table des matières 1. Qu'est ce qu'un serveur de travail collaboratif?...2 2. Pourquoi ce projet?...2 3. Possibilités d'utilisation dans le cadre de l'université...3

Plus en détail

TP n 2: Mise en place d'un serveur Web avec PHP et MySQL

TP n 2: Mise en place d'un serveur Web avec PHP et MySQL TP n 2: Mise en place d'un serveur Web avec PHP et MySQL Le but de ce TP est de vous apprendre comment installer et congurer un serveur Web avec PHP et MySQL sous Linux. Cela requiert plusieurs étapes

Plus en détail

Présentation de l outil d administration de réseau Nagios

Présentation de l outil d administration de réseau Nagios Date Date Marque Brand Ecrit par Written by Destinataires Recipients Copie Copy jeudi 16 octobre 2003 M. Grégory Bernard Objet - Subject Présentation de l outil d administration de réseau Nagios Très chers,

Plus en détail

Déploiement & Supervision. Université de Marne-la-Vallée 2/61 Laurent Wargon

Déploiement & Supervision. Université de Marne-la-Vallée 2/61 Laurent Wargon Déploiement & Supervision de Marne-la-Vallée 2/61 Laurent Wargon Déploiement de Marne-la-Vallée 3/61 Laurent Wargon Déploiement L'exploitation reçoit du développement Un code Une documentation? L'exploitation

Plus en détail

Hébergement WeboCube. Un système performant et sécurisé. Hébergement géré par une équipe de techniciens

Hébergement WeboCube. Un système performant et sécurisé. Hébergement géré par une équipe de techniciens Hébergement WeboCube Le service d'hébergement WeboCube a pour but de sécuriser la présence internet grâce à un suivi personnalisé et une maintenance active de votre serveur internet. Un espace de gestion

Plus en détail

PARAGON SYSTEM BACKUP 2010

PARAGON SYSTEM BACKUP 2010 PARAGON SYSTEM BACKUP 2010 Paragon System Backup 2010 2 Manuel d'utilisation SOMMAIRE 1 Introduction...3 1.1 Comment System Backup protège mon ordinateur?...3 1.1.1 Emplacement du stockage des clichés...

Plus en détail

Zabbix. Outil de supervision réseau. Vincent Bernat Vincent.Bernat@wallix.com. July 13, 2007. Zabbix. V. Bernat. Supervision.

Zabbix. Outil de supervision réseau. Vincent Bernat Vincent.Bernat@wallix.com. July 13, 2007. Zabbix. V. Bernat. Supervision. Outil de supervision réseau Vincent Bernat Vincent.Bernat@wallix.com July 13, 2007 Plan 1 La supervision 2 3 Un exemple de Plan 1 La supervision 2 3 Un exemple de Pourquoi superviser? détecter les pannes

Plus en détail

Client Kiwi Backup : procédures d'installation et de mise à jour. Gilles Arnoult, Clément Varaldi

Client Kiwi Backup : procédures d'installation et de mise à jour. Gilles Arnoult, Clément Varaldi Client Kiwi Backup : procédures d'installation et de mise à jour Gilles Arnoult, Clément Varaldi 10 juin 2005 Première partie Installation du client Kiwi Backup 1 Chapitre 1 Sous Windows 1.1 Avant toutes

Plus en détail

Projet Personnalisé Encadré PPE 2

Projet Personnalisé Encadré PPE 2 BTS Services Informatiques aux Organisations Session 2014 Projet Personnalisé Encadré PPE 2. GESTION D'UTILISATEURS SYSTÈMES ET BASE DE DONNÉES, INSTALLATION ET CONFIGURATION D'OUTILS DE SUPERVISION ET

Plus en détail

Installation du SLIS 4.1

Installation du SLIS 4.1 Documentation SLIS 4.1 Installation du SLIS 4.1 1.3RC2 CARMI PÉDAGOGIQUE - ÉQUIPE «INTERNET» DE L'ACADÉMIE DE GRENOBLE juillet 2013 Table des matières Objectifs 5 I - Prérequis 7 A. Préconisations matérielles...7

Plus en détail

Conduite et Gestion de Projet - Cahier des charges

Conduite et Gestion de Projet - Cahier des charges Conduite et Gestion de Projet - Cahier des charges 1 Introduction Sophie Toulouse LIPN - Université Paris 13 +33.1.49.40.40.73 99 av. Jean-Baptiste Clément toulouse@lipn.univ-paris13.fr 93430 Villetaneuse

Plus en détail

PPE 2-1 Support Systeme. Partie Support Système

PPE 2-1 Support Systeme. Partie Support Système PPE 2-1 Support Systeme Partie Support Système Sébastien MASSON 24/04/2013 0 Sommaire 1. DMZ 2 2. Serveurs Web 3 3. Logiciel d'inventaire 6 1 1. DMZ (Zone démilitarisée) Une DMZ est une zone tampon d'un

Plus en détail

Introduction aux Systèmes Distribués. Introduction générale

Introduction aux Systèmes Distribués. Introduction générale Introduction aux Systèmes Distribués Licence Informatique 3 ème année Introduction générale Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Plan

Plus en détail

Cloud public d Ikoula Documentation de prise en main 2.0

Cloud public d Ikoula Documentation de prise en main 2.0 Cloud public d Ikoula Documentation de prise en main 2.0 PREMIERS PAS AVEC LE CLOUD PUBLIC D IKOULA Déployez vos premières instances depuis l interface web ou grâce à l API. V2.0 Mai 2015 Siège Social

Plus en détail

TP2 - Conguration réseau et commandes utiles. 1 Généralités. 2 Conguration de la machine. 2.1 Commande hostname

TP2 - Conguration réseau et commandes utiles. 1 Généralités. 2 Conguration de la machine. 2.1 Commande hostname Département d'informatique Architecture des réseaux TP2 - Conguration réseau et commandes utiles L'objectif de ce TP est d'une part de vous présenter la conguration réseau d'une machine dans l'environnement

Plus en détail

Éléments d'architecture des ordinateurs

Éléments d'architecture des ordinateurs Chapitre 1 Éléments d'architecture des ordinateurs Machines take me by surprise with great frequency. Alan Turing 1.1 Le Hardware Avant d'attaquer la programmation, il est bon d'avoir quelques connaissances

Plus en détail

Monitoring & Surveillance SLIM CHAKROUN (ENSI) EMNA BEN HADJ YAHIA (RT3) SAFA GALLAH (RT3)

Monitoring & Surveillance SLIM CHAKROUN (ENSI) EMNA BEN HADJ YAHIA (RT3) SAFA GALLAH (RT3) Monitoring & Surveillance SLIM CHAKROUN (ENSI) EMNA BEN HADJ YAHIA (RT3) SAFA GALLAH (RT3) Table des matières: I. Présentation de l'atelier II. Supervision des réseaux 1. objectif 2.Problématique 3. Solutions

Plus en détail

Projet Storebox. Livre blanc Swisscom (Suisse) SA

Projet Storebox. Livre blanc Swisscom (Suisse) SA Projet Storebox Livre blanc Swisscom (Suisse) SA Sommaire Sommaire... 2 Introduction... 3 Différence entre synchronisation et sauvegarde... 3 Quelle méthode utiliser?... 3 Situation initiale... 4 Enjeux...

Plus en détail

SUPERVISION SYSTÈME D INFORMATION

SUPERVISION SYSTÈME D INFORMATION 1 SUPERVISION SYSTÈME D INFORMATION SOMMAIRE I. Contexte II. III. IV. Cahier des charges Analyse Conception V. Test de la maquette L entreprise Réseau existant Définition des besoins Calendrier Prévisionnel

Plus en détail

Monitoring des Ressources Informatiques au LAL. Journées Informatique IN2P3 DAPNIA 2004 - HOURTIN Jacquelin Charbonnel - printemps 2004

Monitoring des Ressources Informatiques au LAL. Journées Informatique IN2P3 DAPNIA 2004 - HOURTIN Jacquelin Charbonnel - printemps 2004 Monitoring des Ressources Informatiques au LAL Journées Informatique IN2P3 DAPNIA 2004 - HOURTIN Jacquelin Charbonnel - printemps 2004 solution basée sur 2 logiciels libres nagios www.nagios.org rrdtool

Plus en détail

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 Tsoft et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 OEM Console Java OEM Console HTTP OEM Database Control Oracle Net Manager 6 Module 6 : Oracle Enterprise Manager Objectifs Contenu A la fin de ce module,

Plus en détail

CONFIGURER VOTRE HEBERGEMENT LINUX

CONFIGURER VOTRE HEBERGEMENT LINUX CONFIGURER VOTRE HEBERGEMENT LINUX Ref : FP. P858 V 6.0 Ce document vous indique comment utiliser votre hébergement Linux à travers votre espace abonné. A - Accéder à la gestion de votre Hébergement...

Plus en détail

CAHIER DE S CHARGE S Remote Workload Manager

CAHIER DE S CHARGE S Remote Workload Manager CAHIER DE S CHARGE S Remote Workload Manager équipe Regis Rouyard (rouyar_r) Jonathan Bouchot (boucho_o) Johan Massin (massin_j) Jacky Rouquette (rouque_j) Yannick Boillon (boillo_o) EPITECH INOVATION

Plus en détail

Pourquoi ai-je besoin de recompiler apache? Comment recompiler apache? Comment récupérer les entêtes eid en PHP?

Pourquoi ai-je besoin de recompiler apache? Comment recompiler apache? Comment récupérer les entêtes eid en PHP? 1 Généralité Qu'elle est l'architecture générale d'une application eid en ligne? Client / PC-SC / Reverse Proxy / Serveur applicatif TODO gure architecture JPG A quel niveau se fait/font la/les vérication(s)

Plus en détail

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Version utilisée pour la Debian : 7.7 Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Caractéristiques de bases : Un service web (ou service de la toile) est

Plus en détail

Manuel d utilisation de la plate-forme de gestion de parc UCOPIA. La mobilité à la hauteur des exigences professionnelles

Manuel d utilisation de la plate-forme de gestion de parc UCOPIA. La mobilité à la hauteur des exigences professionnelles Manuel d utilisation de la plate-forme de gestion de parc UCOPIA La mobilité à la hauteur des exigences professionnelles 2 Manuel d utilisation de la plate-forme de gestion de parc UCOPIA 1 Table des matières

Plus en détail

Licence Pro ASUR ------------ Supervision ------------ Mai 2013

Licence Pro ASUR ------------ Supervision ------------ Mai 2013 GRETA VIVA 5 Valence 2013 Licence Pro ASUR ------------ Supervision ------------ Mai 2013 Auteur : Emmanuel Veyre eveyre.formateur@gmail.com Sommaire de la formation Les bases de la supervision d un système

Plus en détail

Projet Supervision et sécurité

Projet Supervision et sécurité Projet Supervision et sécurité Page 1 sur 18 Sommaire Rappel de la demande... Étude de l existant... Architecture réseau... Choix du logiciel de supervision... Qu est ce que la supervision?... Le marché

Plus en détail

Guide rapide GFI LANguard

Guide rapide GFI LANguard Guide rapide GFI LANguard INTRODUCTION Bienvenue dans GFI LANguard : Votre solution tout en un pour la gestion de correctifs, l'analyse de vulnérabilités et l'audit réseau. GFI LANguard (ou "LANguard")

Plus en détail

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts E3FI ESIEE Paris Systèmes et scripts B. Perret TP : Shell Scripts 1 Remarque générale Lorsque vous cherchez des informations sur Internet, n'oubliez pas que langage de shell script que nous avons vu correspond

Plus en détail

Guide d'installation

Guide d'installation 1/7 The-Excalibur.com The Excalibur "hors ligne" : La poker-clock sans connection Internet Guide d'installation 2/7 Sommaire 1 Important... 3 2 Présentation... 3 3 Pré-requis... 3 4 Installation du serveur

Plus en détail

ManageEngine IT360 : Gestion de l'informatique de l'entreprise

ManageEngine IT360 : Gestion de l'informatique de l'entreprise ManageEngine IT360 Présentation du produit ManageEngine IT360 : Gestion de l'informatique de l'entreprise Améliorer la prestation de service à l'aide d'une approche intégrée de gestion des performances

Plus en détail

Prise en compte des ressources dans les composants logiciels parallèles

Prise en compte des ressources dans les composants logiciels parallèles Prise en compte des ressources dans les composants logiciels parallèles Aperçus de l action RASC et du projet Concerto F. Guidec Frederic.Guidec@univ-ubs.fr Action RASC Plan de cet exposé Contexte Motivations

Plus en détail

PostgreSQL, le cœur d un système critique

PostgreSQL, le cœur d un système critique PostgreSQL, le cœur d un système critique Jean-Christophe Arnu PostgreSQLFr Rencontres Mondiales du Logiciel Libre 2005 2005-07-06 Licence Creative Commons Paternité - Pas d utilisation commerciale - Partage

Plus en détail

Plan de notre intervention 1. Pourquoi le test de charge? 2. Les différents types de tests de charge 1.1. Le test de performance 1.2.

Plan de notre intervention 1. Pourquoi le test de charge? 2. Les différents types de tests de charge 1.1. Le test de performance 1.2. Plan de notre intervention 1. Pourquoi le test de charge? 2. Les différents types de tests de charge 1.1. Le test de performance 1.2. Le test aux limites 3. Méthode 2.1. Pré-requis 2.2. Préparation des

Plus en détail

SUPERVISION BASÉE SUR SHINKEN.

SUPERVISION BASÉE SUR SHINKEN. SUPERVISION BASÉE SUR SHINKEN. THÈSE DE BACHELOR PRÉSENTÉE PAR Monsieur Huseyin BILGIN Pour l obtention du titre Bachelor of Science HES-SO en Ingénierie des technologies de l information avec orientation

Plus en détail

Portage et développement de jeux Java sur téléphones mobiles. Licence Professionnelle SIL 25 juin 2007

Portage et développement de jeux Java sur téléphones mobiles. Licence Professionnelle SIL 25 juin 2007 Portage et développement de jeux Java sur téléphones mobiles Table des matières I Présentation de l'entreprise II Présentation des projets effectués III Le portage d'un jeu sur téléphones mobiles IV Conclusion

Plus en détail

VRM Monitor. Aide en ligne

VRM Monitor. Aide en ligne VRM Monitor fr Aide en ligne VRM Monitor Table des matières fr 3 Table des matières 1 Introduction 3 2 Vue d'ensemble du système 3 3 Getting started 4 3.1 Démarrage de VRM Monitor 4 3.2 Démarrage de Configuration

Plus en détail

LES FONCTIONS DE SURVEILLANCE DES FICHIERS

LES FONCTIONS DE SURVEILLANCE DES FICHIERS SYSLOG and APPLICATION LOGS Knowledge Module for PATROL - Data Sheet Version 1.5 Développé par http://www.axivia.com/ PRESENTATION DU PRODUIT SYSLOG and APPLICATION LOGS Knowledge Module for PATROL est

Plus en détail

www.generation-linux.fr

www.generation-linux.fr LYCEE RAYMOND-POINCARE - BAR-LE-DUC Section de techniciens supérieurs en informatique de gestion. Option «Administrateur de réseaux locaux d entreprise». Mise en place d'une solution de sauvegarde en réseau

Plus en détail

SUJET : «Administration et supervision du réseau Par NAGIOS»

SUJET : «Administration et supervision du réseau Par NAGIOS» U.S.M.B.A «Mini Projet En Réseau» Etudiants En 2ème Année Informatique, Administration de systémes et Réseaux Matiére : Administration des services SUJET : «Administration et supervision du réseau Par

Plus en détail

DÉVELOPPEMENT INFONUAGIQUE - meilleures pratiques

DÉVELOPPEMENT INFONUAGIQUE - meilleures pratiques livre blanc DÉVELOPPEMENT INFONUAGIQUE MEILLEURES PRATIQUES ET APPLICATIONS DE SOUTIEN DÉVELOPPEMENT INFONUAGIQUE - MEILLEURES PRATIQUES 1 Les solutions infonuagiques sont de plus en plus présentes sur

Plus en détail

Cyberclasse L'interface web pas à pas

Cyberclasse L'interface web pas à pas Cyberclasse L'interface web pas à pas Version 1.4.18 Janvier 2008 Remarque préliminaire : les fonctionnalités décrites dans ce guide sont celles testées dans les écoles pilotes du projet Cyberclasse; il

Plus en détail

Principaux utilisateurs du Réseau

Principaux utilisateurs du Réseau Bienvenue à l innovant apptap, la première solution intégrée de l'industrie à combiner les capacités de collecte de données sur le réseau (Tap) avec le suivi du réseau et des applications. Cette nouvelle

Plus en détail

Migration dynamique d applications réparties virtualisées dans les fédérations d infrastructures distribuées

Migration dynamique d applications réparties virtualisées dans les fédérations d infrastructures distribuées Migration dynamique d applications réparties virtualisées dans les fédérations d infrastructures distribuées Djawida Dib To cite this version: Djawida Dib. Migration dynamique d applications réparties

Plus en détail

Administration Réseau

Administration Réseau Refonte du LAN, Administration, Performance & Sécurité. Projet réalisé par Jean-Damien POGOLOTTI et Vincent LAYRISSE dans le cadre d un appel d offre Description du projet Le design suivant a été réalisé

Plus en détail

RapidMiner. Data Mining. 1 Introduction. 2 Prise en main. Master Maths Finances 2010/2011. 1.1 Présentation. 1.2 Ressources

RapidMiner. Data Mining. 1 Introduction. 2 Prise en main. Master Maths Finances 2010/2011. 1.1 Présentation. 1.2 Ressources Master Maths Finances 2010/2011 Data Mining janvier 2011 RapidMiner 1 Introduction 1.1 Présentation RapidMiner est un logiciel open source et gratuit dédié au data mining. Il contient de nombreux outils

Plus en détail

Conception d'un système d'information WEB avec UML Par Ass SERGE KIKOBYA

Conception d'un système d'information WEB avec UML Par Ass SERGE KIKOBYA Conception d'un système d'information WEB avec UML Par Ass SERGE KIKOBYA I. Introduction Suite à une demande des étudiants, il m'est apparu intéressant de montrer, à travers un exemple concret, comment

Plus en détail

Présentation d'un MOM open-source

Présentation d'un MOM open-source Présentation d'un MOM open-source Saber Dir - Victor Laborie - Guillaume Penaud Licence ASRALL 25 mars 2015 Middleware Orientés Message 25 mars 2015 1 / 29 Sommaire 1 Introduction 2 Etat de l'art 3 Maquette

Plus en détail

TER SUPERVISION RESEAU

TER SUPERVISION RESEAU COPONAT Pierre-Adrien REYNIER Serge MASTER2 SIR TER SUPERVISION RESEAU Page 1 sur 20 SOMMAIRE SOMMAIRE... 2 INTRODUCTION... 3 I. Présentation... 4 I.1. Objectifs... 4 I.2. Principe... 4 II. Le protocole

Plus en détail

SweetyPix, mode d'emploi

SweetyPix, mode d'emploi Université de Nice Sophia-Antipolis Master 1 STIC Informatique SweetyPix, mode d'emploi Edouard Jan Mendher Merzoug Anne-Laure Radigois Amaury Tinard 2005-2006 Université de Nice Sophia-Antipolis Master

Plus en détail

Quels usages des données massives pour les statistiques publiques? Enjeux, méthodes et perspectives

Quels usages des données massives pour les statistiques publiques? Enjeux, méthodes et perspectives Quels usages des données massives pour les statistiques publiques? Enjeux, méthodes et perspectives Stéphanie Combes et Pauline Givord (DMCSI) INSEE-DMSCI 02/04/2015 Plan Qu'est-ce que le Big Data? Les

Plus en détail

FazaANGEL supervision pro-active

FazaANGEL supervision pro-active presentation FazaAngel - page 1/7 FazaANGEL supervision pro-active FazaAngel : supervision pro-active fazaangel surveille tous les «éléments de votre infrastructure : télécom, réseau, serveur, site web

Plus en détail

Cours Langage C/C++ Programmation modulaire

Cours Langage C/C++ Programmation modulaire Cours Langage C/C++ Programmation modulaire Thierry Vaira BTS IRIS Avignon tvaira@free.fr «v0.1 Rappel Programmation modulaire (1/2) Le découpage d'un programme en sous-programmes est appelée programmation

Plus en détail

Logiciels libres et sécurité

Logiciels libres et sécurité Logiciels libres et sécurité Frédéric Schütz, PhD schutz@mathgen.ch Groupe romand des Utilisateurs de Linux et Logiciels Libres http://www.linux gull.ch/ Une image négative reste liée à Linux, celle des

Plus en détail

IFSIC Université de Rennes 1 Campus de Beaulieu 35042 RENNES CEDEX. IRISA INRIA Équipe MYRIADS Campus de Beaulieu 35042 RENNES CEDEX

IFSIC Université de Rennes 1 Campus de Beaulieu 35042 RENNES CEDEX. IRISA INRIA Équipe MYRIADS Campus de Beaulieu 35042 RENNES CEDEX IFSIC Université de Rennes 1 Campus de Beaulieu 35042 RENNES CEDEX IRISA INRIA Équipe MYRIADS Campus de Beaulieu 35042 RENNES CEDEX Migration dynamique d'applications réparties virtualisées dans les fédérations

Plus en détail

Gestion et Supervisions des Réseaux Introduction à la gestion et supervision des réseaux

Gestion et Supervisions des Réseaux Introduction à la gestion et supervision des réseaux Gestion et Supervisions des Réseaux Introduction à la gestion et supervision des réseaux These materials are licensed under the Creative Commons Attribution-Noncommercial 3.0 Unported license (http://creativecommons.org/licenses/by-nc/3.0/)

Plus en détail

Stockage du fichier dans une table mysql:

Stockage du fichier dans une table mysql: Stockage de fichiers dans des tables MYSQL avec PHP Rédacteur: Alain Messin CNRS UMS 2202 Admin06 30/06/2006 Le but de ce document est de donner les principes de manipulation de fichiers dans une table

Plus en détail

RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS

RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS Université Joseph Fourier Département Licence Sciences & Technologie RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS Laboratoire d'accueil : Verimag

Plus en détail

Système et réseau : mise en oeuvre et exploitation

Système et réseau : mise en oeuvre et exploitation Système et réseau : mise en oeuvre et exploitation Géraldine Del Mondo - Mathieu Petit Version. grincheux et dormeur 1 Introduction La nalité de ce TP est double : Vous familiariser avec l'environnement

Plus en détail

Fiche de Poste. Responsable du Datacenter et du CCIPL

Fiche de Poste. Responsable du Datacenter et du CCIPL Fiche de Poste Responsable du Datacenter et du CCIPL IDENTITE DU POSTE Intitulé du poste : Responsable du Datacenter et du CCIPL Profil : Catégorie A/A+, Ingénieur de Recherche titulaire ou contractuel

Plus en détail

Tutorial Ophcrack. I) Ophcrack en API. (ou comment utiliser Ophcrack pour recouvrir un mot de passe sous Windows XP et Windows Vista)

Tutorial Ophcrack. I) Ophcrack en API. (ou comment utiliser Ophcrack pour recouvrir un mot de passe sous Windows XP et Windows Vista) Tutorial Ophcrack (ou comment utiliser Ophcrack pour recouvrir un mot de passe sous Windows XP et Windows Vista) Ophcrack est un utilitaire gratuit permettant de cracker les mots de passe des sessions

Plus en détail

IN411-TP1 Conception d'une zone démilitarisée

IN411-TP1 Conception d'une zone démilitarisée IN411-TP1 Conception d'une zone démilitarisée RENOUX Charles ROUESSARD Julien TARRALLE Bruno ROHAUT Fanny SCHAPIRA Boris TEA Christophe le 16 Octobre 2005 Table des matières Introduction 2 1 Routage Classique

Plus en détail

Fully Automated Nagios

Fully Automated Nagios Fully Automated Nagios Table des matières Présentation... 2 Fully Automated Nagios:... 2 Nagios:... 2 Centreon:... 2 NDOUtils:... 2 Nagvis:... 2 Installation... 3 Premier Démarrage... 7 Configuration...

Plus en détail

Mémo d'utilisation de BD Dico1.6

Mémo d'utilisation de BD Dico1.6 Mémo d'utilisation de BD Dico1.6 L'application BDDico a été développée par la Section Cadastre et Géomatique de la RCJU. Son utilisation demeure réservée aux personnes autorisées. Les demandes d'utilisation

Plus en détail

Grid Technology. ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Technology Group Information Technology Department

Grid Technology. ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Technology Group Information Technology Department DB GT CF Grid ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Group Information Department Journée de la communauté FUSE, Paris, 2010 CERN IT Department CH-1211 Geneva 23 Switzerland

Plus en détail

eth0 10.254.52.1/24 eth1 10.52.1.1/24 Sn Serveur Apache

eth0 10.254.52.1/24 eth1 10.52.1.1/24 Sn Serveur Apache APACHE Configuration et administration d un serveur 1 : Mise en place du réseau Schéma logique stp 10.254.0.254 eth0 10.254.52.1/24 eth0 10.52.1.3/24 eth1 10.52.1.1/24 Sn Serveur Apache eth2 10.52.2.1/24

Plus en détail

Programme de formations. été 2015

Programme de formations. été 2015 conseil et services en logiciels libres Programme de formations été 2015 Les logiciels libres et Linux...2 1 Quels logiciels libres pour mon activité professionnelle?...2 2 Découvrir Linux et son utilisation

Plus en détail

TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique

TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique Bilan technique et éléments de développement Fonctionnalités attendues Une vingtaine d établissements

Plus en détail

LOCAL TRUST Charte Open-Source

LOCAL TRUST Charte Open-Source LOCAL TRUST Charte Open-Source Juillet 2011 Pourquoi cette Charte? ATEXO, dans son développement, met en avant le caractère open-source de ses solutions LOCAL TRUST Or la désignation "open-source" fait

Plus en détail

Le monitoring de flux réseaux à l'in2p3 avec EXTRA

Le monitoring de flux réseaux à l'in2p3 avec EXTRA Le monitoring de flux réseaux à l'in2p3 avec EXTRA Journée JoSy «Supervision systèmes et réseaux dans un laboratoire de recherche» 27 mars 2008, ENS Paris Denis Pugnère, CNRS / IN2P3 / IPNL basé sur une

Plus en détail

Grid 5000 : Administration d une infrastructure distribuée et développement d outils de déploiement et d isolation réseau

Grid 5000 : Administration d une infrastructure distribuée et développement d outils de déploiement et d isolation réseau : Administration d une infrastructure distribuée et développement d outils de déploiement et d isolation réseau Nicolas Niclausse - INRIA Sophia Antipolis Méditerranée - projet Aladdin Grid 5000 2 juillet

Plus en détail

Poursuivre ses études à l'université de Rouen Masters professionnels en Informatique et en Mathématiques. UFR Sciences et Techniques 20-03-2014 1/18

Poursuivre ses études à l'université de Rouen Masters professionnels en Informatique et en Mathématiques. UFR Sciences et Techniques 20-03-2014 1/18 Poursuivre ses études à l'université de Rouen Masters professionnels en Informatique et en Mathématiques UFR Sciences et Techniques 20-03-2014 1/18 Masters pro GIL, SSI et AIMAF Taux d'insertion : 100

Plus en détail

Formation Solarwinds Standard, Pro & Expert

Formation Solarwinds Standard, Pro & Expert Standard, Pro & Expert Contact +33 (0)1 34 93 35 35 Sommaire INTRODUCTION Offre INTRA entreprises Offre INTER entreprises p.2 p.2 Les lieux - Votre profil p.3 Contenu de la formation - Présentation générale

Plus en détail

Windows 8 Installation et configuration

Windows 8 Installation et configuration Editions ENI Windows 8 Installation et configuration Collection Ressources Informatiques Extrait 112 Windows 8 Installation et configuration Pour terminer l'application de l'image, nous devons configurer

Plus en détail

Chap. 2 : gestion du code source avec Git/GitHub

Chap. 2 : gestion du code source avec Git/GitHub Chap. 2 : gestion du code source avec Git/GitHub L'objectif de ce cours est de présenter une solution libre et gratuite pour la gestion du code source : l'outil Git associé à la forge logicielle GitHub.

Plus en détail

Raspberry pi : Développer une petite application web sur Raspberry

Raspberry pi : Développer une petite application web sur Raspberry Raspberry pi : Développer une petite application web sur Raspberry Introduction Le Raspberry Pi est un nano-ordinateur basé sur une architecture ARM (conçu par David Braden) qui permet l'exécution de plusieurs

Plus en détail

Laboratoire de Haute Sécurité. Télescope réseau et sécurité des réseaux

Laboratoire de Haute Sécurité. Télescope réseau et sécurité des réseaux Laboratoire de Haute Sécurité Télescope réseau et sécurité des réseaux Frédéric Beck (SED) & Olivier Festor (Madynes) CLUSIR Est - 15 Décembre 2011 Inria : Institut de recherche en sciences du numérique

Plus en détail

Centreon. Description. Paramétrage de Centreon. Table des matières. Les machines

Centreon. Description. Paramétrage de Centreon. Table des matières. Les machines Table des matières Centreon Préambule Description Installation Paramétrage de Centreon Les machines Les services Planification des notifications Ajout d'une nouvelle commande dans Centreon Application

Plus en détail