Voici l’automne, saison où les feuilles tombent mais les conférences et les réunions en tous genres fleurissent.  Cette réunion développeurs a donc principalement eu pour but de centraliser les retours des réunions où ses différents membres s’étaient rendus.

GENCI

Contexte

David s’est rendu à la réunion du GENCI (Grand Équipement National de Calcul Intensif), organisme dont le principal rôle est de centraliser la direction des ressources de calcul intensif pour la recherche publique en France. On peut le voir comme l’antenne française de l’organisation européenne PRACE (PaRtnership for Advanced Computing in Europe).

La réunion se déroulait au grand amphithéâtre du CNRS Michel-Ange.  L’ambiance était bonne, avec beaucoup de tables rondes. Bien que le public d’une réunion GENCI soit à la base plutôt décisionnaire, des utilisateurs étaient présents pour expliquer leurs besoins, et étaient écoutés.

Moyens et évolution de GENCI

Les ressources de calcul de GENCI sont majoritairement concentrées dans 3 grands centres nationaux, chacun ayant une certaine « couleur » administrative bien qu’étant utilisé par tous les acteurs académiques:

• Le CINES (Centre Informatique National de l’Enseignement Supérieur), à Montpellier, est plutôt porté par les universités.
• L’IDRIS (Institut du Développement et des Ressources en Informatique Scientifique), en haut du campus de Paris-Sud, est plutôt porté par le CNRS.
• Le TGCC (Très Grand Centre de calcul du CEA), à Bruyères-le-Châtel, est plutôt porté par le CEA.

Depuis quelques années, GENCI tente également d’intégrer davantage à sa stratégie des centres de calcul régionaux de plus petites tailles, dits « mésocentres », comme par exemple le centre de calcul ROMEO de Champagne-Ardenne. Ils utilisent pour cela une organisation hiérarchique avec une terminologie à base de « Tiers », similaire à celle du monde des grilles.

Une autre évolution est que GENCI tentent de s’adapter davantage aux utilisateurs ayant des besoins en stockage de long terme. Ce n’est historiquement pas une spécialité des supercalculateurs, normalement on crée des comptes utilisateurs le temps d’un projet de court terme, on le détruit à la fin, et toutes les données sont alors jetées. Mais ce changement de stratégie est nécessaire pour intégrer la problématique « big data », ce que le GENCI essaie de faire sous la terminologie de HPDA (High Performance Data Analytics).

Le calcul intensif et les grilles

Historiquement, les communautés du calcul intensif et des grilles de calcul ont régulièrement été en compétition. Une partie de la raison est que leurs besoins et leur organisation sont assez différents, même si ils tendent à se rapprocher depuis quelques années.

Voici quelques points de comparaison entre les deux approches (désolé pour le piètre rendu visuel, j’ai fait ce que j’ai pu côté HTML mais le CSS du blog développeurs semble avoir sa propre idée très précise de l’apparence qu’une table devrait avoir):

Séminaire Verrou

Dans le cadre des séminaires « Demandez le programme » de l’INRIA Saclay, François Févotte, ingénieur de recherche chez EDF, a présenté l’outil Verrou. Cet outil permet d’étudier la stabilité numérique des codes de calcul scientifiques, c’est à dire la sensibilité de leurs résultats aux fluctuations des données d’entrée ou de sortie.

Une telle analyse a plusieurs intérêts:

• Elle permet d’évaluer à quel point le résultat d’un calcul est significatif, et de comprendre et améliorer sa précision.
• Elle peut révéler des bugs ou des problèmes de performance liés à une mauvaise utilisation des nombres à virgule flottante (ex: critère de convergence en-dessous de la précision du calcul)
• Elle peut aussi être utilisée pour guider l’évolution d’un code de calcul vers une précision réduite ou hybride afin d’augmenter ses performances. Souvent, un scientifique utilise en effet la double précision par défaut, par sécurité face à son inexpérience.

La méthode mathématique généralement utilisée pour de telles études de stabilité, appelé CESTAC, consiste à introduire des erreurs d’arrondi aléatoires dans les calculs (correspondant à un bruit sur le dernier bit du nombre calculé) et à évaluer l’impact de ces erreurs sur le résultat du calcul.

Il y a plusieurs manières d’introduire de telles erreurs. La méthode historique, utilisée par l’outil CADNA, est malheureusement très intrusive: on doit remplacer tous les nombres flottants dans le code par un type de données spécialisé. C’est en pratique très laborieux, surtout sur des programmes ayant des dépendances nombreuses. Verrou résout ce problème en utilisant l’émulateur Valgrind pour instrumenter à la volée un binaire non modifié. C’est un gain de temps énorme, pour un prix à payer finalement assez faible:

• Moindre portabilité entre systèmes (Linux x86 seulement)
• Localisation plus grossière des problèmes (le compilateur a éliminé une partie de l’information sur la position des calculs)

L’outil est open-source, EDF l’a mis sur Github. François Touze a mentionné qu’il pourrait intéresser aussi la communauté de la chromodynamique quantique (QCD), qui manipule souvent des matrices presque non inversibles où la moindre erreur dans l’algorithme de calcul peut être fatale pour la qualité du résultat.

ICALEPS et sécurité info

Philippe était à ICALEPS, à Barcelone. C’est essentiellement une conférence de contrôle-commande centrée sur les deux frameworks ennemis TANGO et EPICS, mais cette année, on y trouvait aussi un workshop très intéressant sur la cyber-sécurité.

