Stage de Rosendo Bonnilla - IUT Charlemagne Nancy - [3/04/18 au 22/06/18]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter Thomas K., Christophe

Sujet

• Proposition de stage

Stage (Avril - Juin 2018)

Avril

• 3, arrivée
  • Renseignement sur PerfSONAR
  • Types de architecture
  • Placement de noeuds (interieur/exterieur)
  • Installation de PerfSONAR Bundle sur ma machine (Debian 9), rajout de dépôts perfsonar dans sources.list
  • Création d'un test simple (ping) de la machine PerfSONAR au router de l'observatoire. Dans l'interface d'administration de PerfSONAR Toolkit
• 4, continuacion documentation
  • Révision plus en détail des méthodes de déploiment (beacon, island, mesh)
  • Révision Hardware vs Machines virtuelles
  • Révision architecture de PerfSONAR
• 5,
  • Vidéo-conférence avec M Renan PHILLIPE - présentation PerfSONAR
  • Définition (à peu près) de l'architecture à mettre en place dans l'Observatoire
  • Définition des étapes à suivre
• 6,
  • Création de deux machines virtuelles VirtualBox
  • Problèmes avec ces deux machines-là
  • Bascule sur LXC
  • Installation de LXC, snapd et LXD pour gérer les conteneurs
  • Création de deux conteneurs LXC et installation de PerfSONAR là dedans (node1.lxd et node2.lxd). Le premier noeud (node1.lxd) aura PerfSONAR Toolkit et MaddAsh
  • Problèmes avec NTP (NTP non syncronisé) sur les conteneurs car je les avait mis en mode privilegié (Sol. changer à false security.privilegied dans la configuration des conteneurs)
• 9, séminaire d'accueil
  • Création du fichier mesh.conf pour administrer plusieurs hosts au même temps. On va y specifier l'enterprise ou organisation pour les sondes PerfSONAR, les sondes à superviser, les différents tests périodiques à réaliser, groupes de test et les serveurs d'archivage ou consulter les resultats des test pour ensuite creer les graphiques et les grids sur MaddAsh
  • Conversion du fichier précedent au format JSON
  • Publier le fichier sur un serveur web (apache2 dans ce cas)
  • Configuration des clients pour utiliser le fichier (fichier /etc/perfsonar/meshconfig-agent.conf)
  • Installation de MaddAsh sur une des deux conteneurs
  • Création de la configuration - maddash.yaml (en fait il suffit de laisser dans le fichier de configuration par défaut le chemin de la base de données et le port sur lequel maddash va à écouter ou tout simplement de vider ce fichier là). Après ce dernier va être réécrit par l'outil perfsonar-meshconfig-guiagent de manière automatique
  • Problèmes pour récuperer les données des test ("No data found" dans les graphics, pareil pour MaddAsh)
