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

Posté par Gonéri Le Bouder (Mastodon) le 03 juin 2010 à 02:19. Modéré par baud123.

Étiquettes :

juin

2010

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

Le site (660 clics)
La forge (127 clics)

# pourquoi forker?

Posté par jahrynx le 03 juin 2010 à 03:49. É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 David DURIEUX le 03 juin 2010 à 09:32. É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.
  - [^] # Re: pourquoi forker?
    
    Posté par Goalou Erwan le 03 juin 2010 à 11:41. Évalué à 1.
    
    Bonjour David
    
    au vu de l'activité du projet OCSinventory sur launchpad, tes propos ont l'air d'une bonne contre-vérité...
    
    bonne journée
    - [^] # Re: pourquoi forker?
      
      Posté par carlo le 03 juin 2010 à 12:07. Évalué à 2.
      
      Bonjour,
      
      je ne suis pas certain que les sources soient sur launchpad, et si on regarde sur http://forge.fusioninventory.org/projects/fusioninventory-ag(...) il y a bien une activité sur le code.
      
      Par contre en effet sur launchpad on dirait qu'il y a le dépôt de la version Debian de fusioninventory.
      
      Qu'en disent les développeurs du projet ?
      
      ps : par contre je trouve le titre de la dépêche pas très clair, et "fork de l'agent ocs inventory" aurait été plus exact à mon avis.
      - [^] # Re: pourquoi forker?
        
        Posté par Gonéri Le Bouder (Mastodon) le 03 juin 2010 à 12:25. Évalué à 4.
        
        Les sources sont hébergés dans notre forge et synchronisées sur Github ( http://github.com/fusinv ) et Gitorious ( http://www.gitorious.net/+fusioninventory ).
        
        Les sources des paquets Debian sont gérés dans Debian directement :
        http://git.debian.org/?p=users/goneri/fusioninventory-agent.(...)
        
        La remarque est juste pour ce qui est du titre de la dépêche. Je pense même que techniquement, ce n'est pas forcement un fork, vu que l'équipe de développement qui maintient l'agent FusionInventory reste la même. On a surtout pris nos responsabilités pour faire ce qu'on souhait depuis des mois voire des années.
# Ca tombe bien

Posté par Katyucha (site web personnel) le 03 juin 2010 à 10:40. É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 David DURIEUX le 03 juin 2010 à 11:04. É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 Katyucha (site web personnel) le 03 juin 2010 à 11:35. É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 Gonéri Le Bouder (Mastodon) le 03 juin 2010 à 12:00. É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 Katyucha (site web personnel) le 03 juin 2010 à 12:06. Évalué à 1.
        
        Je travaille sous perl justement pour trouver une solution
        Je suis un pietre programmeur par contre XD
    - [^] # Re: Ca tombe bien
      
      Posté par NOULARD Eric (site web personnel) le 04 juin 2010 à 00:23. É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 Jean-Emmanuel LACÔTE le 04 juin 2010 à 10:22. Évalué à 1.
        
        On peut faire cela avec Windows remote management pour les os microsoft par exemple.
        
        [^] # Re: Ca tombe bien
        
        Posté par Sytoka Modon (site web personnel) le 05 juin 2010 à 13:00. É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 FantastIX le 03 juin 2010 à 16:26. É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 tuiu pol le 03 juin 2010 à 11:04. É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 tontonrico le 03 juin 2010 à 11:51. É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 David DURIEUX le 03 juin 2010 à 12:03. É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 Morgan LEFIEUX le 03 juin 2010 à 17:12. É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 David DURIEUX le 03 juin 2010 à 17:15. É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 Sharpshooter le 03 juin 2010 à 19:38. É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 David DURIEUX le 03 juin 2010 à 19:42. É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.