Un thème récurrent était les nouvelles menaces liées aux nouvelles pratiques de gestion des données des entreprises, où on tend de plus en plus à remplir des disques dur par défaut sans réfléchir aux conséquences légales et techniques de cette accumulation.

En passant, un mot sur l’attaque KRACK. Pour résumer, une faille de sécurité a été trouvée dans le protocole cryptographique d’échange de clé du système de chiffrement WPA2 des réseaux Wi-Fi. La conséquence est qu’un utilisateur ne disposant pas du mot de passe peut lire et écrire le trafic réseau chiffré comme si il avait rejoint le réseau normalement. La faille se situant au niveau du protocole WPA lui-même, toutes les implémentations actuelles sont vulnérables, et le problème ne sera pas facilement soluble par un simple patch. Il faut donc dorénavant considérer que les réseaux WPA2 sont aussi sûrs (confidentiels et intègres) que des réseaux publics non chiffrés pour un attaquant expérimenté. Il ne faut donc pas utiliser sur ces réseaux des protocoles réseau « en clair » ne fournissant pas leur propre mécanisme de chiffrement et d’authentification.

Une autre menace grandissante est celle des périphériques malveillants. A ce sujet, on peut facilement laisser son esprit être emporté par une fascination perverse pour l’élégance technologiques d’attaques sophistiquées, comme celles basées sur des logiciels malveillants ou sur le siphonnage du contenu de la RAM d’un ordinateur par un périphérique (auxquels les Macs ont été sujets avec le Firewire, puis à nouveau avec le Thunderbolt, prouvant que les fabricants de matériel ne savent pas tirer les leçons de l’histoire en termes de sécurité). Mais il faut aussi garder les pieds sur terre et se rappeler que le danger peut aussi provenir d’attaques beaucoup plus « bas niveau ». Ainsi, les sinistres « USB killers » ne sont autres que des batteries de condensateurs qui, à la manière d’un flash d’appareil photo, se chargent avec la petite alimentation 5V d’un port USB pour finalement frire la carte mère de l’ordinateur victime avec une impulsion de plusieurs centaines de volts. Quand on en arrive à ce niveau de bassesse, on en finit par se dire que tout accès physique aux ports d’une machine est une vulnérabilité en soi.

Se pose alors la question la plus importante: quelle alternative pratique et efficace aux clés USB peut-on fournir aux utilisateurs d’installations partagées comme les synchrotrons pour transférer leurs données scientifiques d’un ordinateur à un autre?

Une autre faille courante, au niveau utilisateur, c’est la réutilisation de mots de passe. Pour rappel, le problème avec cette pratique, c’est qu’elle augmente la quantité de dégâts provoqués par une brèche de sécurité. Ainsi, quand la base de données de mots de passe d’un site web fuite, tous les autres sites web pour lesquels on utilise le même mot de passe sont potentiellement aussi vulnérables. Un outil pratique quand on arrive après la bataille est le site « Have I been pwned », qui permet de savoir si un site populaire où l’on possède un compte a fuité des mots de passe récemment. Un autre outil plus ambivalent est le gestionnaire de mots de passe. Ce dernier facilite grandement la tâche d’avoir un mot de passe différent pour chaque service auquel on se connecte, par contre lorsqu’une faille de sécurité est trouvée dans le gestionnaire de mots de passe lui-même, les conséquences sont potentiellement dramatiques.

Comme sources d’informations sur la sécurité informatique, on peut mentionner pour les plus braves les listes de diffusion CERT, qui recensent les failles de sécurité découvertes dans des logiciels couramment utilisés. Mais leur débit conséquent et leur contenu très technique en découragera plus d’un. Comme alternative un peu plus agréable à lire et vulgarisée, le blog Naked Security de l’entreprise Sophos est une source très sympathique. Au niveau formation, on peut mentionner de nouveau que l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) a ouvert cette année un MOOC sur la sécurité de l’information appelé SecNum académie.

Autres sujets en vrac

Nous aurions bien aimé avoir aussi des retours de XLDB et SUCCES, mais malheureusement, aucun des développeurs qui s’y étaient rendus n’était présents ce jour là.

Philippe voulait savoir si des gens dans le service souhaitent encore jeter un oeil à l’abonnement en ligne à LinuxMag dont il nous avait parlé précédemment par mail, ou si ce n’est pas nécessaire de faire attendre l’éditeur plus longtemps et on peut déjà lui répondre.

L’école de programmation fonctionnelle et de Spark organisée par Christian n’est pas passée inaperçue. Ça a été l’occasion pour Hadrien de rappeler que ce style de programmation a d’autres applications que le calcul.  Ainsi, des langages comme Elm proposent un modèle fonctionnel pour la conception d’interfaces Web, tandis que du côté serveur l’API multi-langages ReactiveX fournit une approche très ergonomique et performante de la programmation par flux de données grâce à des mécanismes d’inspiration fonctionnelle.

Pour débuter avec ce modèle, le mieux est sans doute d’apprendre un langage pensé pour la programmation fonctionnelle à la base. On peut ainsi trouver des formations d’OCaml via l’INRIA et sur la plate-forme de MOOCs France Université Numérique, et des formations Scala sur la plate-forme de MOOCs Coursera.

Faut-il un ordre du jour?

La question de l’ordre du jour des réunions développeurs a été soulevée lors de la récente réunion sur le fonctionnement du service informatique. Le sujet laisse peu indifférent, certaines personnes trouvent la perspective motivante et d’autres la trouvent étouffante. Un compromis possible est de distribuer le temps de réunion entre discussion cadrée et parole libre.