• 10,
  • Les test ne fonctionnent toujours pas, il semble être un problème avec les conteneurs LXC, genre DNS. En effet, dans l'interface web PerfSONAR Toolkit les test définis dans le fichier mesh.central.conf s'affichent cependant les test ne marchent pas
  • Le probleme avec les conteneurs et les test était que l'outil pscheduler a un fichier appelle "limits.conf" ou on trouve des regles de blocage pour certains groupes d'addresses IP (des attacants connus, plages d'addresses privées, etc) y compris celui de LXC/LXD 10.254.11.0/24. Il a fallu enlever cette regle pour que les test etaient propagés.
  • Problème bwctld[21699]: FILE=sapi.c, LINE=391, BWLControlAccept(): Unable to read ClientGreeting message. Pas de solution por l'instant mais les test et les grids marchent.
  • Probleme Couldn't find ma for host: perfSONAR_PS::MeshConfig::Config::Address=HASH(0x51dd118) at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/Generators/MaDDash.pm line 342. (Sol. rajouter les directives <measurement_archive> correspondantes dans le fichier mesh-conf car le script ne les trouvait pas)
  • Problem writing maddash.yaml: Problem writing to /etc/maddash/maddash-server/maddash.yaml: Couldn't open /etc/maddash/maddash-server/maddash.yaml for writing at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/GUIAgent.pm line 302. (Sol. changer le propietaire du fichier maddash.yaml, son propietaire etait "root" et je croyait que c'etait correct. Apres avoir verifier plusieurs fois les logs j'ai decide de changer le propietaire et le groupe par "maddash" et ca a bien tourné)
  • Pour l'instant les grids sur l'interface MaddAsh marchent bien on peut voir les test qui échouent et ceux qui réussisent (plutôt les paquets perdus). Cependant, je vois des paquets perdus de node2.lxd vers node1.lxd même si dans les graphics ils s'affichent correctement. De node1.lxd à node2.lxd il n'y a pas de soucis, tout marche bien.
  • Quelques minutes après tous les test de latence entre les deux noeuds marchent bien, pas de problèmes rencontrés dans le grid; il semble OK. Je pense qu'il suffissait juste d'attendre un peu pour que les données étaient propagés dans les deux directions.
• 11,
  • Installation de CentOS 7 sur la machine qui sera la sonde dans le Batiment Sud
  • Création du fichier mesh-central.conf adapté aux sondes de l'observatoire
  • Création des machines virtuelles VMWare (sondes coupule et Est)
• 12,
  • Révision de la méthode pour utiliser deux interfaces pour lancer des tests différents
  • Division des hosts par organization (Observatoire Astronomique de Strasbourg et IPHC/CNRS Strasbourg)
  • Création de nouveaux tests pour la mesure de la bande pasante en UDP et TCP
  • Définition et création des groupes pour les tests
  • Modification du fichier mesh-central.conf pour prendre en compte les tests vers des sondes à l'exterieur
  • Problemes avec les conteneurs LXC, cette erreur apparait toujours une fois la machine redemarre. Le probleme est que les conteneurs n'arrivent pas a recuperer une addresse IP (Sol. redemarrer le service snapd et snap restart lxd)
  • Les machines virtuelles pour mettre en place les sondes reelles ne sont pas pour l'instant disponibles, je fais donc des tests sur les conteneurs LXC
  • Plusieurs problemes avec le nouveau fichier mesh-conf.
  • D'abord, Problem generating maddash configuration: Problem generating maddash configuration: Can't use an undefined value as an ARRAY reference at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/Generators/MaDDash.pm line 1093. Je pouvait pas definir un groupe "start" car il y avait des soucis pour créer la configuration de maddash, je donc opté pour un groupe "disjoint". Ce groupe on l'utilisera pour etablir des test avec de sondes a l'exterieur. Ensuite, j'ai du changer aussi l'instruction "no_agent".
  • Probleme Couldn't find a tool in common among the participants. Selon moi ca vient des test qui se lancent a l'exterieur (avec la sonde CNRS Strasbourg par exemple) et alors il y a des problemes de compatibilité entre les outils de test des deux sondes (evidemment on connait pas du tout les outils qu'ils on mis en place).
  • Les grids sur MaddAsh semblent bien marcher sauf pour les tests a l'exterieur que l'on corrigera dans les sonde reelles
• 13,
  • Création de machines virtuelles lesquelles seront les différentes sondes (Coupole, Est et Sud)
  • Test du fichier mesh.conf crée auparavant
  • Problemes genre Problem generating maddash configuration: Can't use an undefined value as an ARRAY reference at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/Generators/MaDDash.pm line 1093.
  • Probleme, la page d'administration de chaque sonde bloqué a un moment donné, on peut voir le test qui se executen mais la page reste en "Loading" et si on clique au dessus on y accede par contre la page n'est pas chargée du tout
• 16,
  • Reprise des problemes precedents
  • Config de maddash.yaml marche toujours pas
  • J'ai verifié plusieurs fois les fichiers config des sonde réelles et celles des conteneurs et semblent etre les memes
  • Error Instruction 'checks' not defined : Sol. ce que j'ai fait c'est de recuperer le fichier config maddash.yaml dans ma machine depuis le conteneur et ensuite le copier sur la sonde a travers SSH et l'adapter. Le fichier marche.
  • Problem reading remote meshes: Can't use an undefined value as an ARRAY reference at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/GUIAgent.pm line 183. J'ai pas reussit a trouver la cause de cette erreur. Maintenant je me retrouve avec quelque chose qui pouvait etre la cause, les demon de pscheduler n'executent pas de facon normal sur une des sondes (Coupole). J'ai verifie les differents scripts appeles lors de la creation automatique de maddash.yaml, notamment, le script perfsonar_meshconfig_guiagent. Selon ce que j'ai compris, avant la creation du fichier maddash.yaml ce script consulte les differents test definis sur chaque sonde (crees a partir du fichier mesh-central fournit pour la sonde principal -Sud-) mais il arrive pas a communiquer avec la sonde Coupole a cause de la defaillance de pscheduler sur cette sonde la.
  • Aupres les fichier de logs de pscheduler de la sonde Coupole je me retrouve qu'il cherche une connexion avec postgresql mais il arrive pas a le faire. Le logs disent une possible solution : verifier si le port 5432 correspondant a postgresql est ouvert. En effet, ce port la n'est pas ouvert dans cette sonde.
  • Probleme de PostgreSQL resolu
  • Toujours le meme probleme Problem reading remote meshes: Can't use an undefined value as an ARRAY reference at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/GUIAgent.pm line 183.
• 17,
  • Reprise de problemes precedents
  • D'abord reprise du problem des pages d'administration de perfSONAR qui ne chargent pas les services ni les informations basiques des hosts. Dans les fichiers de logs de httpd on trouve : Can't exec "/sbin/runlevel": Permission denied at /usr/lib/perfsonar/web-ng/root/services/../../../lib/perfSONAR_PS/NPToolkit/Services/Base.pm line 168., referer: http://ops-sc.u-strasbg.fr/toolkit/. En fait, ce script la verifie d'abord que les services de perfSONAR soient lances dans le niveau d'execution 2-5. Cependant on a essaye en changeant notre runlevel de 3 a 5 et ca marche toujours pas (on a decide de le changer car dans les test dans des conteneurs LXC on a bien un runlevel 5 et tout marche bien).
  • On essaie en créant une nouvelle machine virtuelle mais avec une autre image ISO de CentOS (pas celle minimale) pour voir si la cause des problemes etait liee a une manque de paquets ou quelque chose comme ca
• 18,
  • Au debut le meme probleme liee a l'image ISO, on a decide d'installer l'image ISO fournie par perfSONAR.
  • On a cree un machine virtuelle dbug juste pour tester les differents images
  • L'installation de l'image fournie par perfSONAR marche bien et donc on l'a installee sur toutes les machines virtuelles et la machine physique de la Coupole
  • Toutes les machines ont desormais un perfSONAR Toolkit qui marche correctement
  • Toujours le meme probleme Problem reading remote meshes: Can't use an undefined value as an ARRAY reference at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/GUIAgent.pm line 183.
• 19,
  • Toute la journée utilisée pour corriger le probleme pour creer le fichier de conf de MaddAsh
  • J'ai verifié plusieurs fois les differents fichiers de conf et les scripts de perfSONAR mais aucune solution pour l'instant
  • Christophe est venu m'aider pour essayer de trouver la cause du probleme
  • Un probleme qui pourrait entrainer les autres est celui lie au reseau : sur la machine virtuelle Sud on avait deux interfaces reseau definies dans le meme reseau, ca casse l'addressage de la machine
  • On a verifie encore les fichiers de logs et les scripts
  • On utilise tcpdump et Wireshark pour analiser les differents flux entre chaque sonde et essayer de trouver les paquets lies au problem
  • Aucune solution trouve
  • En fait, le probleme vient de deux scripts en Perl qui echouent : /usr/lib/perfsonar/lib/perfSONAR_PS/MeshConfig/GUIAgent.pm et /usr/lib/perfsonar/bin/perfsonar-meshconfig-guiagent
  • Ce dernier est charge de verifier les test des sondes distantes et c'est la ou ca bloque
  • Juste pour verifier, j'ai essaye de reduire au maximun le space d'erreur. Je n'ai definit que deux tests et que deux sondes et supprimé une des deux interfaces réseau
  • Fin de journée sans une solution trouvée
• 20,
  • Reprise de probleme precedent
  • J'ai analisé encore une fois les scripts ou tout bloque
  • J'ai essayé d'exécuter le script /usr/lib/perfsonar/bin/perfsonar-meshconfig-guiagent en mode debug à l'aide de perl -d (perldebuger) mais rien de important trouvé (bon, je suis pas tres familier à cet outil)
  • J'ai modifié les scripts pour registré plus d'info sur les fichiers de logs (quelques variables; etc)
  • À la fin j'ai trouvé la solution !! :')
  • Je me suis rendu compte que le script cherche la definition de l'URL pour recuperer le fichier JSON depuis le serveur principal dans deux fichiers (pas dans un seul fichier de conf comme dans les autres sondes). Explication : quand on installe perfSONAR Toolkit et on veut créer une groupe de hosts à superviser on doit créer un fichier principal avec toute la config de tests et de hosts. Ensuite ce fichier doit etre publié sur un serveur pour que le reste de sondes puissent le recuperer et definir les test en local (ses propres tests en local ca veut dire que toutes les sondes feront de tests à toutes les sondes). Pour que les sondes aient acces a ce fichier, on doit les indiquer ou le trouver, alors on doit modifier le fichier /etc/perfsonar/meshconfig-agent.conf et y mettre l'URL vers le fichier JSON (ca on doit le faire sur toutes les sondes y compris la sonde principal). Tout ca je l'avais deja fait mais les scripts quand-meme echouaient. Normalment, on n'a qu'un seul fichier a modifier dans chaque sonde (le fichier /etc/perfsonar/meshconfig-agent.conf) pour qu'elles fassent partie de l'ensemble des sondes à tester. Cependant, la sonde principale (machine virtuelle sonde Sud) sert aussi comme serveur MaddAsh et lors de l'installations de ce dernier, le script meshconfig-guiagent.conf est aussi installé, ce fichier la se trouve dans le meme repertoire que meshconfig-agent.conf. C'est pourquoi les scripts montraient l'erreur : Problem reading remote meshes: Can't use an undefined value as an ARRAY reference at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/GUIAgent.pm line 183, car j'avais oublié de modifier ce fichier la avec l'URL ou recuperer le fichier JSON.
  • Une fois cette erreur corrigée, les script marchent et creent la config du serveur MaddAsh.
  • Maintenant, on a un tableau de bord tout fonctionnel
  • Pour certains test on a pas encore d'informations, notamment ceux de bande pasante en interne et vers l'exterieur car ca prend du temps pour se faire (normalment quelques heures)
  • Les tests ping, latence et traceroute marchent tres bien, aucun problem trouvé dans les grids
  • Travail sur la creation des scripts pour automatiser la creation
• 23,
  • Création de une premiere version du script pour l'ajout de nouvelles sondes
  • Script crée en bash
  • Analyse des alternatives pour mettre à jour le fichier de conf
  • Analyse de la création d'un template de conf
• 24,
  • Création d'un template grace a Jinja2
  • Création d'un script en plus en Python pour gérer les modifications du fichier de conf
  • Traitement du template avec un fichier YAML servant à remplir le template
  • Modif du script en bash pour le rendre plus propre : division en bloques, création de functions, traitement d'erreurs, installation de dependences
  • Ajout d'interface graphique en terminal pour les informations demandées lors de l'exécution du script
  • Premiers tests sur des conteneurs LXC
  • Ajouter la compatibilité avec Debian et CentOS
• 25,
  • Etude de la solution Automatic Test Configuration with MeshConfig pour faciliter l'addition et suppresion de nouvelles sondes
  • Si cette config marche, on mettra de conté les scripts faits jusqu'à present
  • Premiere tentative de deployement d'un Private Lookup Service sur un conteneur LXC sous CentOS 7
  • Installation de dependences faite : mongo-db, JDK Java, lookup-service.rpm
  • Installation de Lookup Service echoué à cause d'un probleme de compatibilité avec CentOS 7
  • Création d'un conteneur LXC sous CentOS 6 pour tester l'installation
  • Installation d'abord des paquets perfSONAR et MaddAsh
• 26,
  • Premiere configuration du PLS
  • L'installation de Lookup Service s'est bien pasée
  • Probleme pour telecharger le fichier LS Bootstrap Service, il se trouve plus dans le repos de Internet. Alternative : le telecharger manuellement du site de Internet2 en FTP : par contre ces outils n'on été testés qu'en CentOS et on sait pas si il sont toujours à jour
  • Probleme avec la config du PLS, il semble etre un souci avec les ports dont l'outil a besoin
  • Mise au point des besoins de l'Observatoire : si on part de la documentation de perfSONAR on trouve que les test dynamiques se font (forcément) entre toutes les sondes (type mesh) et l'objectif de l'observatoire c'est de faire juste les tests entre les mirroirs et la sonde batiment Sud à l'Observatoire et pas entre sondes. On a pas donc besoin (il vaut pas la peine) de mettre en place un Lookup Service et deployer les tests dynamiques.
  • Je reprend les scripts d'automatisation précedents
• 27,
  • Amelioration du script pour travailler avec des functions
  • Création d'un script un Python chargé de creer le nouveau fichier meshconfig
• 30,
  • Definition d'un arborescence pour le script. Un repertoire specifique pour la config mesh : repertoires sites et backup
  • Le script marche bien en CentOS et Debian
  • Pas d'integration de la sonde a un groupe por l'instant
  • Etude de la posibilite d'utiliser une petite base de données pour toutes les informations. Premiere tentative, SQLite
  • D'apres moi, il vaut pas la peine de mettre en place une base de données car chaque objet et composé juste d'une paire d'attributs (sauf pour les tests qu'ils en ont plusieurs, par contre le script est surtout centré sur l'administration des sondes -sites- pas sur les test pour le moment). En plus, une BDD prende de l'espace disque et de la memoire. Enfin, l'ajout de sondes ne se fera pas tres frequement, le script ne se lancera donc qu'eventualement.

Mai

• 1, jour ferié
• 2,
  • Maintenant, le script permet de choisir le groupe de la sonde. J'ai defini deux groupes, le premier de type mesh pour les sondes en interne et le deuxieme de type disjoint pour les miroirs.
  • Amelioration de script pour executer plus de taches : lister les sondes, en ajouter ou en supprimer
  • Amelioration de la function aide() pour etre plus comprehensible
  • Substitution de 'getops' par ' while : ' . Comme ca, on peut specifier plus de choses. Le nouveau usage du script est :
    • Usage : ./add_sonde-2.0.sh --action=[list,add,delete] --dir=[répertoire]
    • --action : spécifie quelle type de tache on veut réaliser.
      • list : affiche la liste des sondes définies dans le fichier meshconfig
      • add : permet d'ajouter une nouvelle sonde
      • delete : permet de supprimer une sonde
    • --dir : spécifie le chemin vers le répertoire où se trouve toute la configuration MESH.
  • Formatage de la sortie de la tache action=list
  • Affichage d'un example d'arborescence quand le script ne trouve pas les fichiers nécessaires
  • Création de la function tache_sup() pour supprimer une sonde : cette tache ecrase le lien symbolique dans le repertoire 'groupes' et supprime le site du repertoire 'sites'. En plus, el crée une nouvelle configuration, meshconfig
• 3,
  • Reprise script
  • Thomas Keller a installe une sonde chez lui pour tester les mesurements depuis l'exterieur
  • J'ai modifie le fichier meshconfig pour y rajouter la nouvelle sonde
  • Sonde prise en compte dans le tableau de bord
  • Problemes pour realiser les tests de bande pasante et de latence owamp a cause d'un probleme de pare feu du router de Thomas, par ailleurs il a ouvert certains ports du pare feu de l'observatoire pour teste la connectivite. Pour jeter une erreur du scheduler j'ai lancé des test manuellement avec owping -c 5 -v 82.244.189.212 et ca produissait l'erreur
    • owping: FILE=protocol.c, LINE=1515, _OWPReadAcceptSession:Unable to read from socket
    • owping: FILE=owping.c, LINE=200, Session Failed!
  • Le probleme est peut-etre les ports en UDP de l'outil OWAMP. Il y a toujour le probleme : ops.u-strasbg.fr powstream[24107]: OWPControlOpen([82.244.189.212]:861): Waiting 59.493093997 seconds before retrying (l'addresse 82.x.x.x est la sonde chez Thomas), on a verifie a l'aide de netstat et nmap si le port 861 etait ouvert et en effet il etait bien ouvert. A l'aide de tcpdump j'ai regarde les paquets envoyes entre les deux machines concernees, tous semblait etre bien. Apres, j'ai fait pareil mais cette fois ci, entre la sonde Sud et celle de la Coupole et j'ai constate qu'en plus de l'envoi de paquets sur le port 861 l'outil OWAMP en envoyait aussi sur les ports genre 9xxx.
