Remontée automatique d'inventaire

Manu · 2004-12-17 14:56:05

Bonjour,
Je viens de découvrir, GLPI et suis très impressionné par sa richesse fonctionnelle.

Est-il prévu de faire une remontée automatisée d'inventaire comme OCS Inventory par exemple?
Si oui quel est le délais estimé pour cette fonctionnalité?
Ou bien serait-il envisageable d'utiliser un système externe d'inventaire et faire un lien?

En résumé votre système est très bon et complémente parfaitement OCS (à mon humble avis).
Si ceci était faisable j'envisagerai sérieusement d'utiliser (en sus) votre système sur un périmètre très large: 15 à 20000 stations au moins.

Manu · 2004-12-17 15:22:51

Précision:
Pour les stations linux, je vais utiliser un bach avec DMIDECODE bientot finalisé;
donc:
1 Un agent est installé en local sur chaque machie (Zindo et linux)
2 des fichiers csv sont générés en local et pourssés en FTP sur un serveur central
3 Le données sont entrées par un script dans une base MySql (OCS)

Manu

baaz · 2004-12-17 16:58:57

On pense pouvoir implémenter ça d'ici deux version (donc surement la 0.6) en tout cas ce ne sera pas fait sur la 0.5 vu que la roadmap est déjà faite.

Pour l'instant nous avions retenu LIAM http://cri.univ-mlv.fr/liam/ qui nous semblait le plus simple à integrer dans notre architecture et qui présente l'avantage d'être un projet francophone.

Le principe de Liam est a peu de choses pret le meme que celui d'OCS inventory, sauf qu'au lieu d'envoyer le tout en ftp il fait ça via smtp sur un compte mail que le serveur central viendra parser au fur et a mesure.

Ensuite ce n'est pas un choix définitif, nous sommes toujours dans la phase de reflexion à ce sujet donc toutes les remarques, suggestions et idées sont les bienvenues.

Manu · 2004-12-17 19:08:26

Merci de votre réponse.
Nous avons étudié et comparé le fonctionnement de Liam avec celui de OCS (en ce qui concerne l'agent).

Notre avis:
Liam est innovant. Cependant il nécessite Perl avec Qq extensions (pricipe PAR) voire le rapport de stage. Nous ne sommes pas d'accord avec son principe de fonctionnement (http + smtp + pop). En effet il semble très curieux d'utiliser un protocole de messagerie pour effectuer du transfert de fichiers. De plus la lecture des fichiers à l'arrivée s'en trouve plus compliquée (nécessité d'une messagerie avec un client qui analyse les pièces jointes et un serveur WEB pour les clients....). C'est bien compliqué tout ça...

Alors qu'un binaire faisant la même chose que DMIDECODE et une analyse de la config et des packages sur Zindo comme sur Linux doublé d'un transfert en FTP est une solution très légère et presque facile à mettre en oeuvre (pas de messagerie pas de serveur web pas de client spécifique).
Cela fonctionne déjà chez nous avec l'agent de OCS installé en local (pré-production).
Nous écrivons un binaire en C pour la partie linux.
Le travail avance vite et nous en ferons profité la communauté normalement en janvier.
un module d'import des données (simples fichiers csv) est très simple à coder et peut fonctionner sur GLPI (nous donner le schema de la base) comme sur OCS.
Si notre travail vous convient nous vous en ferons profiter avec plaisir et ce sera un juste retour car votre interface PHP est vraiment très bien pensée.

Manu

Manu · 2004-12-20 10:05:17

Petit PB avec l'utilisation du forum...
http://glpi.indepnet.org/forum/viewtopi … id=880#880

MoYo · 2004-12-20 11:54:35

Votre solution est en effet très intéressante et les petits problèmes dont vous nous faites part sur Liam sont aussi ceux qui nous font encore hésiter pour l'adoption des agents Liam.
Ou en tout cas l'adoption de Liam tel quel... Nous avions pensé à quelques modifications pour l'utiliser plus facilement.

Nous sommes vraiment très intéressés par votre solution et seront très heureux de tester son intégration dans GLPI. Pour ma part je n'y vois qu'un seul problème mais c'est du chipotage : le transfert via FTP qui n'est pas sécurisé

Manu · 2004-12-20 14:58:22

Votre intéret pour ce principe nous conforte dans l'idée qu'un peu de bon sens et d'échange d'idées permet souvent de gagner du temps...
Je ne suis pas trop ému par le coté sécurité, mais si cela était nécessaire une réponse (simple) peut être SFTP (http://www.chiark.greenend.org.uk/~sgta … nload.html)
Je fais le point dès qu'une version (pré prod) est disponible.
Où puisje trouver le schéma de votre base?

Last edited by Manu (2004-12-20 14:59:56)

JMD · 2004-12-20 17:56:47

Le schéma de la base de données ne va pas vous servir à grand chose car il va changer (pas mal) pour la version 0.5. Donc, vous risqueriez de bosser sur une base déjà obsolète.

Pour précision, ce que nous cherchons c'est un système qui apporte les données à GLPi sous un format de données exploitable : csv, XML etc...

Aprés, le parsage de ces fichiers pour importer les données dans GLPI, on peut s'en charger.

Votre solution semble trés intéressante mais j'ai quelques interrogations :

1) Sur la structure des fichiers générés. J'aimerai bien voir la tête qu'ils ont.

2) Sur les paramêtres passés aux agents (ftp). Il sont passés à l'agent au moment de l'exécution ou sont ils codés en dur ?

3) Sur le serveur où ils sont récupérés : OCS semble généré un repertoire par partie d'un micro et y reçoit le fichier csv correspondant pour chaque machine. C'est pas un peu lourd ça ?
Cette contrainte est codée en dur dans l'agent ? ou est-ce passé en paramêtre ?

