Greffon FusionInventory pour GLPI version 9.1 + 1.0

Posté par . Édité par Davy Defaud, ZeroHeure, Yvan Munoz, Nÿco, Nils Ratusznik et palm123. Modéré par Nÿco. Licence CC by-sa
15
21
nov.
2016
Administration système

Le greffon FusionInventory pour GLPI est sorti en version majeure 9.1 + 1.0. Cette version est compatible avec GLPI 9.1.1 (pas la 9.1 dû à un bogue dans cette version). Pour mémoire, FusionInventory est projet libre de gestion du parc informatique : il s’agit d’un outil permettant de réaliser des inventaires locaux et/ou distants des ordinateurs, des matériels réseau et des imprimantes.

logo FusionInventory

Petit rappel des fonctionnalités de FusionInventory :

  • inventaire des ordinateurs avec un agent installé dessus (Windows, Mac OS X, GNU/Linux, *BSD, AIX, Android…) ;
  • déploiement de logiciels sur les ordinateurs (P2P, serveurs mirroir…) ;
  • découverte du réseau, analyse du réseau pour trouver les matériels connectés (NetBios, SNMP…) ;
  • inventaire réseau, inventaire des commutateurs réseau via SNMP(information standard, ports, connexions sur chaque port) et imprimantes réseau (information standard, état des cartouches, compteurs d’impression) ;
  • collecte d’informations sur les ordinateurs (base de registre, WMI, recherche de fichiers) ;
  • Wake-on-LAN (réveil des ordinateurs grâce à un autre ordinateur, ce qui permet de passer les routeurs).

Les nouvelles fonctionnalités sont :

  • nouvelle gestion des informations du système d’exploitation :
    • architecture (32 bits, 64 bits…),
    • système d’exploitation (Windows, Debian, FreeBSD…),
    • version du système d’exploitation (XP, 7, 6.4…),
    • nom du noyau (MSWin32, Linux…),
    • version du noyau (6.1.7601, 3.18.34…),
    • service pack,
    • édition (professionnelle, serveur standard…) ;
  • gestion du système d’exploitation dans les logiciels ; par exemple, on peut avoir deux logiciels avec le même nom, un pour Windows et un pour Mac OS X ;
  • informations des logiciels d’accès distant ; par exemple, on gère l’identifiant de TeamViewer ;
  • nouvelle option dans la gestion des tâches ; on peut ne pas replanifier la tâche si la dernière exécution a été réalisée avec succès ;
  • simplification de la gestion des paquets de déploiement (fusion des onglets Installation et Désinstallation) ;
  • déploiement en mode self‐service : l’administrateur ou le technicien créent un paquet que l’utilisateur peut installer lui‐même sur son PC, même s’il n’est pas administrateur de son ordinateur ;
  • ajout de la date d’installation d’un logiciel dans la fiche d’un ordinateur ;
  • amélioration de la sécurité (filtrage de toutes les requêtes HTTP GET et POST).
  • # OCSInventory-NG versus FusionInventory

    Posté par . Évalué à 4.

    Quelqu'un a t il des éléments pour lister les grands points forts et faibles de ces 2 solutions ?

    • [^] # Re: OCSInventory-NG versus FusionInventory

      Posté par . Évalué à 3.

      Pour être a peu près objectif, les 2 grosses différences :

      • La partie serveur de FusionInventory est un plugin de GLPI, donc on met à jour directement la base de données de GLPI
      • Je suis développeur de FusionInventory et de GLPI,donc c'est un peu plus simple pour faire bien évoluer les 2 produits
      • [^] # Re: OCSInventory-NG versus FusionInventory

        Posté par . Évalué à 1.

        Merci pour ces précisions sur FusionInventory.

      • [^] # Re: OCSInventory-NG versus FusionInventory

        Posté par . Évalué à -4.

        Je ne vois pas vraiment où est l'objectivité dans ton propos ?
        Tu prèche pour ta paroisse sans comparer.

        • [^] # Re: OCSInventory-NG versus FusionInventory

          Posté par . Évalué à 1.

          Avec le recul, tu as raison :(

        • [^] # Re: OCSInventory-NG versus FusionInventory

          Posté par (page perso) . Évalué à 2.

          Objectivité ne signifie pas comparaison.

          Le commentaire de David est objectif, il donne des faits qui ne sont pas biaisés.

          C’est objectif que FusionInventory mette directement à jour la base de donnée de GLPI.
          C’est objectif qu’il y a au moins un développeur qui est sur les deux projets à la fois.

          Par contre oui, ça ne répond pas au besoin de netchaiev qui, lui, demandait un comparatif. Le commentaire de David ne manque pas d’objectivité, il ne répond pas à la question, ce n’est pas pareil.

          ce commentaire est sous licence cc by 4 et précédentes

  • # Comparatif

    Posté par . Évalué à 1.

    OCSInventory/GLPI c'est la vieille école, deux interfaces pour gérer deux choses différentes, deux bdd. Loin d'être pratique, devoir jongler avec les onlgets pour faire des trucs basiques, j'en pouvais plus.

    Fusioninventory/GLPI une seule interface, une seule BDD et des fonctionnalitées un peu plus poussée que OCS. Pour une nouvelle install ou un renouvellement de la solution de gestion de parc c'est la solution.

  • # version recommandée?

    Posté par . Évalué à 1. Dernière modification le 23/11/16 à 15:30.

    Bonjour et merci pour les infos et le boulot effectué!
    Ce qui suit sort un peu du cadre de ce forum, mais j'ose une petite question/interrogation:
    Le greffon FusionInventory version majeure est proposé pour la version 9.1.1 de GLPI, qui si je ne dis pas de çonnerie n'est pas une version stable recommandée pour la production?
    (vais quand même tenter l'affaire, qui ne tente rien n'a rien, et puis la version packagée est stable mais assez ancienne.)
    Concernant la question OCSI vs FusionIventory, comme précisé plus haut, OCSInventory-NG server/report requiert en partie (sauf erreur de ma part) un serveur Apache/ModPerl2, ce qui n'est pas le cas de GLPI, ni de son plugin FusionInventory.
    Enfin je me permets une petite remarque (pas un troll j'espère :-)) :
    force est de constater que GLPI est de moins en moins "léger" et fait de plus en plus de choses (via ses greffons certes mais pas seulement), et peu à peu marche sur les plates-bandes de solutions de monitoring bien établies.

Suivre le flux des commentaires

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