L’une des questions que poserait l’introduction d’un ordre du jour, c’est le remplissage de ce dernier. On sait en effet que quand l’organisateur d’une réunion essaye de partir à la pêche aux idées, il y a peu d’écho du côté des participants. Une possibilité serait de récupérer les idées qui n’ont pas été complètement traitées lors d’une réunion pour la réunion suivante.

Pour satisfaire les personnes qui exprimaient, à la réunion sur le fonctionnement du service, une insatisfaction de ne pas savoir ce que font leurs collègues, il a été proposé de faire, au fil des réunions, un tour de table graduel des activités des développeurs, personne par personne. Le format serait très bref, 2-3 slides par exemple.

Il a été remarqué qu’au rythme d’un développeur par séance, comme il y a 12 semaines ouvrées par semestre et la réunion développeurs se produit une semaine sur deux, ce rite de présentations ne concernerait qu’environ 12 personnes par an, et prendrait donc plusieurs années à couvrir l’ensemble des développeurs. Cependant, l’alternative consistant à présenter plusieurs personnes par réunion a aussi été jugée nocive pour la discussion.

Une autre conséquence de ce délai très long est qu’il faudrait bien réfléchir à l’ordre dans lequel on fait passer les gens, par exemple en mettant les personnes qui vont bientôt quitter le LAL en premier. Pour ne pas intimider par une prise de parole forcée, il était proposé de fonctionner sur un mode de volontariat assisté, où Antoine et David partiraient entre deux réunions à la pêche à la bonne personne ou au bon sujet, et les personnes qui ne souhaiteraient pas présenter elles-mêmes leur activité pourraient déléguer la tâche à quelqu’un d’autre.

Formation et milieu universitaire

Développements dans Paris-Saclay

Fabien Cavalier a récemment envoyé un courrier sur les derniers développements en date de l’Université Paris-Saclay. Le premier point qui est clair, c’est que Polytechnique et la plupart des écoles en ont marre, à l’exception notable de l’ENS Cachan.

Par ailleurs, le nouveau document a le mérite d’exprimer plus honnêtement que la raison d’être de Paris-Saclay est l’optimisation du rang au classement de Shanghai.

Dans cette optique, la dernière fantaisie en date du projet est de séparer le plus gros de la formation de licence (le « CUPS ») des filières de Master et de recherche (MàJ du 28-09-2017: ce plan semble aujourd’hui en voie d’enterrement). La tendance est, dans ce cadre, vers un plus grand nombre de PRAGs et de PRCEs. Une autre tendance est de profiter du changement administratif pour essayer d’augmenter les frais d’inscriptions et modifier d’autres statuts.

Formations au développement logiciel

Il y a eu une courte discussion sur l’école 42 lancée par Xavier Niel (Iliad/Free). De l’expérience de développeurs qui ont rencontré leurs anciens élèves, ils tendent à être des hyper-spécialistes qui sont d’une efficacité impressionnante dans leur domaine d’expertise, mais n’ont même pas une vague culture générale des autres facettes de l’informatique. C’est un pari dangereux pour la carrière de quelqu’un.

Une autre particularité de cette école, c’est qu’elle n’exige aucun prérequis en entrée (ce qui n’est pas le cas de formations similaires comme Epita/Epitech), et offre une flexibilité très grande dans le plan de formation qui rend plus difficile la tâche d’évaluer le niveau de sortie des étudiants. Le système encourage assez fortement la spécialisation et l’évaluation des étudiants par leurs pairs.

Dans le périmètre Paris-Saclay, il y a…

• Une licence d’informatique généraliste, qui n’est pas particulièrement fléchée « code ».
• Un IUT qui offre une formation de programmation généraliste, impliquant notamment du C++, du Java et des technologies Web.
• Un DUT plus spécialisé dans la programmation web à Vélizy.
• Joël Falcou, gourou C++ local (anciennement LRI, maintenant plus focalisé sur l’entreprise Numscale), qui organise avec le groupe Calcul des séminaires de niveau avancé sur le C++ moderne.
• Un DUST (Diplôme Universitaire de Sciences et Technologies) que Gérard Marchal a suivi. On ne sait pas si ce diplôme existe encore.
• Polytech Paris-Sud a une filière info.
• Des écoles généralistes comme Centrale qui enseignent notamment de l’informatique.
• Le master de calcul de l’UVSQ, dont David et Hadrien ont plusieurs fois constaté que les étudiants sont fort brillants.

Des éloges ont également été formulés sur la formation de l’UTC (Université de Technologie de Compiègne).

Dénouement du stage de Lucas

Malheureusement, nous n’avons pas réussi à trouver un financement approprié pour la thèse que nous proposions pour Lucas Serrano, visant à permettre le développement de langages spécifiques pour la performance portable et durable en physique des particules.

Nous n’avons pas su remarquer les faiblesses du plan de financement proposé à la base (via les bourses ENS et Télécom Sud Paris), et n’avons pas non plus réussi à rattraper le coup via les financement de Paris Saclay. Le LAL était, quand à lui, prêt à financer la thèse en intégralité si besoin, mais nous avons préféré refuser cette proposition car il était très important pour le bon déroulement de cette thèse et pour la carrière de Lucas par la suite qu’un laboratoire d’informatique soit dans la boucle.

Pourquoi pas la Maison de la Simulation? Parce que cet organisme n’a pas vraiment de financement propre. Ils font financer leurs thèses par l’institut auquel appartiendra le doctorant. Ce qui aurait pu poser quelques problèmes politiques avec les physiciens…