• 4,
  • Reprise script
  • J'ai montre a Thomas ce qui le script fait pour l'instant pour prende en consideration des nouvelles fonctionnalités. On a jetté l'idee de mettre en place une base de donnees avec le script
  • Division de body.cfg en differents fichiers : premier solution pour traiter la configuration restante
  • Test du script dans Debian et CentOS
• 7,
  • J'ai montre le script a Christophe et il m'a confirme que l'utilisation d'une base de donnees n'est pas necessaire
  • On a decide de traiter les tests dans le script, dans le futur on pourrait souhaiter rajouter de nouveaux tests
  • Creation d'un nouveau repertoire /tests dans le repertoire /mesh principal, j'y ai ajoute tous les test disponibles pour le moment, chacun dans un fichier pour suivre la meme methode des sites. En plus; j'ai cree un repertoire dans /tests appellé /actives et la dedans un fichier actives.cfg contenant la relation entre les tests et les groupes
  • Travail sur l'affichage et selection des test dans un checklist avec whiptail
  • Travail sur la possibilite de montrer les test qui tournent dans le checklist : ces tests la seront deja selectiones dans le checklist.
  • La partie precedente fonctionne deja mais le code cest un peu le bordel, je verrai apres son optimisation
  • En attente, la modif de active.cfg pour prende en compte les tests selectionnes pour l'utilisateur
  • Une fois cette partie marche a peu pres bien, j'ai modifie l'usage du script pour prende en compte la nouvelle fonctionnalité et j'ai renomme les scripts pour leur donner un nom plus parlant et plus adapte. L'usage desormais est :
  • Usage : ./manage_sonde.sh --action=[list,add,delete,conftest] --dir=[répertoire]
    • --action : spécifie quelle type de tache que l'on veut réaliser.
      • list : affiche la liste des sondes définies dans le fichier meshconfig
      • add : permet d'ajouter une nouvelle sonde
      • delete : permet de supprimer une sonde
      • conftest : permet de sélectionner les tests qui tourneront
    • --dir : spécifie le chemin vers le répertoire où se trouve toute la configuration MESH.
