résumé

Résumé, fiche descriptive

PLUME : historique du projet et de la plate-forme depuis août 2013

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 04/11/13
  • Correction mineure : 04/11/13
Mots-clés

PLUME : historique du projet et de la plate-forme depuis août 2013

Ce document liste les principales étapes et réalisations du projet et de la plate-forme PLUME, par ordre chronologique, depuis août 2013.

Les actions et réalisations précédentes se trouvent :

2013

Applications et méthodes de monitoring Java

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 19/09/13
  • Correction mineure : 19/09/13
Mots-clés

Applications et méthodes de monitoring Java

  • Type de ressource : article, référentiel, résumé
  • Date de publication du document ou de l'événement : Avr 2013
  • Auteur(s) ou responsable(s) : Stéphane Deraco
  • Contact pour plus d'informations : java@services.cnrs.fr

Que faut-il surveiller ?

Surveiller une application peut vouloir dire plusieurs choses selon les besoins et le contexte de l'application. Par exemple, une application contrôlant un élément d'un accélérateur de particules ne sera pas surveillée de la même manière qu'une application chargée d'envoyer un mail dès qu'une page d'un wiki est modifiée.

La surveillance peut être technique (est-ce que mon application fonctionne correctement, est-ce que les performances sont acceptables, combien y a-t-il d'utilisateurs en ce moment) ou fonctionnelle (combien de factures ont été traitées ce mois-ci, pour quel montant).

Quels outils pour surveiller ?

Les outils de surveillance d'une application Java peuvent se diviser en deux catégories : les outils fournissant des données instantanées, et les outils permettant de conserver un historique des données, certains outils fournissant les deux.

Beaucoup d'outils utilisent la fonctionnalité JMX, qui permet d'exposer des informations via des MBeans.

Logs

La mise en place de logs est le minimum à faire dès lors que l'on souhaite surveiller une application.

La solution la plus basique est d'utiliser la méthode System.out.println pour écrire les lignes de logs dans la console. Le problème avec cette solution est qu'elle n'est pas évolutive : on ne peut pas choisir les niveaux de logs, ni quels composants logger.

C'est pour cela que l'on utilise un cadriciel (framework) de log. Les plus courants sont les suivants :

  • JUL (java.util.logging) : c'est le framework de logs implémenté dans la JVM. Il n'est pas beaucoup utilisé, car il n'a été introduit dans Java qu'à partir de la version 1.4.
  • Apache Log4J : c'est l'un des framework de logs les plus utilisés.
  • Logback : c'est un framework écrit par l'auteur de Log4j, qui apporte des améliorations par rapport à ce dernier.
  • Apache Commons Logging et SLF4J : ce sont des façades permettant de choisir l'implémentation de logs. L'utilisation de façade est utile car dans un projet Java utilisant plusieurs librairies tierces, chacune peut utiliser un framework de logs différent. La façade permet d'unifier cela.

Les avantages à utiliser un framework de logs sont les suivants :

  • Pouvoir choisir le niveau de logs à logger.
  • Pouvoir choisir, composant par composant, quel est le niveau de logs.
  • Les données loggées ont ainsi des priorités différentes.
  • Possibilité d'utiliser des destinations différentes pour les logs (fichiers, base de données, JMS, etc).

Avoir une librairie de logs ne suffit pas pour pouvoir surveiller efficacement son application Java. Le choix de ce qu'il faut logger est très important. Il n'en faut pas trop pour ne pas noyer les informations importantes, ni trop peu pour en avoir assez.

Il peut être intéressant d'avoir plusieurs destinations de fichiers de logs, selon les besoins :

  • un fichier full qui contient tous les logs,
  • un fichier securité contenant les logs relatifs à la sécurité (tentatives de connexions, actions sensibles, etc.),
  • un fichier audit pour pouvoir tracer les événements qui surviennent dans l'application.

Il est intéressant de noter que la destination des logs peut être autre chose que des fichiers, et qu'un même message de logs peut être envoyé vers plusieurs destinations. La plupart des librairies de logs permettent d'envoyer les logs en base de données, sur une file d'attente JMS, sur une socket, par mail ou encore sur le système de log Linux syslog. Cependant, il faut en général toujours envoyer les logs critiques au moins dans un fichier, pour être sûr qu'ils soient disponibles (une base de données peut ne pas être montée, le broker JMS peut être saturé, etc.).

L'utilisation de logs permet de surveiller ce qui se passe en temps quasi réel, mais aussi d'accéder à l'historique.

JMX

http://fr.wikipedia.org/wiki/JMX

JMX est une spécification Java permettant d'exposer des MBeans présents dans la JVM. Un MBean est simplement une classe Java exposant des getters et des méthodes.

Cela permet par exemple d'accéder à des attributs de la JVM tels que le temps total de compilation. On peut également appeler des méthodes.

Il est donc possible d'ajouter dans notre programme Java des MBeans afin de les exposer via JMX. Cela permet de remonter des valeurs, ou d'appeler des méthodes de notre programme. Par exemple, Tomcat expose les MBeans User, Role, mais aussi le nombre de requêtes pour chaque servlet. On peut également stopper un port donné, expirer une session, etc.

Utiliser JMX dans une application Java permet donc facilement, avec les outils adéquats, d'interagir avec l'application et de surveiller ce qui se passe dans la JVM, aussi bien au niveau technique qu'au niveau fonctionnel (il suffit d'écrire les MBeans correspondant).

La plupart des outils suivants se basent sur JMX pour remonter les informations.

JConsole

http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html

JConsole est présent dans le JDK. C'est une interface graphique affichant des graphes décrivant le fonctionnement de la JVM. On y trouve par exemple un graphe affichant la mémoire Heap utilisée, le nombre de threads actifs, ou encore le pourcentage d'utilisation du CPU.

JConsole permet également de consulter les MBeans exposés par la JVM.

JConsole permet de se connecter à une JVM locale, mais également à une JVM distante (il faut effectuer une configuration au niveau de la JVM distante).

Dans le cas où le réseau bloque les ports empêchant JConsole de se connecter à une JVM distante, il est possible d'utiliser un tunnel SSH. Pour cela, on peut utiliser PuTTY :

  • Aller dans la section Connection/SSH/Tunnels, puis dans Add new forwarded port, renseigner un numéro de port quelconque dans Source port (ce sera le port du proxy SOCKS), puis sélectionner Dynamic.
  • Cliquer sur Add. Dans le tableau au dessus, une ligne doit s'ajouter avec le numéro de port préfixé par la lettre D.
  • Se connecter au serveur distant en SSH avec PuTTY.
  • Lancer JConsole avec la commande suivante : jconsole.exe -J-DsocksProxyHost=localhost -J-DsocksProxyPort=10000 (avec 10000 le port renseigné dans PuTTY).

JConsole permet de voir ce qui se passe à un instant donné dans l'application, mais ne permet pas de consulter l'historique. JConsole ne conserve que l'historique depuis son démarrage.

JVisualVM

http://docs.oracle.com/javase/7/docs/technotes/tools/share/jvisualvm.html

JVisualVM est également présent dans le JDK. Il reprend les fonctionnalités de JConsole sur l'affichage de graphes sur les mesures internes de la JVM.

