Entrevue avec les auteurs de FusionInventory

Voici une entrevue avec les auteurs de FusionInventory, projet libre de gestion du parc informatique. C’est un outil qui permet des inventaires locaux ou distants des ordinateurs, des matériels réseau et des imprimantes. FusionInventory fonctionne très bien avec GLPI… dont l’un des auteurs s’est entretenu également avec LinuxFr.org.

LinuxFr.org : T’es qui toi ?

David Durieux : J’habite à Beaujeu, dans le Rhône. Depuis mon adolescence, je suis un autodidacte passionné d’informatique (matériel, administration de serveurs et réseau, et programmation). Je suis contributeur sur les projets GLPI, FusionInventory et Shinken-Monitoring.

Gonéri Le Bouder : Je vis en Île‐de‐France, même si je suis très attaché à la Bretagne. J’ai fait mes études à Saint‐Malo, et depuis quelques années maintenant, je suis aussi développeur Debian et un Mongueur Perl.

Fabrice Flore‐Thébault : Je vis à Bruxelles où j’anime les Jeudis du Libre. Je suis un compagnon de route de FusionInventory, GLPI et Rudder, dont les contributions ne sont pas du code.

Walid Nouh : Je vis à Sète, et je travaille avec Gonéri. Je fais surtout des déploiements chez les clients, ainsi que des tests.

Guillaume Rousse : Je suis Parisien. J’ai rejoint le projet récemment, lorsque j’ai commencé à déployer la solution au travail. Au départ, il s’agissait juste de quelques patches pour corriger ou nettoyer un peu le code de l’agent, et comme j’ai vite gonflé Goneri avec mes demandes d’intégration journalières, j’ai rapidement hérité d’un accès en écriture au dépôt Git…

LinuxFr.org : C’est quoi FusionInventory ? Qu’est‐ce que ça fait, et comment ?

FusionInventory est une brique qui permet d’ajouter des nouvelles fonctionnalités à l’outil de gestion de parc libre GLPI.
Cette description est un peu réductrice, car elle laisse penser que nous ne sommes pas ouverts à d’autres projets tiers, ce qui est faux. Par exemple, les logiciels Uranos et Rudder s’interfacent avec l’agent.

Au niveau des fonctionnalités, voici les grands axes :

 - Une intégration complète avec l’interface de GLPI

La partie serveur est un greffon pour GLPI, sans autres dépendances, la mise en place des remontées d’information issues du parc informatique dans GLPI est triviale.

 - La découverte réseau

FusionInventory va, à la demande de l’administrateur, faire des balayages du réseau et identifier les équipements connectés. Cette fonction permet de répondre facilement à des préoccupations récurrentes des administrateurs système :

• existe‐t‐il des machines de mon parc qui ne sont pas inventoriées ?
• quels sont les équipements que je ne connais pas et qui peuvent mettre en danger la sécurité de mon réseau informatique ?
• comment identifier les imprimantes et les équipements réseau pour les gérer dans GLPI ?

 - L’inventaire des ordinateurs, des machines virtuelles, des serveurs ESX, des imprimantes réseau et des équipements réseau

 FusionInventory peut faire un inventaire complet de différents équipements :

• ordinateur : du portable sous Windows au serveur Mac OS X, jusqu’à la grosse machine AIX P7, il est possible, via l’utilisation d’un agent, d’avoir une remontée d’inventaire complète automatique ;
• machines virtuelles : l’agent remonte aussi la liste des machines virtuelles hébergées sur l’ordinateur, les relations seront présentées dans GLPI, dans la mesure du possible ;
• les serveurs ESX/ESXi/vCenter : il n’est pas possible d’installer un agent sur ces machines, nous faisons l’inventaire à distance en utilisant les API officielles (nous souhaitons à terme étendre cet inventaire à d’autres hyperviseurs) ;
• imprimantes : en fonction du niveau de couverture de votre équipement, nous pouvons présenter dans GLPI l’état des cartouches d’encre, les niveaux des compteurs d’impression, et donc la visualisation de ces compteurs au fil du temps ;
• équipements réseau : pour un grand nombre d’équipements, nous sommes en mesure d’afficher la table de brassage des ports (liaison entre commutateurs, mais aussi avec tous les matériels : ordinateurs, serveurs, imprimantes, badgeuses…), et beaucoup d’informations complémentaires, directement dans GLPI. Nous sommes très fiers de cette fonction, qui permet de connaître, en quelques clics, l’enchaînement des équipements qui relient les éléments du réseau entre eux.

 - Le réveil des machines sur le réseau (Wake On Lan)