• 8, jour ferié
• 9,
  • Modif script pour pouvoir ajouter une description pour chaque definition de test
  • Creation d'une function dans le script creation_meshconfig.py pour optimiser la creation des bloques de test
  • Rendre la possibilite de modifier directement la partie de tests, action=conftest, car le script echouait quand on demandait de faire juste cette partie. En plus, quand on demandait l'action delete ou add le script echouait aussi car il necessitait forcement les parametres de la tache conftest. Maintenant, cette partie est traitee.
• 10, jour ferié
• 11,
  • Travail sur le script
  • Il y a un probleme avec le traitement des descriptions de chaque test : si la tache est add ou delete, je met des descriptions par defaut (dans ce cas le nom de groupe) et ca c'est pas tres pertinent. Ensuite, si le tache est conftest, on doit indiquer toutes les descriptions de tous les tests a chaque lancement meme si on veut changer juste un test. Le probleme vient de que je ne stocke dans aucune partie la description. Ca serait une bonne idee de sauvegarder les descriptions dans le fichier ou je stocke le groupe et les tests (il s'agit du fichier actives.cfg).
  • Je vois aussi la maniere pour pouvoir modifier les parametres de chaque test facilement : je pense a le faire avec whiptail et checklist ou radiolist
  • Creation d'un boutton whiptail pour ajouter la tache 'avancee' et pouvoir modifier les parametres des test
  • Traitement des bouttons 'Annuler' dans chaque partie pour eviter des erreurs