JVisualVM ne permet pas de base d'accéder aux MBeans de la JVM. Cependant, il a un mécanisme de plugins qui permet de rajouter un onglet MBeans (VisualVM-MBeans) offrant les mêmes fonctionnalités que JConsole.

De plus, d'autres plugins sont intéressants :

  • Visual GC : affichage précis des différents pools de mémoire de la JVM, ainsi que les temps utilisés par le Garbage Collector.
  • Tracer-JVM Probes : sondes permettant d'afficher des graphes sur des comportements internes de la JVM (utilisation des Collections, les buffers NIO, etc.).

JVisualVM permet de se connecter à une JVM locale, mais également à une JVM distante (il faut effectuer la même configuration au niveau de la JVM distante que pour JConsole).

Dans le cas où le réseau bloque les ports empêchant JVisualVM de se connecter à une JVM distante, il est possible d'utiliser un tunnel SSH de la même manière que pour JConsole. Il suffit, après avoir activé le proxy SOCKS, d'aller dans JVisualVM dans le menu Tools > Options > Network (proxy SOCKS).

JVisualVM permet de voir ce qui se passe à un instant donné dans l'application, mais ne permet pas de consulter l'historique. JVisualVM ne conserve que l'historique depuis son démarrage.

JMX Term

http://wiki.cyclopsgroup.org/jmxterm

C'est un outil en ligne de commande permettant d'accéder aux MBeans. L'avantage c'est que l'on peut l'utiliser même si on n'a pas d'interface graphique (sur un serveur Linux sans X11 par exemple). Il est fourni sous forme d'un Jar exécutable.

Une fois le Jar lancé, on se connecte à une JVM locale, puis on navigue dans les domaines et les MBeans, pour enfin afficher les valeurs, les renseigner, ou appeler des méthodes.

JMX Term offre également la possibilité d'être utilisé via des outils de scripts, tels que Perl ou un shell. Voici par exemple un extrait du site de JMX Term :

open JMX, "| java -jar $jar -n";

 print JMX "help \n";

 my $host = "localhost";

 my $port = 9991;

 print JMX "open $host:$port\n";

 print JMX "domains\n";

 print JMX "close\n";

 close JMX;

JMX Term ne conserve pas d'historique.

jmxtrans

https://github.com/jmxtrans/jmxtrans

Cet outil a pour objectif d'extraire des informations de différentes JVMs, puis de les envoyer vers d'autres outils pour leur traitement. Il a pour vocation d'être performant avec un grand nombre de JVMs à analyser.

Il fonctionne en tâche de fond. Une fois lancé, il lit des fichiers de configuration écrits en JSON ou YAML, dans lesquels sont décrits les serveurs à analyser, le port JMX, les objets MBeans à interroger, et la façon dont envoyer les données des MBeans.

Par exemple, il est possible de lui demander d'interroger le MBean java.lang:type=OperatingSystem, et de récupérer les valeurs des attributs SystemLoadAverage et FreePhysicalMemorySize, puis d'envoyer ces valeurs dans un fichier texte.

La façon dont JMXTrans traite les données récupérées se fait par la notion de Writer. Il existe des Writers pour écrire les données sur la console, dans un fichier texte, mais aussi vers Graphite (outil web de visualisation de données), ou encore vers des fichiers de type RRD (utilisés entre autre par Nagios, Cacti).

JMXTrans permet donc de surveiller un ensemble de JVMs (sur des attributs de notre choix), et d'envoyer ces données à d'autres outils pour affichage ou analyse.

Par sa nature, JMXTrans permet de conserver l'historique : il tourne en tâche de fond, et les Writers accumulent les données reçues. C'est à la charge des outils externes (Graphite, Nagios, etc.) d'afficher ces données historisées.

Jolokia

http://www.jolokia.org/

Cet outil permet de récupérer les données des attributs de MBeans par des services web REST. Il se greffe dans une JVM et est ensuite interrogeable par une URL, dans laquelle on indique les MBeans à interroger (pour récupérer des valeurs d'attributs, ou appeler des méthodes). Le format retourné par l'URL est du JSON.

La façon d'intégrer Jolokia dans une JVM peut se faire de différente manière : via un war à mettre dans Tomcat, un bundle OSGi, ou un agent Java (spécifié dans la commande java lançant l'application).

Jolokia permet donc de faciliter l'interrogation d'une JVM pour obtenir des données sur son fonctionnement. Il est ensuite facile d'utiliser un autre outil tel que Nagios pour automatiser la récupération d'informations via Jolokia.

Jolokia fournit un instantané de ce qui se passe dans la JVM, c'est à la charge des outils qui l'utilisent d'historiser les données.

HawtIO

http://hawt.io/

C'est une webapp déployable sous un conteneur de servlet (Tomcat par exemple), qui permet de se connecter à une JVM locale ou distante (la connexion à une JVM distante se fait en utilisant Jolokia - Jolokia doit donc être installé sur la JVM distante).

HawtIO met à disposition une interface web permettant de consulter les données exposées (par JMX ou Jolokia) d'une JVM. Il est possible de consulter les données, mais également d'afficher des graphes pour des données numériques.

Ce projet est en plein développement, mais semble prometteur. Il a un système de plugin permettant d'afficher des vues spécifiques selon les frameworks utilisés dans la JVM. Par exemple, s'il détecte qu'il y a le broker ActiveMQ, alors il va rajouter un onglet spécifique facilitant la consultation des données du Broker. De même, si Tomcat est détecté, alors un onglet dédié permettra d'arrêter des applications, de voir les sessions, etc.

HawtIO permet de grapher les données numériques, mais l'historique se limite à la durée de connexion à HawtIO.

YourKit & JProfiler

http://www.yourkit.com/

http://www.ej-technologies.com/products/jprofiler/overview.html

Ces deux outils permettent, comme JConsole et VisualVM, de se connecter à une JVM locale et distante, et d'afficher des informations sur cette JVM.

La force de ces outils est de proposer des méthodes pour détecter ce qui consomme le plus de ressources dans le programme.

Notamment, la détection de fuites mémoire est grandement facilitée avec ces outils, qui montrent le nombre d'instances de chaque objet, et quels sont les objets qui gardent une référence sur ceux-ci, empêchant le garbage collector de les supprimer.

Eclipse MAT

http://www.eclipse.org/mat/

Cet outil est assez similaire dans les objectifs à YourKit et JProfiler, mais il fonctionne sur un Heap Dump. C'est à dire que son utilisation est plutôt post mortem.

Cette page explique comment générer un Heap Dump sur une application existante, et quels paramètres fournir à Java pour qu'il génère automatiquement un Heap Dump en cas de OutOfMemoryError. Cela permettra d'analyser a posteriori les causes d'une fuite mémoire sur un système en production.

Apache JMeter & Gatling

http://jmeter.apache.org/

http://gatling-tool.org/

Ce sont des outil de tests de performance, permettant de tester la résistance d'applications sous différents cas d'utilisation. Les tests de performances peuvent être de différents types, par exemple : tests de charge, tests de stress, tests d'endurance, etc. Cette page explique les différents types de tests.