Vous pouvez programmer un réveil de votre parc via une tâche planifiée dans GLPI. Par exemple, pour faire l’installation d’une grosse mise à jour durant la nuit.

 - Et très très bientôt, le télé‐déploiement d’applications

Nous y travaillons depuis plusieurs mois maintenant. Nous nous sommes inspirés des solutions existantes pour proposer un outil le plus pratique possible et bien intégré dans GLPI.

LinuxFr.org : C’est sous quelle(s) licence(s) ?

L’ensemble des développements sont en GPL v2+. Le greffon FusionInventory pour GLPI passera en AGPL v3 lors de sa prochaine version.

LinuxFr.org : C’est développé autour de quelles « technos » ?

Nous utilisons un agent en Perl pour la partie collecte des informations. Depuis plusieurs mois, sous l’impulsion d’un travail de fond mené par Guillaume Rousse, nous sommes dans une phase d’amélioration conséquente de la qualité du code.
La partie serveur utilise l’API/framework PHP de GLPI.

LinuxFr.org : Ça se compare à quoi de libre ou proprio ?

Nous ne connaissons pas très bien les solutions propriétaires concurrentes. Elles offrent en général une très bonne couverture, parfois avec une adhérence forte sur une marque d’équipement ou sur un système d’exploitation, mais le prix est aussi au rendez‐vous.

Du côté du Libre, il y a, bien sûr, OCS Inventory NG, dont nous sommes issus à l’origine (l’agent fusion dérive de l’agent UNIX d’OCS). Mais, eux, visent une solution autonome (agent et serveur), tandis que nous préférons nous appuyer sur GLPI pour la seconde partie. Il doit également exister d’autres alternatives, mais, à notre connaissance, aucune avec une couverture aussi large et une aussi bonne intégration avec une solution de gestion de parc moderne.

Il faut noter également que de plus en plus de solutions de gestion de configuration, comme Puppet ou Chef, commencent à intégrer un aspect remontée d’inventaire. Il y a sans doute là l’amorce d’une convergence en cours entre les deux rôles. C’est ce qu’on retrouve également dans des produits comme Rudder ou Uranos, qui intègrent l’agent FusionInventory.

LinuxFr.org : Ce sont quoi les tueries de ce soft ?

Le point fort de FusionInventory est d’être complémentaire de GLPI, un excellent logiciel de gestion de parc libre, qui dispose d’une très bonne dynamique communautaire. Ce choix, fait en début de projet, de ne pas réinventer la roue, nous a permis de nous concentrer sur les choses importantes, en ne nous préoccupant pas de certains aspects (tâches planifiées, habilitations et interface LDAP, etc.).
Il faut dire que ce choix n’est pas venu par hasard, puisque plusieurs membres de l’équipe sont aussi contributeurs sur GLPI.

Ensuite, sûrement :

• le côté multi‐plate‐forme : nous souhaitons avoir une couverture fonctionnelle la meilleure possible sur tous les systèmes d’exploitation. Mac OS X est aussi important que Solaris ou Windows ;
• la couverture des équipements réseau : plutôt que d’avoir une couverture réseau partielle à cause des faiblesses des implémentations SNMP des fabricants, nous avons fait le choix d’étudier au cas par cas l’ensemble des produits pour tenir compte de leurs bogues^ww cas particuliers. Ce travail de fourmi, chronophage, est mené par David Durieux, le mainteneur de cette partie du logiciel, ainsi que du serveur. Plus de 1 700 commutateurs Ethernet et imprimantes sont actuellement pris en charge, et nous en rajoutons très régulièrement grâce aux contributions des utilisateurs (snmpwalk de leur équipements).

LinuxFr.org : Est‐ce que FusionInventory s’intègre à des solutions d’orchestration, libres, comme Archipel, ou proprio, même s’il ne s’agit pas de matériel, mais de machines virtuelles ?