Du côté de Télécom, les gens sont toujours intéressés, et une nouvelle proposition de projet commun est en préparation. Pas mal de développeurs LAL présents étaient aussi intéressés par le rapport de stage de Lucas.

Café LoOPS sur Meson

La veille de la réunion, le mardi 5 septembre, LoOPS a tenu son premier café de 2017-2018. Le sujet était Meson, un système de gestion de configuration et de compilation. Il y avait environ 23 personnes dans la salle.

Meson effectue un travail similaire à celui de CMake et des Autotools. Il se destine principalement à des projets écrits dans des langages compilés (C, C++, Fortran…). Sa fonction est de s’assurer que les dépendances de compilation d’un programme sont présentes sur le système hôte, gérer des différences plus ou moins subtiles entre les configurations système supportées (ex: Linux vs OSX, Clang vs GCC, x86 vs ARM…), et générer en sortie des fichiers de configuration pour IDE (XCode et Visual Studio) ou des scripts de compilation (actuellement au format Ninja) permettant d’orchestrer la compilation proprement dite.

Au niveau des utilisateurs, Meson a rencontré un grand succès dans la communauté GNOME (environnement graphique pour Linux), et il est en cours d’intégration dans d’autres grands projets open-source (Xorg, systemd, Wayland/Weston) en tant qu’option de build secondaire. Pour l’instant, il a surtout du succès comme remplacement des Autotools, mais a plus de difficulté à convaincre les utilisateurs de CMake, outil plus récent et plus proche de Meson au niveau des fonctionnalités.

Voici un résumé des principales différences par rapport à CMake:

• L’outil est beaucoup plus jeune, ce qui a ses avantages (évolution rapide, équipe joignable et à l’écoute) et ses inconvénients (certaines fonctions sont peu matures, comme le support des IDE)
• La gestion de dépendances utilise le standard pkg-config plutôt que des scripts ad-hocs de plusieurs milliers de lignes.
• Si une dépendance n’est pas présente, Meson peut en option aller automatiquement la chercher, la compiler et l’installer.
• Les scripts de configuration sont faits pour être faciles à écrire et lisibles par la suite. Ils sont donc écrits dans un langage déclaratif simple, haut niveau, et volontairement non Turing-complet, avec une syntaxe d’inspiration Python.
• La configuration par défaut est optimisée pour une bonne performance de compilation via l’usage de Ninja, de CCache, des en-têtes précompilés; ainsi que l’interdiction d’utiliser des « wildcards » comme *.cpp qui sont pratiques mais ne passent pas à l’échelle.
• Cette configuration par défaut suit aussi un certain nombre de bonnes pratiques comme l’activation des diagnostics de compilateurs (-Wall) et l’usage d’un dossier de compilation dédié.
• Le support des analyses dynamiques de programmes comme la mesure de couverture de code, les « sanitizers » des compilateurs, ou Valgrind est plus poussé que dans CMake, qui se restreint essentiellement au support des builds de debug et des tests unitaires.

Le langage de script mérite quelques mots de plus, car c’est un des points les plus contentieux de la conception de Meson. Voici les principales choses qu’on peut en dire:

• Il est, dans sa syntaxe, inspiré par Python avec quelques changements mineurs pour adapter aux scénarios de compilation (par exemple, on utilise pour le formatage de texte le caractère @ plutôt que les accolades {}, ce qui réduit la nécessité d’utiliser des séquences d’échappement).
• Bien que Meson soit actuellement implémenté en Python, l’équipe se réserve la possibilité de basculer vers un autre langage si des contraintes comme la performance l’exigent. L’équipe essaie donc de ne pas exposer l’implémentation Python dans l’interface, y compris au niveau des scripts de configuration.
• Pour cette raison, et pour éviter de se retrouver face à des monstres tentaculaires de configuration comme ça peut arriver avec les langages Turing-complet comme le Python de SCons et Waf ou le pseudo-script shell de CMake, Meson essaie de s’en tenir à un langage de configuration minimaliste, qui ne fournit que ce qui est strictement nécessaire. L’import de modules Python arbitraire ou la génération de code de configuration à la volée n’est donc actuellement pas à l’ordre du jour.

Dans un contexte LAL, un autre point de comparaison possible était CMT. Par rapport à ce dernier, Meson met moins l’accent sur la possibilité d’effectuer des requêtes sur la configuration de compilation, et sur son origine. Par exemple, on pouvait dans CMT savoir de quelle dépendance provenait un certain paramètre de compilation, ce qui semble plus difficile voire impossible avec Meson.

Une suite de ce café LoOPS sera probablement proposée sous la forme d’un atelier Meson d’un jour en présence d’un ou deux développeurs de l’outil.

Événements à venir

XLDB

L’édition 2017 de la conférence XLDB, qui discute de grandes bases de données avec un accent sur les problématiques de physique des particules et d’astrophysique, se déroulera à Clermont-Ferrand du 10 au 12 octobre.

Cette conférence se déroule habituellement à San Francisco, mais elle a été organisée en France cette année en reconnaissance des contributions du LPC à l’infrastructure de bases de données de LSST.

Les participants actuellement pressentis sont Grigory, Adrien, Antoine et Christian (ce dernier étant financé par LSST).

Séminaire d’architecture matérielle

Hadrien fera une première présentation d’un séminaire d’architecture matérielle le mercredi 13/09 à 10h30. Le contenu sera principalement orienté vers un public de développeurs, mais peut aussi intéresser une partie du groupe exploitation, car il y a une forte synergie sur certains sujets comme la mesure des performances.