• 14,
  • Traitement des descriptions plus efficace : maintenant lorsqu'on choisi la tache add ou delete le script ne demande pas les descriptions de chaque test ou mets de descriptions par defaut qui ne sont tres correctes, le script stocke et lit les descriptions a l'aide du fichier actives.cfg. Avec la tache conftest, on peut activer/desactiver des tests et le script demandera juste les descriptions des nouveaux tests pas toutes comme il faisait avant. Tout ceci, je l'ai traite avec des dictionnaires en Python, j'ai relie chaque test avec sa description comme ca je peux comparer facilment les tests selectionnes par l'utilisateur avec ceux tournant sur le serveur.
  • Test du script dans des conteneurs LXC CentOS : la dedans, un serveur perfsonar tourne et alors on peut tester la creation du nouveau fichier JSON et redemarrer les services perfsonar pour verifier que le script marche bien
  • Etude de SaltStack pour traiter la modification du fichier meshconfig-agent.conf de la nouvelle sonde
• 15,
  • Corrections de certaines erreurs du script
  • On a parle tous les trois sur l'avancement du projet : le script, la config des sondes et tout ce qu'il manque à faire
• 16,
  • Test du script directement sur le serveur Maddash et il marche
  • J'essaie de traiter le sondes à l'exterieur de facon plus optimale : pouvoir ajouter des sondes qui n'appartiennent pas à l'observatoire en tant que nouvelles organisation et pas faisant partie de l'organisation Observatoire
  • Thomas a ouvert tous les port nécessaires sur la sonde chez lui pour verifier si maintenant les tests marchent
  • Malheureusement, les test ne marchent pas du tout a cause du meme probleme :
    • owping: FILE=protocol.c, LINE=1515, _OWPReadAcceptSession:Unable to read from socket
    • owping: FILE=owping.c, LINE=200, Session Failed!
  • Si je lance un test owping de la sonde de Thomas vers ops.u-strasbg.fr ou sbgperfps1.in2p3.fr j'au une erreur :
    • owping: FILE=capi.c, LINE=711, Server denied test: sbgperfps1.in2p3.fr
    • owping: FILE=owping.c, LINE=200, Session Failed!
    • En cherchant sur internet et le forum de perfsonar j'ai trouvé que perfsonar ne marche bien lorsqu'on fait du NAT car les outils OWAMP et BWCTL nécessitent se lier à une seule addresse specifique et tel chose n'arrive pas avec du NAT
    • mai 16 13:12:22 ops.u-strasbg.fr owampd[17349]: FILE=sapi.c, LINE=610, Test Denied: OpenMode recieve_addr(10.0.0.10) = control_client(her67-1-82-244-189-212.fbx.proxad.net)
    • https://lists.internet2.edu/sympa/arc/perfsonar-user/2014-12/msg00088.html
    • http://linlog.blogspot.fr/2009/06/owamp-problems-behind-nat.html
  • Thomas a décidé de mettre sa sonde dans une VPN et comme ca arriver a faire de tests, ca marche mais a la fin c'est comme si la sonde etait en local
  • La nouvelle sonde ajoutee doit redemarrer le service perfsonar-meshconfig-agent pour prendre en compte les tests recuperes a partir du fichier JSON
  • Correction du script pour bien supprimer la sonde indique car je la cherchait dans l'arborescence a l'aide de 'ls' mais ca ne marchait pas avec le repertoire no_agent, j'ai change 'ls' pour 'find' pour parcourir aussi les sous-repertoires
  • Differents tests du script sur le serveur perfsonar et il semble bien marcher pour toutes les tache