4) Comment envisagez vous la ventilation des agents sur le parc ?

Manu · 2004-12-21 11:35:17

1) La structure des fichiers CVS est sur le lien suivant:
http://ocsinventory.sourceforge.net/fr/csv_files.php

2)Les paramètres de l'agent (ftp) sont à limage du code de « OCSinventory.exe » qui écrit en dur sur le partage ou en local dans une suite de dossiers un fichier csv (Access, Bios, etc). Chaque fichier dans ces dossiers porte le (même nom) qui est celui de la machine. Nous savons que ce n'est pas le plus efficace donc nous sommes en train de repackager cet agent sans en modifier sont code original afin d'utiliser un identifiant unique. Mais cela a le mérite de fonctionner correctement. En fait le nom du fichier csv n'a pas d'importance.
Le seul vrai paramètre que nous passons est le nom (ou l'allias) du serveur Ftp.

3)Le serveur récupère ces fichiers dans une arborescence identique. Un utilitaire examine ces dossiers et fait l'import dans la base dont le schéma est sur le lien suivant:
http://www.thompsonic.com/ocsrep/ocsinv-3.pdf
En regardant le schéma on comprend ce choix de plusieurs dossiers (même si on n'est pas d'accord). L'outil « Imortcsv.exe » d'OCS utilise cette structure pour alimenter la base. C'est pourquoi nous l'utilisons aussi (par facilité). Comme ces fichiers sont d'abord générés en local sur la machine nous pouvons imaginer toute forme de transformation avant le transfert en cas de besoin.
4)Comme notre périmètre est très large nous avançons dans plusieurs directions simultanées:
a/ Un agent, installé une fois pour toutes, nécessitant un setup sur la machine (avec éventuellement une possibilité d'auto-mise à jour).
b/ Un binaire qui embarque le nécessaire à l'inventaire permettant de réaliser un inventaire des machines non connectées au réseau avec export sur disquette ou autre et éventuellement utilisable en script de connexion. Mais ce dernier point nécessite une grosse adaptation qui est en cours. De plus l'idée du script peut s'avérer désastreuse (pour le réseau) sur un parc de très grande taille.
c/ Un binaire Linux faisant ma même chose (c'est ce point que nous maîtrisons de A à Z).

Pour finir, notre travail sur l'agent (zindo) reste une adaptation. Ce choix est délibéré pour rester compatible autant que possible avec le produit de base.
Pour info:
Pour des raisons de compatibilité et de simplicité, nous avons volontairement laisser de coté la possibilité de l'agent d'écrire directement les données dans la base de données (MDAC).

JMD · 2004-12-21 14:09:03

Merci pour vous réponses.

1) J'aurai pu chercher un peu, désolé.

2) Un identifiant unique généré à partir de quoi ?