Le principe est de présenter en quoi les ordinateurs modernes s’écartent du modèle de Von Neumann qui est souvent utilisé dans l’enseignement de la programmation, pour quelles raisons, et par là même de dévoiler quelques grands principes pour l’obtention de bonnes performances logicielles sur le matériel moderne.

Si ça a du succès, il y a des évolutions possibles, par exemple une diffusion vers un publique plus large (IPN, webinaire RI3, traduction anglaise pour une utilisation au CERN), ou une évolution vers un format plus « TP » présentant quelques exemples classiques de programmes inefficaces et invitant l’apprenant à les optimiser grâce aux connaissances acquises et à des outils de mesure de performance modernes.

École de programmation fonctionnelle et Apache Spark

Christian est en train de préparer une double formation de programmation fonctionnelle et de traitement de données distribué avec Apache Spark. Cette dernière sera, à terme, gérée comme Action Nationale de Formation (ANF) du CNRS, mais pour la première édition, nous tirerons parti d’un créneau de formation de DevLOG qui a dû être annulé.

La formation se composera de deux parties de trois jours, administrativement indépendantes mais pensées pour former un tout cohérent. La première partie présentera des concepts de programmation fonctionnelle en Python ou Scala (langages préférés pour l’interaction avec Spark), et la seconde partie présentera le traitement de données avec Spark à proprement parler.

La première session devrait se tenir au LAL en janvier 2018. L’intervenant de l’école Apache Spark, très apprécié, sera rappelé, avec un budget temps plus confortable (3 jours au lieu de 2).

MOOC ANSSI sur la sécurité informatique

Philippe rappelle que l’ANSSI a récemment lancé un MOOC sur la sécurité de l’information, appelé « SecNum académie », qui sera en libre accès jusqu’à Avril 2019.

Peut-être de quoi faire un peu de concurrence francophone à l’excellent Introduction to Cyber-Security de FutureLearn, qui est souvent un brin trop britannique dans ses discussions légales!

Organisation des réunions

Antoine a profité de cette réunion pour relancer la question de l’ordre du jour. Par choix, les réunions Dev@LAL n’en ont pas, ce qui a des avantages et des inconvénients.

Un inconvénient qui a été mentionné par le passé est que les gens qui ne viennent pas aux réunions n’ont pas un mot à dire sur le contenu, mais on peut légitimement se demander si ils devraient en avoir un. Un autre travers de la parole spontanée est qu’elle favorise l’expression des individus bavards et à l’aise socialement, ce qu’on pourrait éventuellement contrer en ajoutant des règles de prises de parole, mais au prix d’une perte des avantages de la spontanéité.

La question de la valorisation des compte-rendus a été soulevés. Ces derniers demandent pas mal de travail, et on pourrait avoir envie de les diffuser à un public plus large, à définir. Par exemple à tout le SI, voire au-delà. Antoine avertit cependant qu’une diffusion trop large pourrait amener les personnes à surveiller davantage leurs paroles, et donc à perdre en spontanéité.

Au sein du groupe de développement, certaines personnes sont intimidées par le volume de texte. Pour cette raison, nous souhaiterions un format résumé, ce qui sort de la zone de confort d’Hadrien. Après quelques discussions, la parade a été trouvée: une extension WordPress peut générer automatiquement une table des matières des articles, qui pourra être jointe aux mails annonçant la publication du compte-rendu de la réunion. Serge a mis ça en place (merci!).

Philippe s’interrogeait sur les canaux de diffusion possibles pour des séminaires issues du service informatique, ce qui a soulevé quelques commentaires:

• Les cafés LoOPS ne devraient pas être des séminaires, mais des discussions. David a déjà fait face à des situations où une personne refusait d’organiser un café car elle avait le sentiment de « ne pas connaître le sujet assez pour en parler », et souhaiterait éviter que ce type d’auto-censure ne devienne la norme.
• Serge a rappelé qu’il est possible d’organiser des séminaires internes à l’échelle du LAL.
• Antoine a mentionné qu’en creusant la question du changelog automatique, il a découvert que c’était un sujet assez riche pour mériter un séminaire en soi.
• Christian a rappelé qu’il n’y a pas besoin d’être un grand expert pour présenter un séminaire, juste d’en savoir un peu plus que la moyenne.

Antoine voudrait aussi discuter prochainement de nouveaux outils d’analyse de code statique, comme le Better Code Hub, un outil d’analyse de qualité de code qui se branche sur l’API GitHub et compile différents indicateurs, un peu à la manière de Sonarqube:

• Longueur et complexité des routines
• Absence de duplication
• Simplicité des interfaces publiques
• Modules spécialisés et bien séparés
• Architecture équilibrée (pas de composant-dieu)
• Simplicité générale du code
• Tests automatisés et complets…

Hébergement et noms de domaine

Nous avons récemment reçu un mail de la DSI [1] nous informant que cette dernière propose maintenant un hébergement gratuit des sites web professionnels. Auparavant, ce service était payant.

L’apparition de ce nouvel hébergeur potentiel a lancé une discussion sur l’hébergement du blog sur Apache Spark que Christian Arnault est actuellement en train de monter à l’adresse spark.in2p3.fr.

Christian a considéré deux hébergeurs privés, WordPress.com et Overblog.  Il s’est cependant rapidement heurté aux limitations des fonctionnalités proposées gratuitement par ces derniers. Ainsi, WordPress demandait un paiement pour l’attribution d’un nom de domaine en rapport avec Spark, et Overblog inondait trop les visiteurs de publicités pour un blog professionnel.