Ils ne permettent pas d'analyser directement le fonctionnement d'une JVM (ni en cours de fonctionnement, ni à partir d'un Heap Dump), mais ils permettent de s'assurer que notre application (Java ou autre) réponde bien à différents scénarios. Ils produisent par contre des rapports et des graphiques permettant de s'assurer que notre application répondra correctement dans ces cas d'utilisation.

OpenSearch : spécification pour standardiser les fonctions de recherche en ligne

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 21/05/13
  • Correction mineure : 21/05/13
Mots-clés

OpenSearch : spécification pour standardiser les fonctions de recherche en ligne

  • http://www.opensearch.org
  • Type de ressource : résumé
  • Date de publication du document ou de l'événement : 2005
  • Auteur(s) ou responsable(s) : A9 (filiale d'Amazon.com)

Description courte :

OpenSearch est une spécification qui offre des services de recherche sur un site Internet et ce, indépendamment de la technologie du moteur de recherche utilisé par ce site. L'objectif est de proposer un standard pour la recherche et la publication sur Internet.

Avec cette technologie, il est ainsi possible d'agréger et d'afficher les résultats de plusieurs sites de recherche différents. On peut par exemple effectuer la même requête sur une base de données documentaire, un dictionnaire en ligne et un wiki, et afficher les résultats sur une même page.

Il est également possible de rajouter son moteur de recherche sur n'importe quel client de recherche qui contient un agrégateur OpenSearch (dans lequel on peut configurer son fichier de description OpenSearch). L'un des exemples d'utilisation les plus connus de cette technologie est l'intégration de listes de sites de recherche dans les navigateurs web (champ de recherche situé à droite de la barre d'URL sur Firefox et Internet Explorer).

Documents de standardisation : La dernière spécification se trouve ici : OpenSearch 1.1 (Draft 5)

Description détaillée :

OpenSearch ne remplace pas un moteur de recherche mais propose donc une surcouche afin d'uniformiser les formats de publication. En ce sens, on peut apparenter cette technologie à un « service web » pour la recherche sur Internet.

Techniquement, OpenSearch utilise XML et les flux de syndication (RSS ou Atom).

Pour pouvoir offrir tous les composants nécessaires à la recherche standardisée sur Internet, la spécification OpenSearch est composée de quatre formats complémentaires :

  • OpenSearch description document

    C'est un fichier XML qui identifie et décrit le moteur de recherche. En plus de l'adresse du namespace de la spécification «http://a9.com/-/spec/opensearch/1.1/», ce fichier doit contenir au moins les 3 balises obligatoires suivantes : ShortName pour le nom du service, Description pour sa description et Url qui contient l'adresse du site de recherche.

  • OpenSearch URL template syntax

    Ce format contient différents paramètres qui permettent de décrire la syntaxe de recherche utilisée par le moteur de recherche. Il précise notamment les règles de grammaire de l'attribut template de la balise Url utilisée dans le document de description précédent.

  • Opensearch Query element

    Ce format permet de configurer des requêtes spécifiques par un client de recherche. Il est composé d'un ensemble d'attributs de la balise Query. On peut par exemple proposer un exemple de requête qui peut être effectuée sur le moteur de recherche ou encore afficher des résultats avec des mots proches de celui utilisé par la requête (mais contenant une faute d'orthographe par exemple).

  • OpenSearch response elements

    C'est le format de présentation des résultats de recherche. Les formats possibles nativement sont RSS 2.0 et Atom 1.0. D'autres formats de publication sont possibles comme HTML/XHTML.

En plus de ces formats, il existe plusieurs extensions, parmi lesquelles :

  • Referrer

    Permet de fournir des informations sur la source effectuant la recherche, comme par exemple le logiciel client utilisé

  • Relevance

    Permet d'indiquer le score de chaque résultat d'une recherche donnée

  • Suggestion

    Permet l’auto-complétion de mots dans le champ de recherche.

Pour l'utilisation de chacune de ces extensions, il faudra ajouter l'adresse du namespace XML de la spécification dans le fichier de description.D'autres extensions sont encore à l'état de draft mais offriront des possibilités intéressantes, notamment :

  • Geo extension

    Propose de fournir un mécanisme standard pour effectuer des recherches sur des données géographiques, comme des coordonnées ou des noms d'endroits.

  • Mobile extension

    Propose un mécanisme standard pour adapter les recherches de type OpenSearch aux terminaux mobiles, notamment dans l'affichage des résultats.

Utilisations recommandées :

Tout site utilisant OpenSearch peut être directement intégré au navigateur en utilisant la zone de recherche adaptée.

OpenSearch peut également être utilisé sur des applications hébergeant des moteurs de recherche et fournissant des services en ligne. Cela peut rendre l'application plus générique et permet d'accepter des requêtes à partir d'autres applications. Un exemple d'application en milieu scientifique est le logiciel SITools2 qui intègre nativement un champ de recherche OpenSearch. D'autre part, de nombreux CMS ou wiki implémentent opensearch soit de manière native soit grâce à un plugin: par exemple WordPress, SPIP,Drupal, PLONE, GetNetwork, DokuWiki, MediaWiki

OpenSearch est également très utilisé pour les recherches sur les sites bibliographiques car contenant de multiples bases de données provenant de sources différentes (voir par exemple le site de la revue internationale Nature : http://www.nature.com/opensearch).

Exemple de mise en œuvre :

Pour pouvoir configurer un service OpenSearch sur un moteur de recherche, il faut effectuer les trois étapes suivantes :

  • Configurer le moteur de recherche pour proposer en option une réponse au format RSS ou Atom (cela permettra d'utiliser les paramètres du format OpenSearch response elements)

  • Créer un fichier de description au format OpenSearch description document

    Le fichier minimum doit être de la forme :

    <?xml version="1.0" encoding="UTF-8"?>
    <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
      <ShortName>${name}</ShortName>
      <Description>${name}</Description>
      <Url type="application/html" template="${url}/suggest?q={searchTerms}">
      </Url>
    </OpenSearchDescription>

    Où ${name} est le nom du site et ${url} l’adresse du site.

  • Publier le fichier précédent en ajoutant un lien dans le header de la page d'accueil du site de recherche.

    Si par exemple le fichier s'appelle opensearch.xml :

    <link rel="search" type="application/opensearchdescription+xml" title="${name}" href="${url}/opensearch.xml">

Une étape supplémentaire peut être d'envoyer ce fichier de description à l'un des annuaires de moteurs de recherche supportant OpenSearch pour faire connaître le service de recherche.

Il existe en outre de nombreuses bibliothèques qui implémentent les services OpenSearch. Une liste détaillée se trouve ici :
http://www.opensearch.org/Community/OpenSearch_sof...

 

VNC : prise en main de poste distant

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 23/10/12
  • Correction mineure : 04/02/13
  • Auteur : Dirk Hoffmann (Centre de Physique des Particules de Marseille (CPPM-IN2P3))
Mots-clés

VNC : prise en main de poste distant

Introduction

VNC désigne à la fois un protocole de prise en main d'un poste (sous Windows, Linux, MacOS, etc.) et les logiciels qui l'implémentent. Cette fiche ressource se veut générique dans le sens où elle décrit le protocole VNC ainsi que les caractéristiques communes aux logiciels qui l'implémentent.
Cette fiche reprend délibérément le format d'une fiche logiciel, plus exhaustif (et contraignant) qu'une fiche ressource.

Un site générique pour VNC en tant que protocole n'existe pas. Le domaine historique vnc.com renvoie vers le site de la société RealVNC, issue d'une partie de l'équipe initiale des développeurs et détenteur de la marque déposée VNC™. Voir plus loin pour les sites des différentes implémentations, commerciales ou libres, du protocole VNC.

Fonctionnalités générales

Prendre la main (vue de l'écran et contrôle du clavier et de la souris) sur une machine distante, pour faire par exemple de l'administration ou de l'assistance utilisateur. VNC utilise le protocole RFB (remote frame buffer), qui peut s'appliquer à tous les systèmes affichage "en fenêtres" (dont Windows, le protocole X11 et Macintosh). De par sa conception extensible, il a permis aux différentes implémentations (depuis la fin des années 1990) de rester largement compatible entre elles.

Plate-formes et interopérabilité

Fonctionne sur toutes les plate-formes majeures (Windows, Linux, MacOS, etc.), sans problème d'interopérabilité. Cela signifie qu'un client à partir d'un système d'exploitation donné peut se connecter à un serveur tournant sur un autre système d'exploitation. Cependant, l'interopérabilité entre les différents logiciels VNC (saveurs) n'est pas toujours donnée, surtout quand le logiciel serveur et le logiciel client ont des dates de fabrication trop éloignée l'une de l'autre.

Contexte d'utilisation dans mon laboratoire/service

  • serveur VNC sur un serveur Windows pour l'administration à distance,
  • serveur VNC sur des postes clients pour faire de l'assistance à distance,
  • serveur VNC sous Linux, des clients VNC permettent aux utilisateurs d'accéder à cet environnement depuis des PCs Windows.

Limitations, difficultés, fonctionnalités importantes non couvertes

Le protocole est vulnérable à certains types d'attaques, quoique le mot de passe et la transmission des données soient cryptés. Des solutions à base de tunnels SSH ou de VPN sécurisés permettent de pallier cette faiblesse.

Distributions dans lesquelles ce logiciel est intégré

Quasiment toutes les distributions Linux intègrent un client/serveur VNC.

Logiciels implémentant le protocole VNC

  • RealVNC: http://www.realvnc.com/, existe en version gratuite "Free" (licence propriétaire), "Personal" et "Enterprise Edition". La version Free est distribuée pour Windows, Linux x86, Solaris 7, HP-UX 11, code source (Unix) et code source pour le Viewer en Java et pour Windows.
  • TightVNC: http://www.tightvnc.com/, entièrement gratuit (octobre 2011) en licence GPL. Dernière version (2.5) serveur + client disponible pour Windows. Une version précédente (1.3) également en saveur "Unix-like", ainsi que source et "binaire" en Java pour un Viewer en version 2.6.
  • TigerVNC: http://tigervnc.sourceforge.net/, est un fork de TightVNC fondé par un ancien co-développeur de TightVNC pour diverses raisons. Ce dérivé se veut " high performing, stable and generic". Est disponible gratuitement en licence GPL.
    Je n'ai pas pu le tester, mais il est distribué avec Fedora 13 par exemple.
  • UltraVNC: http://www.ultravnc.fr/, gratuit en licence GPL, donations possibles, pour Windows.
  • Vine Server/Client : http://www.testplant.com/support/downloads/vine/, précédemment distribué sous le nom OSXvnc, est un couple serveur/client VNC libre et open-source de TestPlant, Inc., vendu également avec un service support par la même entreprise.

Des fiches logiciels pour ces applications n'existent pas actuellement dans PLUME. Si vous êtes utilisateur régulier d'une de ces "saveurs" de VNC, contactez l'auteur de la fiche pour contribuer à la collection avec votre description du logiciel.

Autres logiciels aux fonctionnalités équivalentes

  • Symantec pcAnywhere (client et serveur payants).
  • Windows Terminal server (payant) et client RDP (intégré à Windows ou rdesktop, FLOSS pour Unix)
  • Nomachine NX, logiciel commercial, mais version gratuite "Free Edition" disponible qui est limitée à deux utilisateurs (comptes) déclarés simultanément sur la machine serveur. (Voir NX-Freenx pour une implémentation gratuite.)

Historique et Éléments de pérennité

Le protocole a été développé à l'origine dans les laboratoires de recherche joints des sociétés Olivetti et Oracle. Les laboratoires ont été vendus en 1999 à la société AT&T, qui ferma les activités de recherche en 2002. Suivant cette fermeture, plusieurs développeurs du projet ont fondé RealVNC, afin de pouvoir continuer à produire le code open source et commercial sous ce nouveau nom. Les sources ont été mises sous licence GPL et réutilisées (forked) par plusieurs autres équipes de développement.
Aujourd'hui, de (trop ?) nombreuses implémentations du client/serveur disponibles sur la majorité des plate-formes existent.
Protocole éprouvé et très répandu.

Références d'utilisateurs institutionnels

  • ATLAS control room management / sysadmins (CERN).
  • Accès à distance local (labo) et international (collaborations) au CPPM (CNRS).
  • Utilisation de VNC pour l'administration et l'intervention à distance sur les postes gérés par les ASR du LAAS (CNRS).

Augmentation de la sécurité du protocole

Le protocole VNC n'était pas un protocole sécurisé à la base, et malgré des progrès récents, surtout dans des versions commerciales de l'implémentation, il convient de donner quelques conseils pour augmenter la sécurité.

Serveur VNC sous Windows

  • Via la base de registre côté serveur, il est possible de n'autoriser que certaines adresses ou plages d'adresses IP à se connecter à un serveur VNC en paramétrant une valeur "AuthHosts" ou "Hosts" selon l'implémentation de VNC utilisée ("AuthHosts" VNC et UltraVNC , "Hosts" pour RealVNC).

  • Le paramétrage d’AuthHosts est une clé de type REG_SZ employée pour indiquer un ensemble de masques d’adresses IP que les connexions entrantes doivent respecter afin d’être acceptées. Par défaut, le masque est vide et les connexions de tous les centres serveurs sont acceptées. Le masque est de la forme :
    +[masque d’IP]
    ?[masque d’IP]
    -[masque d’IP]

Explications :

Le [masque d’IP] représente l'adresse IP ou le masque de sous-réseau qui doit être pris en compte. Il peut être de la forme 192.168.1.10 (et désignera alors une adresse IP précise), ou 192.168 (et désigner l'ensemble du sous-réseau 192.168.x.x et toutes les adresses IP en faisant partie).

    • le symbole "+" indique que le [masque d’IP] correspondant est autorisé.
    • le symbole "-" indique que le [masque d’IP] correspondant est interdit.
    • le symbole "?" indique que le [masque d’IP] correspondant doit être accepté côté serveur par l'intermédiaire d'une fenêtre de dialogue.
    • le symbole ":" (VNC) ou "," (RealVNC) sert de délimiteur, permettant ainsi de définir plusieurs valeurs.

On aura donc par exemple comme valeur de clé :
HKEY_LOCAL_MACHINE\Software\RealVNC\WinVNC4
"AdminPassword"=hex:dc,c6,6b,58,6d,e4,19,7c
"Hosts"="+192.168.82.0/255.255.254.0,?192.168.0.0/255.255.0.0,-255.255.255.255/0.0.0.0"

Serveur VNC sous Linux ou Windows avec SSH

Il est possible de rediriger les ports utilisés par VNC vers la machine locale à travers un tunnel SSH afin d'en sécuriser la connexion : ainsi les mots de passe VNC ne transitent pas en clair sur le réseau.

ssh $SSH_SERVER -L$LOCALPORT:$VNC_SERVER:$VNCPORT

Le cadriciel cygwin peut fournir un serveur SSH pour une machine équipée de Windows.

PLUME : historique du projet et de la plate-forme 05/2012 - 07/2013

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 01/10/12
  • Correction mineure : 04/11/13
Mots-clés

PLUME : historique du projet et de la plate-forme 05/2012 - 07/2013

Ce document liste les principales étapes et réalisations du projet et de la plate-forme PLUME, par ordre chronologique, entre mai 2012 et juillet 2013.

Les étapes précédentes, dès la création en 2006 jusqu'au départ de Jean-Luc Archimbaud, responsable de PLUME, en mai 2012 se trouvent dans ce document : PLUME : historique du projet et de la plate-forme 07/2006 - 04/2012.

Les étapes suivantes (depuis août 2013 et l'évolution du comité de direction) sont listées dans ce document : PLUME : historique du projet et de la plate-forme depuis août 2013.

2012

2013

Free/Open Access - L’accès libre à la science et le LIGM. Présentation du 6 mars 2012

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 25/03/12
  • Correction mineure : 13/11/13
Mots-clés

Free/Open Access - L’accès libre à la science et le LIGM. Présentation du 6 mars 2012

Cette présentation a été realisée dans le cadre de la journée logiciels du Laboratoire d'informatique Gaspard-Monge (Université de Marne-la-vallée) et a pour but d'analyser les questions du libre accès sur la production scientifique du laboratoire.

La production du laboratoire consiste principalement en articles (et autres publications scientifiques) et logiciels, mais il y a aussi les ressources linguistiques produites par l'équipe d'Informatique linguistique, et une autre production plus recente sur "l'Internet of things", travail en cours de I. Salhi.

La première partie de la présentation, dédiée aux logiciels, analyse les deux définitions sur le libre accès aux logiciels : celle du logiciel libre donnée par la FSF et celle du logiciel open source donnée par l'OSI et montre des différences entre les objets définis. Cette section continue avec les données sur les logiciels LIGM présentés sur PLUME.

La deuxième partie, dédiée aux articles, étudie les diverses définitions sur l'open access qui apparaissent dans le domaine des publications scientifiques. Certaines de ces définitions ont été étudiées lors de la matinée sur l'Open access gold - Un enjeu majeur pour les publications en physique. Certaines définitions apparaissent lors des déclarations, par exemple la Déclaration de Berlin ou la Déclaration de Budapest.

Cette deuxième partie analyse aussi la situation du libre accès et de l'édition scientifique au CNRS, en particulier la situation paradoxale dans la production d'articles, leur édition, l'achat des revues où ces articles sont publiées, et l'évaluation de l'activité des chercheurs. Cette situation est assez similaire dans les autres organismes de recherche en France, et pour approfondir sur ces thèmes nous invitons en particulier à la lecture de ces documents :

En conclusion on peut affirmer que l'édition scientifique est dans une situation très bouleversée actuellement, et son fonctionnement est en (r)évolution. La politique de diffusion, avec des licences Creative Commons (CC-by-nd), de la revue Logical Methods in Computer Science est étudié.

Nous attirons aussi l'attention du lecteur sur l'utilisation du terme open access dans le domaine des publications scientifiques : traduit souvent en français par libre accès, il peut y avoir des significations très distinctes, comme celle d'une licence CC-BY, celle donnée par la déclaration de Budapest ou celle qui indique un accès gratuit pour le lecteur d'un article, mais qui a été publié de façon payante pour son auteur. Il est donc important de clarifier le contexte avec la définition utilisée et les licences impliquées, c'est-à-dire, sur le modèle de la diffusion de logiciels.

Autres références utiles :

Et sur les politiques des revues scientifiques :

Fichier attachéTaille
2012_6mars_journeelogisligm_tgd.pdf493.01 Ko

Fourches (forks) d'un logiciel libre (définition, propriété, conseils...)

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 14/02/12
  • Correction mineure : 10/12/12
Mots-clés

Fourches (forks) d'un logiciel libre (définition, propriété, conseils...)

  • http://aful.org/ressources/fourches-forks
  • Type de ressource : article, résumé
  • Date de publication du document ou de l'événement : 5 mai 2011
  • Auteur(s) ou responsable(s) : Parmi les contributeurs : Laurent Séguin, Marc-Aurèle Darche, Nouha Bouayad, Gilles Polart-Donat, Florent Jouatte, Anne Tramut, Pierre Jarillon, Laurent Godard, Véronique Fritière, Julia Jumeau, François Desbois. Illustrations de Michel Cadiou et de Véronique Fritière.
  • Contact pour plus d'informations : http://aful.org/association/contact

Après la définition de fourche (ou embranchement ou fork en anglais) : programme développé à partir des sources d'un autre (voir aussi la page Wikipédia sur les forks), ce document AFUL classe les différents types de fourches comme suit :

  • la continuation d'un logiciel abandonné,
  • une évolution d'un programme dans une direction différente,
  • une libération d'un programme sous licence propriétaire,
  • une propriétarisation d'un logiciel libre,
  • une divergence dans la gouvernance du projet.

Chaque point dans ce classement est suivi d'un exemple représentatif. De plus, des exemples de fourches majeures sont analysés : MySQL, OpenOffice.org et Mandriva.

Une fourche "technique" peut entraîner une fourche "de communauté", ce qui peut affaiblir le projet initial, mais aussi attirer des nouveaux collaborateurs.

Ce document contient aussi des exemples de plateformes en ligne de gestion de sources, traite la question du financement et donne des conseils aux utilisateurs.

Mon intérêt porte en particulier sur le point de la propriétarisation d'un logiciel libre, ce qui est possible si on a les droits patrimoniaux d'un logiciel ou une licence libre qui le permet, c'est le cas de l'exemple donné sur ce type de fourche : Cedega. Selon la page Wikipédia sur Cedega, il s'agit d'une version propriétaire du logiciel Wine, initialement distribué sous une licence MIT et qui, suite à ce fourchage, a changé sa politique de licence vers une licence LGPL. Dans ce cas, c'est la licence initiale de type BSD ou sans copyleft de Wine qui a permit la propriétarisation.

Similairement, la libération d'un code existant est possible si on en a les droits d'explotation. Dans l'exemple donné de Blender, l'achat du code source est une première dans l'histoire du logiciel libre (voir par exemple http://www.logiciellibre.net/2003/news20031210.php).

Un autre exemple est celui de Open-Sankoré, libération du logiciel Uniboard, c'est l'État français qui a acquis les droits d'Uniboard et l'a rendu Open source et gratuit.

Une autre possibilité pour la propriétarisation ou la libération d'un logiciel est sa réécriture complète, mais cela doit éviter les problèmes de plagiat.

Observatoire des pratiques géomatiques

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 03/01/12
  • Correction mineure : 03/09/12
Mots-clés

Observatoire des pratiques géomatiques

L’Observatoire des Pratiques Géomatiques de l’Institut Français de l'Education (ENS Lyon) a été fondé en 2005 pour permettre de faire avancer la réflexion sur les usages et les enjeux des outils géomatiques dans l’enseignement secondaire. La géomatique regroupe l'ensemble des outils et méthodes permettant de représenter, d'analyser et d'intégrer des données géographiques. Le traitement de ces données géographiques est souvent effectué par des logiciels spécialisés appelés les Systèmes d'Information Géographique (SIG) qui sont à la fois les outils et les systèmes de gestion et de décision principaux du développement de cette discipline.

Néanmoins, à l'heure où les systèmes de cartographie en ligne prennent une place de plus en plus importante sur Internet, les pratiques se démocratisent via des applications en ligne où chaque internaute peut produire des cartes personnalisées. Dans ce contexte, la géomatique revêt à la fois des contenus pratiques et des usages à finalité double : l'utilisation de ces outils par les enseignants pour transmettre et faire réfléchir les élèves aux contenus disciplinaires (depuis le primaire jusqu'à l'université), proposer aux élèves une véritable éducation aux problématiques citoyennes de la géomatique (néogéographie, simulations, aide à la décision...)

L'observatoire a pour vocation de confronter les regards pluridisciplinaires sur des pratiques géomatiques éducatives afin de créer une communauté d’usagers diversifiée autour de ces différents usages. Il s'y emploie notamment par le croisement des approches et des regards, proposant une réflexion double, à la fois sur les enjeux pédagogiques et fonctionnels géomatiques, tout en développant des axes de recherche et d'innovation propres fondés sur ces réflexions.

XML (eXtensible Markup Language) : langage de balisage extensible

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 28/11/11
  • Correction mineure : 12/06/13
Mots-clés

XML (eXtensible Markup Language) : langage de balisage extensible

Cette fiche ressource à été relue par Maud Ingarao (ENS Lyon, CNRS) et par Florence Petit (IGM).

Introduction

XML est un langage informatique de balisage (enrichissement d'information textuelle).

A noter que le contenu de cette fiche PLUME ne constitue qu'un aperçu global d'XML et des standards associés, et non une formation exhaustive sur ces différents sujets.

Origine

Issu d'une simplification de la norme SGML (Standard Generalized Markup Language), XML (eXtensible Markup Language) est le fruit de travaux communs du World Wide Web Consortium (W3C) et de plusieurs industriels, entre 1996 et 1998.

Vue d'ensemble

Les principes de base d'XML sont donc ceux du SGML :

  • Séparation de la présentation et des données
  • Structuration des données
  • Capacité à valider la structure des données

Ces principes simples et souples donnent à XML la capacité à rendre le partage d'information ouvert, ce qui favorise les échanges informatisés basés sur des formats portables ainsi que l’interopérabilité des applications.

Schéma

Cela peut s'illustrer ainsi :
XML, principes

Structuration et organisation du contenu XML

Principe

XML est un langage de balisage générique qui permet de définir des documents contenant à la fois les données et des indications sur la structure de ces données. Ces balises ne sont pas prédéfinies, d'où la nature extensible du langage. Il convient de respecter des règles de construction syntaxique d'XML : on parle alors d'un document bien formé

Exemple

Un exemple de document XML est le suivant :

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="application/xml" href="personnes.xsl"?>
<personnes>
<personne naissance="1802" mort="1870">
   <nom>
    <prenom>Alexandre</prenom>
    <nom_famille>Dumas</nom_famille>
  </nom>
  <!-- l'abbé Faria a existé -->
  <profession>Ecrivain</profession>
  <informations xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.dumaspere.com"/>
</personne>
<personne naissance="1840" mort="1902">
  <nom>
   <prenom>Emile</prenom>
   <nom_famille>Zola</nom_famille>
  </nom>
  <profession>Ecrivain</profession>
</personne>
</personnes>

Ce document XML correspond à l'arbre ci dessous :
XML, exemple de document, vue hierarchique

Validation du contenu XML

Principe

Un document XML contient des données, organisées selon les règles de construction d'XML : c'est la notion de document bien formé déjà mentionnée.

Une grammaire donnée permet de définir des contraintes supplémentaires sur la structure d'un document XML. La définition d'une grammaire donnée se fait via des DTD ou via des schémas XML (extension : .xsd). Les schémas sont à ce jour les plus utilisés, car par rapport aux DTD, ils présentent en effet l'avantage d'être eux-même des documents XML. La syntaxe simplifiée Relax NG est également très utilisée.

Un document valide est un document qui respecte la grammaire définie dans une DTD ou un schéma XML.

Exemple

Soit le document XML suivant :

<?xml version="1.0" encoding="ISO-8859-1"?>
<personnes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="personnes.xsd">
  <personne>Alexandre Dumas</personne>
  <personne>Emile Zola</personne>
</personnes>

Le contenu de ce document XML peut être validé via le schéma XML suivant :

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Definitions types de donnees -->
  <xsd:simpleType name="personneType">
   <xsd:restriction base="xsd:string"/>
  </xsd:simpleType>
  <xsd:complexType name="personnesType">
   <xsd:sequence>
    <xsd:element name="personne" type="personneType" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="personnes" type="personnesType"/>
</xsd:schema>

Sur la différence entre document bien formé et document valide, voir par exemple ce récapitulatif sur le site W3schools.

Transformations de contenu XML

Principe

Comme expliqué ci-avant, un document XML contient les données et leur sémantique et ce contenu peut être validé par rapport à une grammaire donnée via des schémas XML (ou une DTD). Pour la présentation et/ou la transformation de contenu en XML, il est possible de passer par :

  • des CSS (Cascading StyleSheets),
  • des feuilles XSL (eXtensible Stylesheet Language), avec principalement XSLT (XSL Transformations) et XSL-FO (XSL-Formatting Objects).

Par ailleurs, le langage de requête XPath est souvent utilisé dans ce contexte de transformations de données car il permet de sélectionner des fragments de contenu XML.

Exemple

On considère le document XML ci-dessous :

<?xml version="1.0"?>
<salutation>
  Bonjour le monde !
</salutation>

La transformation de ce document en une page HTML peut se faire via le code XSLT suivant :

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/">
  <xsl:apply-templates select="salutation"/>
</xsl:template>
<xsl:template match="salutation">
  <html>
   <body>
    <h1>
     <xsl:value-of select="."/>
    </h1>
   </body>
  </html>
</xsl:template>
</xsl:stylesheet>

Le résultat de la transformation donne :

<html>
<body>
  <h1>Bonjour le monde !</h1>
</body>
</html>

Liaisons de contenu en XML

Principe

Étant donné la structure logique en arbre d’XML, la description de relations autres que parent-enfant(s) entre nœuds n’est pas naturelle. La réponse à cette problématique de liaisons de contenu XML passe par :

  • XLink, qui permet de décrire des graphes dans lesquels les sommets sont des documents (situés à des URI particuliers) et les arêtes sont les liens entre ces documents,
  • XPointer, langage dédié à l’identification de fragments de documents XML, souvent utilisé en liaison avec XLink.

Exemple

Soient trois fichiers zola1.txt, zola2.txt et zola3.txt pour lesquels un lien multidirectionnel de type arc doit être construit, pour avoir :
zola1.txt <--> zola2.txt <--> zola3.txt

Via XLink, cela peut s'exprimer de la sorte :

<series xlink:type="extended" xmlns:xlink="http://www.w3.org/1999/xlink">
<auteur>E. Zola</auteur>
  <roman xlink:type="locator" xlink:label="ez1" xlink:href="ftp://archive.org/zola1.txt">
   <titre>La curée</titre>
  </roman>
  <roman xlink:type="locator" xlink:label="ez2" xlink:href="ftp://archive.org/zola2.txt">
   <titre>La fortune des Rougon</titre>
  </roman>
  <roman xlink:type="locator" xlink:label="ez3" xlink:href="ftp://archive.org/zola3.txt">
   <titre>L'assommoir</titre>
  </roman>
  <!-- arcs -->
  <suivant xlink:type="arc" xlink:from="ez1" xlink:to="ez2"/>
  <suivant xlink:type="arc" xlink:from="ez2" xlink:to="ez3"/>
  <precedent xlink:type="arc" xlink:from="ez2" xlink:to="ez1"/>
  <precedent xlink:type="arc" xlink:from="ez3" xlink:to="ez2"/>
</series>

Manipulations de contenu XML

Principe

La manière de manipuler des documents XML depuis des programmes (lecture, écriture, modification) s’implémente principalement de deux façons différentes :

  • SAX (Simple API for XML), API qui aborde la notion de parsing de manière événementielle,
  • DOM (Document Object Model), API qui traite un document XML avec une approche arborescente.

Exemple

Soit l’extrait de document XML suivant :

<nom>
<prenom>David</prenom>
<nom_famille>Rousse</nom_famille>
</nom>

Un parseur SAX reportera typiquement les événements suivants (dans l’ordre indiqué)

startElement : nom
startElement : prenom
content : David
endElement : prenom
startElement : nom_famille
content : Rousse
endElement : nom_famille
endElement : nom

Un parseur DOM va, lui, représenter la totalité du document XML en mémoire sous la forme d'un arbre, en respectant la recommandation Document Object Model du W3C.

A noter : le parsage DOM est un exemple de "XML data binding", qui signifie le fait de représenter les éléments d'un document XML en tant qu'objets en mémoire. Cf. l'article [en] XML data binding sur Wikipedia.

Conclusion

En guise de conclusion, les différents éléments précités autour de XML s'illustrent de la sorte :
XML, champs d'applications

Références

Le support de cours suivant traite de manière plus approfondie d'XML et des normes et standards liés.

PLUME : historique du projet et de la plate-forme 07/2006 - 04/2012

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 15/04/12
  • Correction mineure : 10/07/13
Mots-clés

PLUME : historique du projet et de la plate-forme 07/2006 - 04/2012

Ce document liste les principales étapes et réalisations du projet et de la plate-forme PLUME, par ordre chronologique.

Dans les phases suivantes, de 2006 à 2010, PLUME est un projet de l'UREC, Unité Réseaux du CNRS. Ensuite le projet est piloté par le pôle ARESU, Architecture Réseaux, Expertises, Support aux Unités, de la DSI, Direction des Systèmes d'Information, du CNRS.

2006

L'UREC a plusieurs missions dont une d'animer la communauté des informaticiens dans les laboratoires du CNRS (et de mutualiser leurs compétences) et une autre de monter des projets répondant et parfois anticipant les besoins nouveaux des laboratoires en terme d'informatique proche de la science. Dans ce contexte une réflexion démarre au sujet des logiciels utilisés ou développés dans les laboratoires.

  • Premiers constats et questionnement de Jean-Luc Archimbaud (UREC)

    • Les informaticiens dans les laboratoires et les universités utilisent et développent des logiciels souvent libres mais ré-inventent la roue, ne sachant pas ce qu'utilisent ou développent leurs collègues dans les mêmes environnements : perte énorme de temps et d'efficacité.
    • Il y a beaucoup de compétences pointues sur des logiciels variés dans la communauté Enseignement Supérieur - Recherche (ESR).
    • Les logiciels libres présentent maintenant des produits stables. C'est une solution bien adaptée à la communauté ESR, à la fois pour l'utilisation et pour le développement.

    --> Comment mutualiser ces compétences sur les logiciels (en particulier libres) ?

  • Etude de l'existant
    • Y-a-t-il déjà des listes de logiciels libres utilisés ? : beaucoup de listes mais très restreintes, à l'initiative d'une personne très motivée la première année mais qui ensuite, moins motivée, n'assure pas un suivi. Sauf un serveur national framasoft très intéressant mais avec une cible tout public, donc beaucoup de logiciels sans intérêt pour l'ESR et sans mise à jour des informations (les descriptions n'évoluent pas).
    • Y-a-il des projets de référencement de logiciels ? Quelques uns mais pas pour l'ESR.
    • Combien d'informaticiens y-a-t-il dans la communauté ESR : environ 10 000 ingénieurs ou techniciens, sans compter les chercheurs et les enseignants : donc beaucoup.

    ---> Idée de créer un référentiel de logiciels utilisés dans l'ESR, principalement libres, avec les mises à jour nécessaires.

  • En juillet 2006, une amorce de projet est élaborée dans le document Projet national pour faciliter et promouvoir l’utilisation des logiciels libres dans la communauté enseignement supérieur et recherche, document diffusé pour recueillir des avis de la communauté ESR et amorcer des contacts.
  • Geneviève Romier (UREC) se joint à Jean-Luc Archimbaud (les deux pour une partie de leur activité UREC dans ce projet), rapidement appelé PLUME : Promouvoir les Logiciels Utiles Maitrisés et Economiques dans l'enseignement supérieur et la recherche. C'est une première chance du projet d'avoir un acronyme représentatif de l'objet, sympathique et mnémonique.
  • Décision de monter une plate-forme de test pour publier des descriptions de logiciels utilisés dans l'ESR, sans matériel ni développement particulier, en utilisant le serveur Web existant de l'UREC (sous le CMS  SPIP), des échanges 'manuels' de mails avec les contributeurs et la publication des fiches descriptives en PDF avec un début de classification et un premier modèle de fiche. Les premières fiches sous cette forme sont publiées en septembre 2006. Ceci dans le but de :
    • Valider la faisabilité de créer un référentiel (trouver des contributeurs...) et son début d'utilité (est-ce intéressant ?)
    • Définir la structure des fiches, les processus de réalisation, l'organisation et les outils techniques nécessaires
  • Sylvain Corcoral, ingénieur dans le laboratoire LSEET, rejoint pour une partie de son temps, le projet en temps que rédacteur de fiches, puis sur la définition du projet et la mise en place des outils futurs.
  • Fin 2006, il y a 5 fiches en ligne sur le serveur de test PLUME (serveur Web de l'UREC) : OpenOffice.org, Autoruns, PDFCreator, modXLDAPAuth et Ad-Aware rédigées par 4 contributeurs : Geneviève Romier, Gael Beauquin, Sylvain Corcoral, Alice de Bignicourt.

2007

Le projet prend forme : une présentation de PLUME faite au CCIN2P3 le 17 janv 2007 avec une video et les transparents associés en donne le descriptif. En résumé :

  • Deux objectifs principaux : référencer les logiciels utilisés dans la communauté ESR (mutualisation des compétences) et les logiciels développés dans cette communauté (promotion, valorisation) sous forme de fiches descriptives indexées avec des mots clés
  • Cible : la communauté ESR et en particulier les informaticiens ou utilisateurs éclairés de l'informatique
  • Rédacteurs de fiches : utilisateurs ou développeurs des logiciels
  • Organisation avec plusieurs rôles : contributeurs, relecteurs, responsables de thèmes... Un thème peut être un métier, un domaine scientifique, une activité transverse, un domaine informatique. Les responsables thématiques sont des personnes qui travaillent dans un laboratoire ou une université, qui connaissent bien les logiciels d'un thème et qui acceptent de participer à PLUME comme référent pour ce thème. Ils ont pour mission principale de suivre et de coordonner la publication d'un certain nombre de fiches.
  • Des entités (laboratoires...) qui soutiennent et qui sont partenaires de PLUME

La plate-forme de test

La plate-forme définitive

La suite du projet

Une plateforme de formation à distance (à partir de juillet)

Dans le cadre d'un projet de fin d'étude , la mise en place d'une plate-forme de formation à distance (pour les logiciels libres) basée sur le LMS Moodle est réalisée par Anne Durand (MAP), Marie Leproust (UVSQ/TICE) et Hélène Vanderstichel (Mission locale Villeneuve d'Ascq). Cela donnera le projet connexe @2L (Apprentissage des Logiciel Libres).

2008

  • Janv-Mars : dans le cadre du projet @2L, développement d'une offre complète de formation à distance au CMS SPIP. Plusieurs sessions de formation seront organisées en 2008 et 2009.
  • Mars : intégration de Anne Durand (MAP) à 50 % de son temps dans le noyau dur PLUME en particulier pour le projet @2L et pour l'ergonomie de la plate-forme. Ces 50 % seront effectifs jusqu'en septembre 2009.
  • Avril-mai : avec le réseau métier RESINFO, appel à projets DEVA (DEVeloppements Administrateurs systèmes et réseaux de laboratoires de recherche), sélection et soutien de 4 projets.
  • Mai : sur la plate-forme, mise en place des pages thématiques
  • Juillet : sur la plate-forme : création des premières fiches ressources. Ces fiches présentent synthétiquement des ressources liées aux logiciels :
    • articles (comparatif, compte-rendu d'expérience par exemple)
    • supports de cours, transparents d'une présentation, évènements (conférence, journée thématique, ...)
    • services (hébergement de listes de diffusion, pont de visioconférences...)
    • sites web...
  • Août : sur la plate-forme : création des premières fiches de logiciels à valider (logiciels dans un état abouti, utilisés en production sur un site mais qui, à notre connaissance, ne sont pas utilisés sur d'autres sites) et de logiciels en test (pas en production mais en cours de test sur un site).
  • Septembre : sur la plate-forme : création des premières fiches Développement ESR (Développements Enseignement Supérieur - Recherche) fiches qui décrivent les logiciels développés ou en développement dans la communauté ESR quelque soit leur état, des fiches archivées (fiches qui ne sont plus mises à jour) et de l'agenda (pour annoncer les événements autour des logiciels, en particulier libres)
  • Octobre : première école thématique ENVOL_2008 (Formation pour le dEveloppemeNt et la ValOrisation des Logiciels en environnement de recherche)

  • Octobre : recrutement de Antony Burton en CDD UREC qui travaillera jusqu'en avril 2009 sur la mise en place du portail anglophone.

Fin 2008, 314 fiches sont publiées sur la plate-forme avec 18 responsables thématiques (cf tableau de bord). Les nouveaux responsables thématiques (2008) sont : Emmanuel Courcelle (LIPM) pour le thème biologie, Emile Geahchan (CNAM) pour le thème sécurité, Teresa Gomez-Diaz (LIGM) pour le thème patrimoine logiciel d'un laboratoireRaphael Tournoy (ISH) et Maud Ingarao (Institut d'Histoire de la Pensée Classique) pour le thème SHS, Pascal Dayre (IRIT) et Frederic Camps (LAAS) pour le thème développeur.

2009

Durant l'année 2009 PLUME a été présenté dans de nombreuses conférences : cf fiche ressource 'Participation de PLUME dans des journées (2009-2011)'

Fin 2009, 529 fiches sont publiées sur la plate-forme (+90 % par rapport à 2008), par 438 contributeurs avec 22 responsables thématiques (cf tableau de bord). Les nouveaux responsables thématiques (2009) sont : Christelle Dantec (IGF) pour le thème biologie, Anne Facq (CRPP) pour le thème chimie, Sylvain Faure et Loïc Gouarin (Labo Maths Orsay) pour le thème maths, Laurent Perrochon (INRA Phase) pour le thème agronomie, François Morris pour le thème sécurité.

2010

Durant l'année 2010 PLUME a été présenté dans de nombreuses conférences : cf fiche ressource 'Participation de PLUME dans des journées (2009-2011)'

Fin 2010, 844 fiches sont publiées sur la plate-forme, par 650 contributeurs avec 26 responsables thématiques (cf tableau de bord).
En 2010, parmi les responsables thématiques, Sylvain Corcoral a quitté PLUME et sont arrivés : Jean-Michel Glorian (CESR) pour le thème développeur, Jérôme Kieffer (ESRF) pour le thème chimie et Maurice Libes pour le thème Administrateur Systèmes et Réseaux.

2011

Fin 2011, 1019 fiches sont publiées sur la plate-forme, par 762 contributeurs avec 20 responsables thématiques (cf tableau de bord).

Durant l'année 2011 PLUME a été présenté dans de nombreuses conférences : cf fiche ressource 'Participation de PLUME dans des journées (2009-2011)'.

En 2011, parmi les responsables thématiques, Violaine Louvet, Loïc Gouarin et Sylvain Faure pour le thème Maths, Jean-Michel Glorian pour le  théme développeur et  Jacquelin Charbonnel pour le thème Administrateurs Systèmes et Réseaux ont quitté l'équipe PLUME. Sont arrivés : Dirk Hoffman pour le thème physique et Hervé Parmentier pour le thème géographie. Geneviève Romier a mis fin à différentes activités dans l'équipe PLUME mais devient responsable thématique Grilles et sont arrivés Gilian Gambini et David Rousse de la DSI du CNRS.

2012

Syndiquer le contenu