• 17,18
  • Tests de scripts
  • Corrections
  • Echanges avec la sonde CANADA
  • Reject une sonde
• 22-25
  • Commence rapport
  • Echanges avec John
  • RENATER contact
  • Sonde RENATER desormais joignable
  • Video-conf avec John

Juin

• pré-soutenance de stage

Liens

• Installer le toolkit dans les hosts
• Création des utilisateurs pour administres l'interface web du toolkit
• Création du fichier de configuration mesh
• Convertion du fichier précedente au format JSON
• Publier le fichier
• Configurer les clients pour utiliser ce fichier
• Instaler maddash
• Modifier le configuration de maddash
• Configuration automatique du fichier maddash.yaml (Pas nécessaire du tout dans la version récente de PerfSONAR car le démon perfsonar-meshconfig-guiagent le fait de manière automatique)
• Internet 2 mailing list server

Versions testables

• ...

Documentation

• ...

Travail post stage éventuel

• ...

Liste des améliorations à envisager

• Demain, 12/04 - ajout des nouveaux test en UDP au fichier mesh-central.conf - FAIT
• Demain, 17/04 - Debogguer Problem reading remote meshes: Can't use an undefined value as an ARRAY reference at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/GUIAgent.pm line 183. - FAIT 20/04
• Semaine prochaine - Script d'automatisation - FAIT 24/04
  • Modifs script python
    • Ajout MaJ fichier conf mesh
    • Error handling
  • Modifs script bash
    • Error handling
  • Terminal-based GUI