La partie inventaire est l’élément le plus connu du projet, et aussi le plus utilisé par d’autres solutions. C’est le cas du projet Rudder, dont le produit a pour finalité l’évaluation de la dérive du système d’information : inventorier et configurer les serveurs, et rendre compte dans une console Web du taux de conformité de ces derniers avec la norme fixée. L’agent est aussi utilisé pour effectuer l’inventaire des machines par le projet Uranos. Ce logiciel permet l’installation silencieuse et la configuration de postes de travail Windows.
On travaille donc déjà avec ses solutions, et des discussions sont en cours avec certaines, donc il ne faut pas hésiter à nous contacter si l’agent intéresse d’autres projets. Je n’ai pas encore vu comment fonctionne Archipel et si les développeurs en auraient besoin.

LinuxFr.org : Y a‐t‐il un business model autour ?

Deux d’entre nous travaillent dans la société TECLIB’, qui propose du service autour de GLPI et FusionInventory. David Durieux a sa propre société, siprossii, qui propose du service autour de GLPI, FusionInventory et Shinken-monitoring.
Les grands domaines où nous intervenons sont les suivants :

• les études et le conseil pour des projets de migration ou de mise en place de GLPI et/ou FusionInventory ;
• le développement de nouvelles fonctionnalités sur GLPI et/ou FusionInventory ;
• l’intégration de systèmes tiers ;
• les formations sur GLPI ;
• le support professionnel.

Ce modèle nous permet d’être en contact direct avec les besoins des clients, et donc de faire évoluer la solution.
D’un autre côté, nous sommes tous très attachés au modèle communautaire, qui garantit une évolution saine du produit (une entreprise ne contrôlant pas l’ensemble du projet).
Nous sommes également très attachés au fait de ne mettre à disposition qu’une seule version, qui est complètement communautaire (pas de version payante avec des options en plus, ou de version communautaire bridée).

LinuxFr.org : Quels sont les déploiements publics ou privés (dont vous pouvez parler) les plus significatifs ?

• l’École Centrale de Lyon ;
• l’ENS LSH, qui est désormais l’ENS de Lyon qui a financé le démarrage de la partie inventaire SNMP des commutateurs réseau en 2008 ;
• Rector Lesage ;
• Capio ;
• plusieurs Conseils Généraux ;
• l’université Paris‐Sorbonne.

D’autres références dans des groupes industriels importants existent, mais ces derniers ne souhaitent pas communiquer dessus.

LinuxFr.org : Sur ces projets, vous inventoriez combien d’équipements ? Quelle est la carte d’identité type de ce type de parc ?

Plusieurs dizaines, voire des centaines, de commutateurs réseau et imprimantes, et plusieurs milliers de postes clients et serveurs. Nous intervenons sur des parcs de plus en plus conséquents (avec plusieurs milliers de commutateurs réseau et plusieurs dizaines de milliers d’ordinateurs à inventorier).
Ça va du petit parc de 50 machines, à plusieurs dizaines de milliers.

LinuxFr.org : Question naïve, est‐ce que FusionInventory permet de prévoir le renouvellement de parties du parc ? Genre remontée d’alertes sur les machines devenues amorties, obsolètes, ou bien en fin de support ?

FusionInventory ne fait pas ce genre de chose, c’est le rôle du logiciel de gestion de parc, tel que GLPI, qui permet de gérer les dates d’achats, les durées de garantie et les contrats de support, et d’envoyer des notifications lorsque c’est nécessaire. Il est à noter que l’on peut récupérer ces dates de fin de garanties automatiquement sur les sites Web de certains fabricants (HP, Dell, Fujitsu et Toshiba) via le greffon Manufacturer Import.

LinuxFr.org : Vous êtes combien de contributeurs ?

La réponse va varier en fonction de la définition du mot « contributeur ». De nombreuses personnes participent aux efforts sur la prise en charge de nouveaux équipements, sur la traduction, sur le débogage et les tests. Ensuite, nous avons un cercle plus restreint de contributeurs réguliers :

• environ 5 personnes participent au développement de façon régulière ;
• une dizaine d’autres nous aident de façons diverses à un rythme hebdomadaire.

LinuxFr.org : Comment est né le projet ? Comment a‐t‐il évolué ? Quels sont les faits marquants ?

L’agent d’inventaire a été initié en 2006, à l’époque sous un autre nom. La partie serveur et la partie SNMP sont nées en 2008 (greffon Tracker pour GLPI). Nous avons commencé à nous rapprocher en 2009, en créant un projet distinct du nom de FusionInventory.
Nous travaillons beaucoup sur la qualité et écrivons beaucoup de tests unitaires depuis quelques mois, afin d’avoir des publications avec le moins de problèmes (il en reste toujours, mais la qualité se fait sentir au fil des nouvelles versions).