Il a aussi pensé à héberger ce blog au LAL. Cependant, ce dernier mettait un trop fort accent sur l’utilisation d’un nom de domaine en .lal.in2p3.fr, dont le périmètre institutionnel restreint déplaisait à Christian du fait de la vocation universaliste de son blog. Serge a clarifié que le problème résidait dans la gestion trop fastidieuse des nombreux noms de domaines extérieurs, qui demandent une maintenance manuelle régulière.

Sur ce sujet des noms de domaines, Christian a mentionné plus tard par mail que le CNRS peut aussi fournir un service de noms de domaine plus général (notamment en .cnrs.fr, et en .fr via RENATER). Michel a cependant rappelé qu’il est nécessaire que les demandes de noms de domaines passent par le groupe exploitation, afin que ce dernier garde une visibilité sur les domaines gérés par le LAL.

Christian s’est ensuite tourné vers le CCIN2P3 [2]. Ce dernier lui a fourni un nom de domaine un peu plus générique en in2p3.fr, mais en revanche ne fournissait pas d’assistance particulière à l’installation et la configuration de sites. Christian a donc dû installer et configurer son installation de WordPress lui-même avec l’aide de Serge et Justine.

Une question qui reste encore à régler est celle des permissions d’édition. Pour l’instant, les gens doivent se créer un compte sur le blog Spark, et demander «manuellement» la permission d’écrire des articles à Christian. Idéalement, Christian souhaiterait que cette permission soit offerte automatiquement à quiconque s’inscrit à la mailing-list Spark, mais cela requiert une intégration entre la gestion de comptes de Sympa [3] et WordPress qui est actuellement perçue comme trop complexe pour en valoir la peine.

ElasticSearch et Kibana

Philippe s’est rendu à l’atelier sur ElasticSearch et Kibana aux JDEV. Il a trouvé ces outils intéressants pour des utilisations de «déboguage des données», par exemple pour chercher des corrélations statistiques ou des anomalies dans ces dernières.

Une application particulière qu’il avait en tête était l’analyse de logs. Il a été remarqué qu’analyser des logs n’est pas une pratique nouvelle, et qu’on l’avait évoqué lors d’une réunion Dev@Lal il y a un an et demi. Il a été aussi remarqué que ce ne sont pas les seuls outils disponibles pour ce travail, par exemple Spark est aussi parfois utilisé pour analyser des logs de serveurs afin de détecter des pannes. Il existe d’ailleurs une passerelle permettant à Spark de manipuler des données via ElasticSearch.

Le sujet de Spark étant invoqué, la discussion a un peu dérivé sur la capacité de MongoDB à gérer des données temporelles comme des logs. En effet, SQL n’est pas très simple à utiliser pour ce type de travail, mais la dimension «temps» est très utile quand on cherche à étudier des anomalies de latence. Christian a expliqué que ce n’est pas une information native en MongoDB non plus, mais qu’on peut éventuellement la gérer au niveau de la couche Spark supérieure.

Dans l’écosystème ElasticSearch, un outil de visualisation qui peut être utilisé pour ce type est Logstash, qui a également été présenté aux JDEV.

Certains des outils liés (X-Pack, lié à ElasticSearch) sont distribués sous un modèle commercial «freemium», avec une version gratuite disposant de fonctionnalités limitées et une version payante donnant accès au jeu complet de fonctionnalités. Quand on utilise ce type d’outil, il est important d’étudier attentivement les limites de la version gratuite et les conditions de licence de la version payante. Il n’est pas rare, par exemple, que la version gratuite soit open source, mais la version payante soit propriétaire.

Christian a mentionné qu’ElasticSearch serait plutôt efficace pour des besoins de recherche multicritère dans des documents texte, et qu’il était utilisé dans ce but par Nuxeo, le moteur d’Atrium. Il est aussi utilisé pour le moteur de recherche Qwant.

Quelqu’un a aussi mentionné que Dominique Mège du CCIN2P3 avait pas mal d’expérience de la mise en place de ce type d’outils d’analyse statistique.

Conteneurs et machines virtuelles

Qu’est-ce qu’un conteneur?

Antoine, David, Hadrien, Michel et Philippe ont suivi l’atelier sur Docker, LXD et Singularity aux JDEV, présenté par Alexandre Dehne Garcia et Martin Souchal. Cela été l’occasion de clarifier un peu la situation de l’écosystème des conteneurs, qui peut être difficile à aborder.

Pour comprendre la notion de conteneur, un bon point de départ est de considérer leurs prédécesseurs spirituels, les machines virtuelles. Pourquoi utilise-t-on généralement des machines virtuelles?

• Pour s’abstraire du matériel et du système d’exploitation «hyperviseur» sous-jacent et exécuter une application basée sur le matériel virtuel et le système d’exploitation de son choix.
• Pour contrôler l’accès de l’application au système d’une façon plus fine que le système d’exploitation sous-jacent ne le permet (par exemple,  dissimuler l’existence de certains matériels).
• Pour exécuter l’application dans une configuration matérielle et système bien contrôlée afin de maximiser les chances qu’elle se comporte comme dans l’environnement où elle a été développée.

Mais a-t-on vraiment besoin de toute la complexité d’une machine virtuelle pour atteindre ces objectifs? Il se trouve que sous Linux, ce n’est pas toujours le cas:

• On a rarement besoin de simuler du matériel qui n’existe pas sur l’hôte (et on souhaite rarement le faire, car c’est très inefficace)
• Il est devenu possible «au niveau système» de dissimuler une partie du système hôte, y compris les processus en cours d’exécution et les périphériques d’entrée-sortie disponibles, avec de nouvelles fonctionnalités du noyau Linux comme les cgroups [4].
• Le noyau Linux évolue assez lentement de nos jours, donc on a rarement des problèmes de compatibilité avec le noyau du système d’exploitation hôte. Les problèmes de compatibilité apparaissent plutôt au niveau de l’environnement applicatif (compilateur, versions des bibliothèques partagées…).
• Par diverses astuces impliquant le système de fichiers virtuel, on peut aisément «greffer» l’environnement applicatif d’un système Linux sur le noyau d’un autre.

L’idée d’un conteneur est donc de dire que lorsqu’on veut exécuter une application Linux sur un hôte Linux, on peut se permettre d’éliminer la complexité d’une émulation/isolation matérielle et d’une duplication du noyau de système d’exploitation hôte, et à la place ne dupliquer que l’environnement applicatif de l’application cible en l’installant par-dessus le noyau du système hôte. C’est ce que fait Docker sous Linux.

Depuis quelques années, Docker est aussi disponible sous Windows et OSX. Mais sous ces systèmes, il ne peut bien entendu fonctionner comme sous Linux, puisqu’il ne dispose pas d’un noyau Linux sous-jacent. Les versions de Docker disponibles sous OSX et Windows ne sont donc en réalité qu’une machine virtuelle Linux sous le capot. Historiquement, cette machine virtuelle était basée sur VirtualBox, mais depuis 2016, Docker peut aussi utiliser les fonctionnalités de virtualisations natives d’OSX et Windows quand on utilise une version de ces systèmes d’exploitation qui propose de telles fonctionnalités.

Docker est par exemple utilisé pour répondre aux besoins de reproductibilité logicielle d’environnements d’intégration continue, ainsi que dans les enseignements du master NPAC. Mais ce logiciel a certaines limitations en termes de sécurité qui freinent son développement dans d’autres domaines, notamment en production sur la grille de calcul ou dans des supercalculateurs…

L’écosystème des conteneurs

Docker a popularisé la notion de conteneur, mais il ne l’a pas inventée et n’en est pas la seule incarnation. Un grand nombre d’alternatives existent, chacune attaquant le problème sous un angle un peu différent.

Ainsi, une critique de Docker qui est souvent formulée par les administrateurs système est que son isolation est très poreuse. Une application s’exécutant au sein d’un conteneur Docker peut très facilement obtenir un accès administrateur au système hôte, et par ce biais avoir accès à des ressources système dont le conteneur est censé l’isoler. Par conséquent, l’isolation fournie par Docker n’est pas suffisante dans des scénarios où on doit exécuter du code auquel on n’accorde pas une confiance totale, comme c’est le cas par exemple lorsque la grille du CERN exécute des programmes d’analyse écrits par des physiciens sans compétence particulière en sécurité informatique. C’est ainsi qu’on se retrouve dans des situations assez absurdes, comme Amazon faisant tourner des conteneurs Docker par-dessus leur infrastructure de machines virtuelles.

Une solution possible à ce problème est Singularity, un système développé pour le milieu des supercalculateurs qui propose une solution de conteneur dans laquelle l’application s’exécute comme processus ordinaire et n’a pas d’accès administrateur au système hôte. Un effort a été fait pour que l’utilisation de Singularity soit similaire à celle de docker (les Dockerfiles étant compatibles), à ceci près bien sûr que l’utilisateur n’a plus le droit d’utiliser des commandes administratives comme «sudo» dans le conteneur. Cette solution semble donc bien adaptée à la conteneurisation d’applications individuelles nécessitant peu de privilèges système et auxquelles on n’accorde qu’une confiance limitée, ce qui devrait bien correspondre aux besoins de l’informatique scientifique.

Pour ceux qui auraient besoin d’exécuter des applications plus complexes nécessitant un accès plus poussé au système, et ne pouvant donc se satisfaire d’un conteneur limité à l’exécution d’applications non privilégiées, un projet peut être plus intéressant est l’extension de l’infrastructure LXC (LinuX Containers), historiquement utilisée par Docker et CoreOS, via une nouvelle surcouche appelée LXD. Contrairement à Docker, cette plate-forme se destine plutôt à la virtualisation de systèmes complets que d’applications isolées. Entre autres choses, elle vise à offrir de meilleures performances quand on lance de grands nombres de conteneurs, proposer une gestion fine des privilèges système accordés aux conteneurs, et permettre de migrer plus facilement des conteneurs d’un système à l’autre. Elle est donc à première vue mieux pensée pour des déploiements de conteneurs complexes, en production et à grande échelle.

Au-delà des conteneurs actuels

Si les technologies de conteneurs disponibles aujourd’hui sont plus légères et éliminent pas mal de complexité quand on les compare à des machines virtuelles, elles sont cependant encore loin d’atteindre l’efficacité du gestionnaire de paquet natif d’une distribution Linux moderne. Le trafic réseau important engendré par la nécessité de recopier l’équivalent de l’environnement applicatif complet d’un système d’exploitation est notamment un problème, qui limite l’application de ces technologies dans des contextes où la bande passante est limitée, par exemple lorsqu’on organise des TPs basés sur des conteneurs dans des locaux dont la connexion réseau n’est pas dernier cri.