Bugs connus

• Problème bwctld[21699]: FILE=sapi.c, LINE=391, BWLControlAccept(): Unable to read ClientGreeting message. Pas de solution por l'instant mais les test et les grids marchent. *********LXC*********
• Problem reading remote meshes: Can't use an undefined value as an ARRAY reference at /usr/lib/perfsonar/bin/../lib/perfSONAR_PS/MeshConfig/GUIAgent.pm line 183.
• Probleme Couldn't find a tool in common among the participants. *********LXC*********
• Latence negative, surtout pour les test entre sondes internes. Dans la doc de perfSONAR on trouve les informations suivantes :
  • If a facility is interested in collecting internal data, be aware of several properties of network measurements over short paths:
    • Throughput tests are unlikely to be useful, as short RTT tests will frequently exhibit high values, even if packet loss or other factors are impacting TCP.
    • Throughput tests will consume network resources quickly, and due to the short RTT may not back off ; this could hurt background traffic that is trying to use network resources and traveling over a longer RTT.
    • Latency testing from OWAMP requires stable, accurate, and precise measurements from NTP. In many cases NTP can synchronize a clock to the microsecond level, in others there may be a few milliseconds of difference. For short RTTs, the clock skew will become very noticeable, and in some cases may produce negative latency values due to the error in NTP correlation. [ Source]
• rapport-stage-final.pdf: Rapport_stage_final-Rosendo

• presentation-stage.pdf: Presentation soutenance Nancy-Charlemagne