Fork de OCS Inventory : ça bouge du côté de l'inventaire de parc libre

Posté par  (Mastodon) . Modéré par baud123.
16
3
juin
2010
Technologie
Il y a quelques, mois une partie des développeurs d' OCS Inventory a décidé de quitter l'équipe pour lancer un nouveau projet nommé FusionInventory.
FusionInventory est - au départ - la fusion de deux projets :
  • Le greffon GLPI Tracker (interrogation et découverte SNMP) renommé en FusionInventory for GLPI ;
  • L' agent UNIX unifié OCS Inventory forké renommé en FusionInventory Agent

L'objectif de l'équipe est de :
  • Réaliser un projet dynamique aux processus de décision ouverts ;
  • S'interfacer au mieux avec les différents acteurs existant dans le monde de la gestion de parc ;
  • Permettre à des projets tiers d'utiliser FusionInventory pour une ou plusieurs de ses capacités ;
  • Garder sur le long terme la compatibilité avec le serveur OCS pour la remontée d'inventaire.
FusionInventory a pour objectif de fournir un agent unique le plus modulaire possible qui peut :
  • Inventorier le parc des machines et remonter les informations dans GLPI entre autres ;
  • Faire de la découverte réseau sur les équipements connectés (imprimante, routeur, commutateur, téléphones IP, etc.) ;
Une bibliothèque est en cours de développement afin de permettre l'intégration rapide d'un mini serveur de communication FusionInventory (qui utilise le protocole de communication OCS) : celle-ci doit être le plus simple possible pour que les applications qui souhaitent profiter de remontées d'inventaire puissent le faire avec un coût d'intégration réduit. Une intégration poussée de cette bibliothèque avec GLPI est prévue à terme.

Aujourd'hui l'agent fonctionne sur l'ensemble des OS majeurs (Linux, Windows, Mac OS X, BSD, HP-UX, AIX, Solaris). Des paquets existent actuellement pour Debian/Ubuntu, Fedora/RHEL/CentOS, Mandriva Linux, FreeBSD et sont en cours d'élaboration pour Windows et Mac OS X.