En principe, Docker pourrait répondre à ce problème, car il permet d’ajouter des changements incrémentaux à une image existante et de ne transférer que ces changements si le client possède déjà une copie de l’image de base. Mais en pratique, l’absence de standardisation des images «mères» et la jeunesse de la technologie font que cette possibilité est difficile à exploiter en pratique.

En réponse à ce problème, diverses solutions ont été proposées. Une approche particulièrement prometteuse est d’adapter le concept de gestionnaire de paquet pour lui permettre de mieux répondre aux besoins de reproductibilité logicielle, via un contrôle plus fin des dépendances. Cette approche est poursuivie par les gestionnaires de paquets Nix et Spack, le premier se voulant plus généraliste et le second plus orienté vers les besoins du calcul haute performance.

Antoine a précisé par la suite que le tutoriel Nix présenté aux JDEV est en ligne à l’adresse https://gricad.github.io/calcul/nix/tuto/2017/07/04/nix-tutorial.html, et qu’il est possible de le rejouer en environ 3h.

Une autre évolution, matérielle celle-ci, qui a le potentiel de changer beaucoup l’utilisation qu’on a des conteneurs est Intel SGX (Software Guard eXtensions). C’est une technologie qui vise à permettre aux applications de créer des régions mémoires protégées, inaccessibles au système d’exploitation sous-jacent. L’isolation est assurée en ne conservant les données en clair qu’au niveau du CPU, en limitant drastiquement l’accès à ces données au sein du CPU, et en chiffrant toute donnée destinée à être stockée en RAM.

En principe, cela devrait permettre par exemple de sécuriser les applications de type «cloud» où l’on fait tourner du code sur des serveurs sur lesquels on n’a aucun contrôle et qui sont potentiellement sujets à espionner ce qui se passe. Ce propos optimiste doit toutefois être nuancé en mentionnant ce système possède aussi plusieurs caractéristiques nettement plus discutables:

• Pour déployer une application SGX en production (c’est-à-dire supprimer l’accès aux régions mémoires protégées offert à d’autres applications pendant la phase de débogage), il faut obtenir une licence d’Intel, représentée logiciellement par une signature cryptographique dont l’autorité de certification racine est Intel. Selon le brevet américain 8 972 746 d’Intel, c’est une décision de conception volontaire, visant à permettre l’émergence de nouveaux modèles commerciaux («is an enforcement point for a number of new business models»). Le brevet évoque ensuite de façon répétée le potentiel lucratif de la chose pour Intel.
• Comme il est également expliqué dans ce brevet, une application ainsi authentifiée par Intel peut, si Intel lui en donne la permission, aussi avoir accès à des secrets cryptographiques stockés au sein du processeur, tels que la clé «Enhanced Privacy ID» (EPID). Cette clé de chiffrement, écrite en dur dans chaque processeur et donc non révocable, est au coeur de la sécurité de SGX, et une telle application possède donc la capacité de briser la sécurité de SGX (et potentiellement celle d’autres technologies hardware de sécurité des processeurs x86).
• De nombreux aspects de l’implémentation de SGX qui jouent un rôle essentiel pour sa sécurité ne sont pas documentés par Intel. Comme Costan et Devadas l’expliquent dans leur analyse de SGX publiée en 2016, cela empêche une analyse extérieure complète de la sécurité de ce système. C’est problématique, car cela signifie que seuls les ingénieurs d’Intel sont en mesure de dire précisément quelles sont les limites de la sécurité du système SGX, or il n’est pas dans leur intérêt commercial de le faire.
• SGX est, dans sa conception même, vulnérable à de nombreuses attaques de type «side-channel» accessibles à d’autres logiciels tournant sur le même système hôte. Ainsi, une attaque par minutage de cache permettant d’accéder en 5 minutes à 96% des 4096 bits d’une clé cryptographique RSA censée être protégée par SGX a été publiée cette année. Comble de l’ironie, le logiciel attaquant utilisait également SGX pour dissimuler son activité malveillante du système d’exploitation hôte.
• Comme toute extension x86, SGX ne restera pas éternellement spécifique au milieu des gros datacenters, mais finira à terme par atterrir dans des processeurs grand public. Sur ces derniers, il est à craindre que sa principale application ne soit l’implémentation de systèmes de type DRM, visant à donner aux géants du multimédia un contrôle total et centralisé sur les oeuvres qu’ils distribuent. Cette utilisation a été explicitement prévue par Intel, comme ils l’expliquent dans le brevet susmentionné en mentionnant comme cas d’utilisation un lecteur de vidéos. Or, la généralisation de DRMs protégés au niveau matériel a des implications inquiétantes en termes d’interopérabilité des logiciels libres, de censure politique des contenus numériques, et de pérennité des oeuvres artistiques.

Glossaire

1. Direction des Systèmes d’Information du CNRS, qui gère les services informatiques centralisés comme Agate et Janus.
2. Centre de calcul de l’IN2P3.
3. Sympa est un système de gestion de mailing lists très utilisé dans la communauté de l’enseignement supérieur en France.
4. Les cgroups sont une fonctionnalité du noyau Linux permettant de manipuler des groupes de processus en leur imposant des restrictions communes, par exemple un budget total de RAM ou la (non-)visibilité des interfaces réseau.

Le sujet principal de cette réunion développeur était une présentation concernant le contrôle-commande du vide dans l’expérience VIRGO, mais elle a aussi été l’occasion de présenter Nicolas Loizeau, stagiaire L3 fraîchement arrivé dans le service.

Continuer la lecture de Réunion du 14 juin 2017 →