H-inventory : Un nouvel Asset Manager OpenSource

Posté par . Modéré par Nÿco.
Tags :
0
25
oct.
2006
PHP
H-inventory est une nouvelle solution d'inventaire de parc comme le fait OCSInventory. Basé principalement sur PHP5 et PEAR, l'installation, la configuration, le debug sont beaucoup plus souples que OCSInventory.

Mais l'avantage de H-inventory est que le projet possède également divers modules qui permettent de gérer les incidents (HelpDesk), de faire un audit réseau (scan nmap), de faire du monitoring sur les services (alertes mails...), de déployer automatiquement des applications Windows et Linux (Hideploy).

Pour l'interface les pré-requis sont PHP5, MySQL et PEAR.

En ce qui concerne les clients pas de pré-requis, ce sont des scripts VBS ou bash. Ainsi les OS supportés vont de Windows, Linux, FreeBSD, OpenBSD, Solaris.

La version actuelle est Beta7 et le projet recherche donc des traducteurs, codeurs PHP, documentalistes afin de pouvoir rapidement passer en version stable.

H-inventory est hébergé par sourceforge et est distribué sous licence GPL.
  • # OCSInventory

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

    Bonjour,


    Basé principalement sur PHP5 et PEAR, l'installation, la configuration, le debug sont beaucoup plus souples que OCSInventory.


    Je trouve que ça fait un peu argument gratuit. Vous pouvez développer s'il vous plait ?
    • [^] # Re: OCSInventory

      Posté par . Évalué à 3.

      Bonjour Gonéri,

      En entreprise, j'ai pendant longtemps utiliser le couple OCS/GLPI qui était parfait mais je trouvais cà un peu galère avec perl ou même pour debugguer l'application même si le site est bien documenté.
      Par contre une fois que tout est en place , je trouve ca nickel , tout roule !
      Par contre lorsque j'ai testé H-inventory il y a un installeur automatique donc bon à part certains modules pear à installer , j'ai trouvé cà plus rapidement abordable.
      Et pour les clients, pas de dépendances à installer.
      Et même pour debugguer le serveur ce n'est que du php , par contre OCS le serveur de communication en perl j'ai eu beaucoup plus de mal à mettre les mains dedans.

      Au debut , je ne voulais pas parler d'OCS dans mon post mais ma news a été refusée à cause de cela :(

      Voila ce que je voulais dire lorsque je parlais de debug, c'était plus par rapport à mon expérience personnelle. Mais pour les utilisateurs confirmés, c'est sûr que ce n'est pas un argument.


      A bientot
      Vive le libre
      • [^] # Re: OCSInventory

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

        En entreprise, j'ai pendant longtemps utiliser le couple OCS/GLPI qui était parfait mais je trouvais cà un peu galère avec perl ou même pour debugguer l'application même si le site est bien documenté.


        Tu ne dirais pas ça uniquement parce que tu ne connais pas le langage Perl ?

        Par contre lorsque j'ai testé H-inventory il y a un installeur automatique donc bon à part certains modules pear à installer , j'ai trouvé cà plus rapidement abordable.


        Le projet Oreon a lui aussi sorti sa pléthore de modules PEAR pour sa version 1.3 (sans même parler de PHP5). Ceci souffre d'un manque total de réalité par rapport aux environnements de production. On n'a pas encore PHP5 sous debian (non, ne me parle même pas d'utiliser un backport) et la plupart des modules PEAR n'existent pas.
        Ensuite, les modules Perl pour le projet OCS existent déjà sous forme de paquets et j'aurais davantage confiance en certains modules Perl de CPAN qu'en la plupart des modules PEAR.

        Et pour les clients, pas de dépendances à installer.


        Avec des scripts écrits en bash, encore heureux mais en es-tu vraiment sûr ?
        Le script bash pour linux fait appel à un script Perl (d'ailleurs fourni avec l'archive) et celui-ci fait appel aux modules SOAP::Lite et MIME::Base64 (respectivement fournis sous Debian par les paquets libsoap-lite-perl et perl). On ne peut donc pas dire qu'il n'y a pas de dépendances. Et à propos, je n'ai pas vu l'utilisation de dmidecode (utilisé par les agents d'OCSInventory-NG), les informations fournies ne seraient-elles pas pertinentes ?

        Et même pour debugguer le serveur ce n'est que du php , par contre OCS le serveur de communication en perl j'ai eu beaucoup plus de mal à mettre les mains dedans.


        Ce n'est pas une question de langage : quand un projet est mal codé, il est mal codé. Le PHP n'apportera rien de plus que le Perl à la compréhension. Et des projets mal ficelés en PHP, j'en ai déjà vu plein...
        • [^] # Re: OCSInventory

          Posté par . Évalué à 1.

          Je ne sais pas si tu as bien compris que je parlais de mon expérience personnelle? breff
          En ce qui concerne ta première reflexion, je ne dis pas ca car je ne connais pas le langage perl. Je n'ai jamais eu de problème pour l'installation. Mais Les messages d'erreurs n'étaient pas vraiment explicites lors de l'utilisation( je parle des premières versions) . Ca c'est arrangé petit à petit quand les développeurs ont vu le nombre de questions sur le forum.
          Ils ont améliorées la partie d'installation et fait une bonne grosse FAQ.
          En ce qui concerne ta leçon sur Debian c'est ton avis, j'utilises pas mal de FreeBSD donc pas de problème pour php5.
          Apres c'est à l'administrateur de faire son choix, si il a que du Debian et qu'il veut rester sur php4 , il se tournera vers un autre projet comme OCS si il y trouve son compte.
          Concernant les dépendances des clients je le fais par ftp donc je n'ai effectivement aucune dépendance. Les modules perl dont tu fais allusion ne sont utilisés qu'avec d'autres méthodes d'upload.
          Quand tu dis que le langage n'a rien avoir je suis pas vraiment d'accord.
          Un choix technique sur une solution, je sais que je ne vais pas prendre une solution en python ( car je suis noob) même si elle est performante car après je n'arriverais pas à la maintenir ou debuggué si problème. Et comme nous sommes dans l'open source et que les développeurs font ce qu'ils peuvent et ne sont pas tout le temps réactifs , je ne vais pas laisser la solution en attendant le patch qui viendra 1 mois plus tard. Alors que si je connais le langage, on peut plus facilement y mettre le nez.
          Je pense qu'il faut tout de même garder un contrôle technique sur ce qu'on met en place...
  • # HelpDesk

    Posté par . Évalué à 3.

    Pourquoi OCS s'occuperait du helpdesk alors qu'il s'integre à merveille avec GLPI (qui lui s'occuppes du HelpDesk) ?
    • [^] # Re: HelpDesk

      Posté par . Évalué à 3.

      Bonjour,

      Ce n'est pas une critique pour OCS.
      Juste que H-inventory le fait par defaut sans avoir besoin d'installer un autre outil comme GLPI en plus.
      Je suis tout à fait d'accord avec ton point de vue.
      A+
      • [^] # Re: HelpDesk

        Posté par . Évalué à 2.

        Désolé, j'avais mal lu (vivement les vacances)

        Est ce qu'il y a des retours sur Hideploy ? la solution d'OCS est pas encore assez costaud a mon gôut.
        • [^] # Re: HelpDesk

          Posté par . Évalué à 2.

          Salut,

          Pour Hideploy, je l'ai testé sur mon parc de machines Windows XP.
          En fonction du type de poste , par exemple s' il n'est pas dans mon domaine , je l'installe en tant que service windows ( un script vbs est fourni pour ca).
          J'utilise les commutateurs des logiciels afin de faire les install silencieuses.
          Et pour Linux, je n'ai testé que sous mes serveurs debian, j'ai rajouté une tache cron. Je n'ai pas eu de soucis pour l'instant.

          A++
          • [^] # Re: HelpDesk

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

            Une question que je me pose et qui est aussi valable pour OCS :
            Comment sais il que le logiciel est déjà installé et en cas de mise à jour, comment cela se passe-t-il ?

            Je pense par exemple à Firefox qui a souvent des mises à jour. Suffit-il de mettre la nouvelle version de Firefox dans la file d'attente et hop, le système se débrouille soit pour l'installer, soit pour le mettre à jour.
            • [^] # Re: HelpDesk

              Posté par . Évalué à 1.

              Pour Hideploy, il scanne la base de registres car il faut spécifier le nom du logiciel tel qu'il apparait dans AJout Suppressions de Programmes.
              Pour firefox je ne l'ai pas utilisé car il se met à jour tout seul.
              • [^] # Re: HelpDesk

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

                Je prenais Firefox comme exemple mais cela pourrait être un autre logiciel. En gros, comment ca tient dans le temps ces mises à jour ?
        • [^] # Re: HelpDesk

          Posté par . Évalué à 2.

          la solution d'OCS est pas encore assez costaud a mon gôut.


          A quel niveau, tu peux développer un peu ?
  • # Test h-inventory

    Posté par . Évalué à 2.

    Salut,
    effectivement l'installation est plus simple et il y a des choses intéressantes dans ce projet. Pour une version Beta c'est très prometteur. Je vais attendre la version stable et je me poserai la question d'une migration de OCS/GLPI vers ce projet.
    Merci pour l'info
    Ca ne vaut pas encore le couple OCS/GLPI mais c'est vraiment sympa et
    c'est très simple à mettre en place.
    PS: Ce sont des francais qui gèrent ca comme OCS.
    Ils ont l'air super réactifs et à l'écoute des utilisateurs.
    A+
    • [^] # Re: Test h-inventory

      Posté par . Évalué à 2.

      news par un compte créé le 24
      ton commentaire d'un compte créé le 25

      serais-je parano?
    • [^] # Re: Test h-inventory

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

      Comme si les français qui s'occupent d'OCS et de GLPI n'étaient pas à l'écoute des utilisateurs...
      • [^] # Re: Test h-inventory

        Posté par . Évalué à 1.

        Si le forum de OCS est très actif , en tout cas dès que je posais une question le fondateur de OCS Mr Liroulet prenant toujours de son temps et même par email....
        Et GLPI il y a une bonne ambiance ce sont des jeunes vus au salon Linux pour l'occasion :))

Suivre le flux des commentaires

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