FusionInventoryAgent est composé des modules suivants :
  • Communication RPC : permet de réveiller l'agent à distance qui contacte le serveur, puis récupère les informations pour lancer des commandes ;
  • Inventory : permet d'inventorier la machine sur laquelle l'agent est installé. Il remonte les informations matérielles, les logiciels avec leurs numéros de version, les machines virtuelles hébergées et les processus. Pour le moment, et en attendant que la bibliothèque FusionInventory soit opérationnelle, ce module communique uniquement avec le serveur OCS Inventory (qui ne sait traiter qu'une partie de ces informations) mais corrige du coup certains bugs qui étaient présents sur les agents OCS tels que le support complet de l'UTF-8 ou la remonté des logiciels 64 Bits sous Windows ;
  • WakeOnLan : permet de réveiller les machines à distance ;
  • NetDiscovery : Découverte réseau (NMAP, Netbios, SNMP) afin de récupérer un maximum d'informations sur les matériels connectés au réseau ;
  • SNMPQuery : Interroge les équipements réseau répondant en SNMP par exemple :
    • les imprimantes réseau avec leur numéro de série ainsi que l'état des cartouches et les compteurs d'impression ;
    • les commutateurs avec les informations sur chaque port (vitesse, erreur, historique) mais aussi que les matériels connectés sur celui-ci.

  • OcsDeploy : reprise du système de déploiement de paquets d'OCS mais avec une surcouche P2P afin d'optimiser la bande passante et d'éviter de gérer des dépôts sur chaque site distant.

La documentation est actuellement en cours de rédaction. Pour toutes questions, il est possible de joindre les développeurs sur le canal IRC, la mailing list ou le forum du projet.

Aller plus loin

  • # pourquoi forker?

    Posté par  . Évalué à 10.

    la première question que je me suis posé en lisant la dépêche c'est "pourquoi forker?"... Pas que je critique et il y a souvent de bonnes raisons. Mais du coup il est intéressant de les connaitre.

    bref: pourquoi le fork?
    • [^] # Re: pourquoi forker?

      Posté par  . Évalué à 5.

      Quand la team ne fais plus évoluer un produit, n'intègre pas des patch important depuis plusieurs années, on arrive à ce genre de chose.

      FusionInventory avance très vite, ajoute pleins de fonctionnalités, fait des corrections très rapidement et mise sur un "agent unifié" que plusieurs projets peuvent utiliser et coder un module.
  • # Ca tombe bien

    Posté par  (site web personnel) . Évalué à 1.

    Je suis en train d'implémenter un inventaire d'un parc
    Par contre, je dois bosser en agentless :(
    Merci de l'info, je vais suivre ça de trèèèès pret :D
    • [^] # Re: Ca tombe bien

      Posté par  . Évalué à 1.

      Bosser en agentless réel ca veux dire recupérer très peu d'infos du parc et donc gérer ton parc informatique manuellement, ce qui est est assez moyen quand même.
      • [^] # Re: Ca tombe bien

        Posté par  (site web personnel) . Évalué à 1.

        Je n'ai pas le choix ... sinon pour sur que j'aurais mis de l'agent...

        Imposé par le chef, pas d'agent sur les serveurs
        • [^] # Re: Ca tombe bien

          Posté par  (Mastodon) . Évalué à 2.

          Le sujet a été abordé sur la liste. En gros, c'est faisable assez rapidement pour une personne qui connait Perl. Le patch sera accepté avec plaisir sous réserve qu'il soit fait en synergie avec le projet. Vous pouvez réouvrir la discussion si vous voulez.
        • [^] # Re: Ca tombe bien

          Posté par  (site web personnel) . Évalué à 1.

          Pour ma culture, une bête question,
          agentless si je comprends bien, ça veut dire que sur les machines que tu veux inventorier
          tu n'as pas d'agent spécialisé pour faire l'inventaire, est-ce bien ça?

          Si oui quels moyens as-tu pour accéder à ces machines? telnet, ssh, snmp etc...??
          • [^] # Re: Ca tombe bien

            Posté par  . Évalué à 1.

            On peut faire cela avec Windows remote management pour les os microsoft par exemple.
            • [^] # Re: Ca tombe bien

              Posté par  (site web personnel) . Évalué à 2.

              Enfin, le Windows remote management signifie en pratique que ton poste de travail est un serveur (Partage de fichier et d'imprimante actif) et que tu lances l'agent à distance (type psexec). Donc cela revient au même, voire c'est pire...
      • [^] # Re: Ca tombe bien

        Posté par  . Évalué à 1.

        Sur nos serveurs Windows, j'ai pu voir que SNMP renvoie une quantité considérable d'informations, dont les programmes installés, les versions (si j'ai bonne mémoire), ainsi que les indicateurs standards (réseau, mémoire, disques...), plus d'autres choses que j'ai oubliées. A quel genre d'information faites-vous allusion?
  • # Présentation

    Posté par  . Évalué à 4.

    Pour information, j'ai vu que le projet doit être présenté aux prochaines RMLL en juillet : http://2010.rmll.info/FusionInventory-est-un-projet-commun-d(...)
  • # question Fusion inventory...

    Posté par  . Évalué à 1.

    Bonjour,

    J'utilise Ocsng et GLPI et il n'y a pas longtemps j'ai eu besoin du plugin Tracker.

    Il m'a bien rendu service, c'est indéniable. Mais j'ai aussi été surpris de ses capacités dans le sens où il fait se rapprocher GLPI d'un outil de monitoring (particulièrement dans sa capacité à interroger des équipements réseaux tels que les switchs).

    J'imagine que FusionInventory va être encore plus performant en terme de découverte et de remontée d'infos.

    D'où ma question : le processus ne devient-il pas trop lourd pour un outil d'inventaire ?

    Quoi qu'il en soit, Tracker est très utile et FusionInventory va l'être aussi, c'est sûr.
    • [^] # Re: question Fusion inventory...

      Posté par  . Évalué à 3.

      On fait de l'inventaire, donc on récupére les infos des ports des switchs avec les connexions entre ces ports et les ordi connectés dessus. Ca peut effectivement être vu comme du monitoring mais pour nous pour complèter l'inventaire :)

      Les 2 peuvent effectivement se rejoindre et la frontière est mince.

      Pour la question : est-ce trop lourd, je sais pas, mais il faut bien inventorier son parc et switch + imprimantes réseau y compris.
  • # Déjà utilisable en production ?

    Posté par  . Évalué à 1.

    Bonjour,

    Nous utilisons conjointement OCS Inventory NG et GLPI depuis un bon moment, et je voulais savoir si OCS Inventory Server pouvait être complètement remplacé par le plugin dédié à GLPI et si l'ensemble (FusionInventory + Plugin pour GLPI) était déjà utilisable en production ?

    merci
    • [^] # Re: Déjà utilisable en production ?

      Posté par  . Évalué à 2.

      Pour remplacer OCS Serveur, ce n'est pas encore possible, on y travaille en fait coté Fusion et coté GLPI (pour ajouetr des champs en plus).

      On prevoit ça vers la fin de l'année pour remonter directement les inventaires dans GLPI.

      Néamnois, si vous envoyer les inventaire au plugin, il les envoi sur votre serveur ocs (déclaré dans GLPI). C'est un peu proof of concept même si celà fonctionne en attendant de traiter directement ca dans GLPI..
      • [^] # Re: Déjà utilisable en production ?

        Posté par  . Évalué à 1.

        J'ai un peu de mal à voir ce qui est utilisable à l'heure actuelle avec Fusion. Je suis amené à gérer un serveur OCS/GLPI pour un parc d'environ 200-250 machines et je regrette effectivement le manque de découverte des éléments réseaux par OCS.


        Si je comprends bien, à l'heure actuelle on peut remplacer l'agent OCS par un agent Fusion et le plugin GLPI d'import OCS par un le plugin Fusion ?
        • [^] # Re: Déjà utilisable en production ?

          Posté par  . Évalué à 1.

          Non le matos réseau en SNMP va directement dans le plugin fusion et donc GLPI

          Pour l'inventaire des machine (comme l'agent OCS), vous pouvez le faire remonter par le plugin fusion qui va l'envoyer dans votre serveur OCS (il en faut qu'un seul de configuré dans glpi) et après soit vous utilisez le plugin de synchro ocs soit le plugin fusion synchronise directement (donc du serveur ocs à glpi) après avoir envoyé au serveur ocs

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.