3) Oui le morcellement des fiichiers même s'il s'explique me semble pas forcément optimal et surtout un peu lourd. Néanmoins, il s'agit d'un détail et si comme vous le dites, on peut effectuer une éventuelle transformation avant de pousser les fichiers sur le serveur : tout va bien.

4) Les pistes que vous explorées semblent trés pertinentes et ont l'avantage de balayer la majorité des cas potentiels.

Pour ce qui est de l'adaptation de l'agent zindo d'OCS, je crois que c'est la voix la plus sage. Ne pas réinventer la roue est une ligne qui permet d'économiser beaucoup d'énergie.

Enfin concernant, votre choix de ne pas écrire directement dans la bdd, on ne peut que s'en féliciter puisque cela le rend de fait utilisable (avec un script d'import) avec GLPI.

Enfin et il s'agit simplement de curiosité, vous représentez une structure ? ou s'agit-il d'une contribution personnelle ?

Si vous ne souhaitez pas l'indiquer dans le forum, un simple message privé/mail me suffira mais il est vrai que j'aime bien savoir un peu à qui j'ai à faire

Manu · 2004-12-21 15:00:46

R:
2/ host + date à la seconde Ex: (host-2004-12-21-12-01-58.csv)
ou bien simplement (Adresse Mac.csv). Mais toute autre solution est viable.
Je pense qu'il est raisonnable de réécrire l'utilitaire d'importation...

La suite en privé.

benissam · 2004-12-26 20:05:24

votre discution est tres interessante;
je recherche également un moyen de remonter automatiquement les données ds mysql;
mais je connais pas trop OCS inventory, ou puis je trouver cet outil afin de le tester.
pour ma part j'utilisais ds mon ancien boulot pam3 , très complet et très cher.
le moteur de scan est efficace, génère un fichier texte et à l'aide d'un script en perl on alimente la base;
mais sous license jene peut l'utiliser aujourd'huit;

JMD · 2004-12-27 01:13:35

Pour trouver OCS inventory il suffit de tapper "OCS inventory" sur votre moteur de rechercher préféré

Forum GLPI-Project

Announcement

#1 2004-12-17 14:56:05

Remontée automatique d'inventaire

#2 2004-12-17 15:22:51

Re: Remontée automatique d'inventaire

#3 2004-12-17 16:58:57

Re: Remontée automatique d'inventaire

#4 2004-12-17 19:08:26

Re: Remontée automatique d'inventaire

#5 2004-12-20 10:05:17

Re: Remontée automatique d'inventaire

#6 2004-12-20 11:54:35

Re: Remontée automatique d'inventaire

#7 2004-12-20 14:58:22

Re: Remontée automatique d'inventaire

#8 2004-12-20 17:56:47

Re: Remontée automatique d'inventaire

#9 2004-12-21 11:35:17

Re: Remontée automatique d'inventaire

#10 2004-12-21 14:09:03

Re: Remontée automatique d'inventaire

#11 2004-12-21 15:00:46

Re: Remontée automatique d'inventaire

#12 2004-12-26 20:05:24

Re: Remontée automatique d'inventaire

#13 2004-12-27 01:13:35

Re: Remontée automatique d'inventaire

Board footer