LinuxFr.org : Quels problèmes avez‐vous rencontrés ?

Gonéri Le Bouder : Nous souhaitons tous que les journées fassent 48 heures. Dans mon cas, je dois mener de front mes activités professionnelles, répondre aux contributeurs sur FusionInventory et suivre les paquets où je suis actif chez Debian.

David Durieux : Les soucis viennent des constructeurs, sur le SNMP, car il n’est pas toujours propre ; on arrive à avoir des différences entre deux micro‐logiciels (firmwares) d’un même modèle de commutateur réseau, des téléphones IP sans SNMP, et donc difficiles à inventorier (alors qu’il y en a de plus en plus en entreprise). Nous avons (nous et plusieurs de nos utilisateurs/clients) appelé des constructeurs pour leur signaler des soucis dans l’implémentation SNMP (comme les photocopieurs Canon qui n’ont pas le numéro de série sur la plupart de leur modèles), mais on se fait souvent refouler par le support. On a quand même de bons contacts avec HP, par exemple, pour prendre en charge les commutateurs réseau Procurve.

Guillaume Rousse : Pleins…
D’abord, la portabilité pose un certain nombre de défis techniques. Écrire un code qui tourne à la fois sur des systèmes de type UNIX et Windows n’est pas trivial, dès lors que l’on touche à des fonctionnalités comme le parallélisme (multiples processus ou fils d’exécution [threads]) ou le modèle client‐serveur. Ensuite, il ne suffit pas d’avoir un code qui tourne, il faut aussi qu’il soit pertinent, c’est‐à‐dire qu’il remonte des informations utiles et adaptées. Or, nous ciblons certains UNIX propriétaires historiques (AIX, IRIX, HP-UX, SunOS/Solaris) dont personne ne dispose parmi les développeurs. Nous dépendons donc largement des utilisateurs concernés pour, non seulement tester, mais également faire des choix éclairés sur ces plates‐formes.

Cette même portabilité pose également des problèmes au niveau de la distribution du logiciel. Je suis mainteneur de paquetages Mandriva, Mageia maintenant, depuis une dizaine d’années, donc le modèle que je privilégie est celui des distributions GNU/Linux : les développeurs mettent en ligne le code source, les intégrateurs font le reste. Je veux bien admettre que pour Windows il y ait un problème culturel, et qu’il faille fournir des exécutables prêts à l’emploi ; mais j’ai du mal à comprendre qu’un admin système UNIX ne soit pas capable de lire un fichier INSTALL, et qu’il faille faire le travail (mal) nous‐même à sa place… Mais comme mes petits camarades sont beaucoup plus compréhensifs que moi, on fait des compromis. :)

Enfin, l’agent a un lourd passif d’agglomération de fonctionnalités tous azimuts, sans modèle global cohérent. Par exemple, certaines tâches sont configurées principalement par l’agent, comme l’inventaire, d’autres entièrement par le serveur, comme la découverte réseau. Pour un agent censé être générique, c’est pas terrible d’avoir autant d’options codées en dur pour une tâche spécifique. Et je défie quiconque de pouvoir décrire exactement le principe de fonctionnement de l’agent sans lire le code, par exemple… J’aimerais bien arriver un jour à quelque chose de plus homogène, mais c’est difficile à faire sans perte de fonctionnalités.

LinuxFr.org : Quelle est votre feuille de route ?

Nous allons dans un premier temps publier le support de la télédiffusion, ainsi que l’agent 2.2.x avec son architecture interne repensée.
En parallèle, la publication de la première bêta de GLPI 0.83 ne va plus tarder. Il faudra alors que nous publiions un nouveau serveur avec la gestion de cette version.

Sur le plus long terme, nous avons planifié un travail de refonte d’une partie du serveur pour la rendre plus facilement maintenable. Nous souhaitons développer encore plus notre relation avec le projet GLPI, car notre agent remonte toujours plus d’informations, repoussant parfois les limites de l’outil (par exemple, la gestion des téléphones intelligents, les smartphones).

LinuxFr.org : Merci les mecs !

De rien. C’est un plaisir d’être invité à présenter son projet de la sorte. Merci Nÿco< et LinuxFr.org.

Aller plus loin

• FusionInventory.org (518 clics)