Reflexion sur l'usage de l'import des logiciels.

jm.cierniewski · 2006-03-08 11:17:18

Bonjours.
Quelques réflexions constructives ( je l'espére) sur l'inventaire des logiciels.

Après test et utilisation des différentes possibilités d'utilisation de la partie inventaire logiciel je fais un constat.

Le systéme de dictionnaire est une bonne idée, mais n'est a mon avis pas vraiement exploitable tel quel .

Je m'explique.

Comment cela fonctionne aujourd'hui.

Soit on met tout les logiciels dans "unchanged" auquel cas on a dans glpi tout les logiciels, patchs et version. Ce qui fait pas mal d'enregistrement.

Soit on gére des catégories, auquel cas, seul les noms des catégories sont importés dans glpi.

Donc concrétement,

Problématique :

Je souhaite avoir une vue dégagée des logiciels "inutiles" dans l'onglet inventaire logiciel. par exemple les patchs microsoft. je peux donc au niveau d'ocs mettre les patchs microsoft dans une rubrique patch. J'ai donc au niveau de glpi une ligne avec marqué patch microsoft.

Pour une raison x, un jours, j'ai besoin de savoir si les machines ont le patchs n 123423xxx ,,,, comment dois je faire ?
C'est tout bonnement impossible facilement car on a perdu l'information entre ocs et glpi.

La seule solution, aller sur ocs, enlever tout les patchs de la rubrique "patch" , puis forcer un import.Une fois l'information voulue retrouvée, il faut pour retourner à la situation initiale, selectionner dans l'inventaire tout les patchs, les supprimer, les purger, puis aller dans ocs, recréer la catégorie (détruite puisque vidée), redéplacer les patchs dans la rubrique et resynchroniser...
c'est vraiement trop lourd...

Et pour cet exemple je ne parle méme pas de l'inventaire logiciel des machines unix. Car la, vu le nombres de logiciel remontés, on a le choix entre créer une rubrique "logiciels linux" et on met tout dedans, soit on accepte d'avoir plusieurs milliers d'enregistrement dans glpi.
Et comme pour les patchs, si on choisit la solution "catégorie dictionnaire" , on ne pourra plus avoir acces le jour j, au contenu de cette fameuse catégorie.

Ayant un parc mixte linux/unix microsoft, j'en suis venu a décidé de ne pas utiliser les agents linux. ou alors a modifier l'agent pour qu'il ne fasse pas de remonté de logiciel.

Quelques voies de réflexion pour essayer d'améliorer ces fonctionnalités.

1) trouver une solution pour que au niveau d'ocs, les agents microsoft et unix, tag quelque chose dans l'inventaire afin de pouvoir distinguer facilement les machines unix et microsoft
1 bis) Au niveau de la synchro glpi avoir deux configuration d'import, import des machines microsoft, et import des machines linux. cela permettrait par exemple d'importer les logiciels microsoft, et de ne pas importer les logiciels linux.

2) plus évolué et plus efficace a mon avis. Migrer la fonctionnalité de dictionnaire dans glpi.
On aurrai donc ocs qui ferai son boulot, a savoir inventorier les ordinateurs, et glpi le sien, a savoir trier et mettre en forme l'information. On pourrait donc imaginer avoir en affichage dans glpi au niveau de l'inventaire des logiciels un logiciel "patch" ( autrement dit les catégories de dictionnaire) et en cliquant sur ce logiciel patch, on arriverai dans une sous rubrique avec la liste de tout les patchs.
On aurrai donc l'ergonomie de l'utilisation de catégories, sans perte d'information.

Voila, fin de mes réflexions du matin.

MoYo · 2006-03-08 12:25:54

jm.cierniewski wrote:

Pour une raison x, un jours, j'ai besoin de savoir si les machines ont le patchs n 123423xxx ,,,, comment dois je faire ?
C'est tout bonnement impossible facilement car on a perdu l'information entre ocs et glpi.
La seule solution, aller sur ocs, enlever tout les patchs de la rubrique "patch" , puis forcer un import.Une fois l'information voulue retrouvée, il faut pour retourner à la situation initiale, selectionner dans l'inventaire tout les patchs, les supprimer, les purger, puis aller dans ocs, recréer la catégorie (détruite puisque vidée), redéplacer les patchs dans la rubrique et resynchroniser...
c'est vraiement trop lourd...

non la solution c'est changer de catégorie le patch désiré. Il sera reimporté automatiquement dans GLPI.

Pour le moment la modif du dico OCS ne declenche pas la mise à jour des checksums mais ca va venir et alors les machines seront marquées comme a resynchroniser.

jm.cierniewski · 2006-03-08 13:47:49

je n'avais pas vu cette solution.

toute fois, cela nécessite d'utiliser/ administrer les deux "logiciels"
il aurrait été plus hergonomique que "ocs" soit transparant d'utilisation. Le job d'ocs est de remonter de l'information, pas de la mettre en forme. Pour moi, la gestion du dictionnaire est "conceptuellement" du ressort de glpi et pas d'ocs...

MoYo · 2006-03-08 15:23:38

le but d'OCS c'est de faire de la remontée d'infos mais de leur cote s'il n'ont pas un tel système en place c'est leur soft est quasiement inutilisable pour faire de la recherche ou pour avoir une vue synthétique.

Après de longues discussions entre équipes (je pense les plus a même de réflechir la dessus) :
la gestion du dictionnaire est "conceptuellement" du ressort d'ocs et pas de glpi.

Il faut quand meme voir que GLPI et OCS peuvent tres bien être utilisé de manière complètement découplée.

jm.cierniewski · 2006-03-08 15:53:26

Très sincérement, ( y vont pas étre content chez ocs mais bon, j'assume) vu le peu d'ergonomie d'ocs, et vu le cout "nul" d'implémentation de glpi ( en temps et en pognon) je ne vois vraiement pas qui pourrait souhaiter utiliser ocs sans glpi..... Et ce n'est pas la fonctionnalité de dico qui va le rendre exploitable...
Je dit ça sans méchanceté, mais méme si ce n'est pas recommandé, j'utilise ocs /glpi en semie prod ( test grandeur nature quoi, en paralléle avec les process d'entreprise ) et il ne me viendrait mème pas a l'idée de gérer mon parc avec l'interface ocs. On ne peut rien faire avec leur interface, et au risque de vexé certains, ce serait une perte de temps de la part d'ocs d'essayer d'immiter GLPI. (d'un autre cotés, je n'aimerai vraiement pas devoir me passer d'ocs pour automatiser mes inventaires....)

je ne sais pas quels sont vos rapports avec l'équipe ocs, mais le mieux pour les deux solution serait de réellement fusionner. l'équipe ocs affinant le moteur d'inventaire, et glpi s'occupant de la mise en forme et de l'interface graphique...

Pour conclure et finir, vos deux produits sont totalement complémentaires et sauf a accepter une dépense d'énergie invraisemblable, l'avenir d'ocs est de devenir le moteur de glpi...

EmpereurZorg · 2006-03-08 17:43:35

jm.cierniewski wrote:

il ne me viendrait mème pas a l'idée de gérer mon parc avec l'interface ocs. On ne peut rien faire avec leur interface, et au risque de vexé certains, ce serait une perte de temps de la part d'ocs d'essayer d'immiter GLPI. (d'un autre cotés, je n'aimerai vraiement pas devoir me passer d'ocs pour automatiser mes inventaires....)

Je pense que ce n'est tout simplement pas dans leurs objectifs de faire un truc aussi "chiadé" que glpi : OCS peut devenir une très bonne base de données pour alimenter un logiciel de gestion de parc existant, sans le pourrir par des milliers de soft remontés grace au dico ou par des redondances de machines inutiles.

Effectivement quand on part de 0 à la recherche de la 8ème merveille du monde de la gestion de parc, OCS "ne sert à rien". On a des données propres, l'interface est de la vieille école (pas aussi inexploitable que ça, juste moins "fun"), mais pour de la gestion de parc c'est tout juste bon quand on a 10 PC à gérer...
GLPI a d'autres ambitions fonctionnelles, et "pourrait" très bien intégrer des données d'autres logiciels que OCS, pourquoi pas grace à des plugins.

je ne sais pas quels sont vos rapports avec l'équipe ocs, mais le mieux pour les deux solution serait de réellement fusionner. l'équipe ocs affinant le moteur d'inventaire, et glpi s'occupant de la mise en forme et de l'interface graphique...

Oui et non.
Que l'interface fusionne serait un gros plus indéniable pour les utilisateurs/administrateurs de glpi.
Par contre ceux qui ont interfacé OCS avec leur propre logiciel vont faire la tête.
De plus, les BdD doivent absolument être différente pour être "propres". Je préfère qu'un OCS s'occupe d'ingérer tout et de faire le tri pour avoir une base "saine et réactive" dans Glpi.

Pour conclure et finir, vos deux produits sont totalement complémentaires et sauf a accepter une dépense d'énergie invraisemblable, l'avenir d'ocs est de devenir le moteur de glpi...

L'avantage serait en terme de ressources : il vaut mieux un bon logiciel qui évolue vite plutôt que deux """petits""" qui évoluent chacun de leur côté, d'autant que l'OpenSource n'est pas pour rassurer les décideurs si l'une des équipe venait à faiblir...
Maitenant c'est le genre de décision qui n'appartient qu'à eux, peut-être que le succès de GLPI 0.65 et OCSNG les poussera en ce sens... mais c'est - j'imagine - très difficile pour un projet de se sentir aspirer par un autre...

a+
Anthony

Last edited by EmpereurZorg (2006-03-08 17:50:18)

jm.cierniewski · 2006-03-08 17:51:26

Bonne annalyse

niconet · 2006-03-09 00:09:23

moi je monte deux serveurs ocs

1 pour windows et 1 pour linux et j'incorpore cela dans mon glpi

je trouve que deux têtes bien pleines vaut mieux qu'une grosse vide !

jm.cierniewski · 2006-03-09 10:15:06

c'est une solution, quelque peut "bricolée". Il vaudrait mieu que le filtre entre type de machine ( linux /microsoft/mac ) se fasse au niveau des systémes ocs ou glpi...

serpent · 2006-03-09 21:49:00

Bonsoir à tous.
Petite réaction du soir à ce thread intéressant.

OcsNG, au delà d'un logiciel d'inventaire, est désormais une plateforme de communication XML entre les machines de vos parcs et un serveur central. Cette plateforme a été enrichie de quelques fonctionnalités, notamment la recherche de clés de registre, des fonctionnalités d'update auto rudimentaires, l'ipdiscover pour vous aider à identifier les machines non inventoriées, périphériques et autres.. et va encore être enrichie, notamment en matière de télédéploiement sécurisé via SSL, certificats et tutti quanti.

Son interface manque en ergonomie (cela sera corrigé dans la prochaine version), mais est volontairement sommaire. Ocs n'est pas un logiciel de gestion de parc. Il collecte des données brutes et les stocke. Il permet également de donner un accès visuel efficace à ces données(par le biais notamment des recherches multi-critères, qui permettront à terme d'affecter des comportements à des groupes choisis d'ordinateur, c'est déjà structurellement possible mais pas implémenté au niveau de l'interface) et de paramètrer le fonctionnement de son moteur. Il permet également de paramétrer facilement le comportement de millier de machines.

Pour répondre à EmpereurZorg, qui trouve ocs inadapté à un parc de plus de 10 machines, je tiens à préciser que certains systèmes en France et à l'étranger en comptent jusqu'à 70000. Les récents tests de charge ont montré qu'avec un serveur de production monoprocesseur "dans la norme", nous pouvions atteindre 3500 inventaires/h.

Mais il est vrai que ce n'est pas nos "informations administratives" qui vont permettre de les gèrer. Cette fonctionnalité, qui déborde légèrement notre périmètre, est là pour aider les admins (souvent de petites structures) qui n'ont que ocs.

Il est clair, dans tous les cas, que ocs ne peut être utilisé à des fins de gestion et ce n'est pas là son objectif.

Ocs est effectivement un bon moteur pour tout système de gestion de parc, dont fait partie GLPI. Nous ne pouvons envisager (du moins ce sont là nos vues aujourd'hui) la fusion avec un logiciel de gestion en particulier. Par contre, nous pouvons évoluer afin de mettre à disposition nos données, qui seront utilisées par une application tierce.

Pour cela, il existe aujourd'hui un système de suivi des effacements/doublons, un système de bitmap permettant de suivre l'évolution des machines (qui permet notamment, d'isoler les parties d'un inventaire et de dire si elles ont changé depuis la dernière synchro) et le dictionnaire.

Concernant le dictionnaire, la meilleure stratégie me semble un système de white list: Tout mettre dans IGNORED et ne choisir que ce que l'on veut tracer grâce à la recherche de soft. Les patch windows par exemple (recherche sur KB*) peuvent être affectés à unchanged car on veut les voir tel quel dans GLPI.Parcontre le logiciel "jeu de go", retrouvé plusieurs fois dans la base sous les "pseudonymes" jeudego, jeu_de_go, JDG etc.., sera mis dans une catégorie "JeuDeGo", et là pas de redondances ni de pollution des dropdown. Ni non plus avec les paquets linux qui sont dans IGNORED eux aussi. Si vous voulez en tracer certains, et sachant que d'une distribution à une autre, les noms de paquet vont changer, là aussi catégorie (ou UNCHANGED). Un petit tour de temps en temps dans le dictionnaire et vous verrez s'enrichir (éventuellement) la catégorie NEW. (logiciels pas encore présents au moment ou vous avez managé le dico).

Je rappelle la présence de la case "TOUT" sélectionner qui vous permet d'envoyer de grandes quantités de logiciels à la destination voulue.

Attention toutefois aux maladresses liées aux mauvaises recherches (office tous court ne signifie ni openoffice, ni open office ni ooo etc...). Cet avertissement concerne également les recherches multicritères sur la base desquelles vous êtes susceptibles d'émettre des données statistiques à l'attention de votre hiérarchie... Se planter sur 3000 licences ca craint .. :-)

Mais si vous avez un doute sur une machine rien ne vous empeche de visualiser son "format brut" sur ocs.

Ce n'est qu'un début. Peut-etre pourrions nous envisager d'intègrer au moteur un web service à base de soap par exemple, pour offrir des données de manière abstraite et normalisée ? Pour l'instant, telle n'est pas notre priorité. L'accès à notre base compte tenu des éléments précités suffit.

Pour finir, je tiens à repréciser la notion importante de périmètre. Certaines fonctionnalités (par exemple consigner l'historique des modifications, le formattage des données..) fleurtent avec les frontières, et nous devons prendre des décisions. Mais il n'y a que les imbéciles qui ne changent pas d'avis, et nous restons "open" à toutes les opinions constructives comme les votres. Rien n'est figé, sauf ma soupe, qui a définitivement refroidi.... :-)

Bonne soirée.

Pascal.

EmpereurZorg · 2006-03-10 00:25:20

serpent wrote:

Pour répondre à EmpereurZorg, qui trouve ocs inadapté à un parc de plus de 10 machines,

Oulala, je parlais d'OCS en tant que système de gestion de parc "complet" pour remettre un contexte à la phrase. J'en suis à 430 PC sur un bi-pro 400, et OCS est très loin d'être à la ramasse !
Donc, en fait nous somme bien d'accord, OCS n'est pas un gestionnaire de parc, et c'est ce que j'écrivrais en disant qu'il pourrait faire "office de" pour gérer 10 PC...

Pour le dico, c'est très pratique, mais je pensais qu'on pourrait également "sous-catégoriser" les logiciels, ex. :
+ "Bureautique"
+ "OpenOffice"
+ "Microsoft Office"
+ "Office 2000"
- "Microsoft Office 2000 SR1 CD1"
- "Microsoft Office Premium"
+ "Office 97"
+ "Patchs"
+ "Correctifs Windows"
...
Mais bon, c'est déjà excellent de pouvoir filtrer tout ça dans GLPI !

Puisque j'en tiens un (:D), est-il prévu des interogation snmp dans OCS (win & lin), pour éventuellement remonter automatiquement les équipements réseau (routeurs, imprimantes, ...) ?

En tout cas, bienvenue, et un grand bravo !

Last edited by EmpereurZorg (2006-03-10 00:42:06)

serpent · 2006-03-10 00:56:33

Les résultats ramenés par l'ipdiscover sont pour l'instant utilisés de manière simple.
Il n'est pas prévu d'interro snmp, mais rien ne vous empeche d'en faire. Les interfaces découvertes sont mises à disposition.On peut en faire ce que l'on veut, on oubliant pas toutefois qu'il s'agit d'un inventaire d'adresses MAC à un instant T, qui avait à cet instant telle IP. Ainsi, il ne faut pas oublier l'éventualité d'une adresse IP reprise par une autre interface. Toute interro se basant sur l'ip (notamment le nom à l'affichage) se fera sur cette machine là, pas celle enregistrée en base.
Cela explique également que vous puissiez avoir dans certains rapports pls adresses ip identiques.

Pour le dico, il n'est pas prévu pour l'instant de sous catégories, mais gageons que le système va évoluer.

En espérant que ca réponde à la question. Merci pour les encouragements et à bientôt.

Pascal.

jm.cierniewski · 2006-03-10 11:04:52

Très bonne réponse monsieur serpent.
j'avais cru comprendre que vos deux projets allaient fusionner alors, qu'à la lumière de vos explication, il est claire que vous allez plustot collaborer..
Ce qui explique mon incompréhension du moment quand à vos deux développements parralléles.
Bonne continuation donc.

ps: serait il possible d'avoir la possibiliter d'afficher plus de 100 éléments dans les pages du serveurs ocs ?
ainsi que d'avoir un trie "par ordre alphabétique" qui s'étende sur plusieurs pages ?

Merci

MoYo · 2006-03-10 11:34:34

Nous n'avons jamais parlé de fusion des 2 projets où que ce soit.
Toutes les discussions que les 2 equipes ont pu avoir n'ont jamais eut cette conclusion là.

EmpereurZorg · 2006-03-10 11:35:17

jm.cierniewski wrote:

ainsi que d'avoir un trie "par ordre alphabétique" qui s'étende sur plusieurs pages ?
Merci

Pour ça je pense qu'il s'agit d'un bug d'interface (on parle bien du dico ?)
Pour trier sur plusiers page par ordre alpha, il suffit d'ajouter "&order=2" à la fin de l'adresse, ex. :

http://server/ocsreports/index.php?multi=14&cat=NEW&search=&rg=200&order=2

Affiche à partir de la machine 200 par ordre alpha.

jm.cierniewski · 2006-03-10 12:00:06

oui oui on parlait bien du dico. Merci pour l'info

JMD · 2006-03-10 19:12:15

j'avais cru comprendre que vos deux projets allaient fusionner

eheh vous l'avez peut etre tellement souhaité que ça a fini par devenir pour vous une certitude

Mais non.

On collabore avec l'équipe d'ocsng avec laquelle nous entretenons d'excellente relation et nous souhaitons que cela apporte aux deux projets.

Oliver · 2006-03-29 15:08:31

Bonjour,

Thread très intéressant. Merci pour toutes ces précisions.

J'ai une toute petite question concernant l'importation de données triées via le dictionnaire d'OCSInventory-NG : quand on place les logiciels dans une catégorie, toutes les infos sous-jacentes sont perdues dans GLPI. Est-ce parque elles ne sont plus aisément importables depuis OCSInventory-NG sans modifier le code, ou est-ce par choix?

Merci.

jm.cierniewski · 2006-03-29 15:13:48

Salut oliver,,,,

Je vois que vous n'etes plus dubitatif du tout, mais amateur maintenant

Forum GLPI-Project

Announcement

#1 2006-03-08 11:17:18

Reflexion sur l'usage de l'import des logiciels.

#2 2006-03-08 12:25:54

Re: Reflexion sur l'usage de l'import des logiciels.

#3 2006-03-08 13:47:49

Re: Reflexion sur l'usage de l'import des logiciels.

#4 2006-03-08 15:23:38

Re: Reflexion sur l'usage de l'import des logiciels.

#5 2006-03-08 15:53:26

Re: Reflexion sur l'usage de l'import des logiciels.

#6 2006-03-08 17:43:35

Re: Reflexion sur l'usage de l'import des logiciels.

#7 2006-03-08 17:51:26

Re: Reflexion sur l'usage de l'import des logiciels.

#8 2006-03-09 00:09:23

Re: Reflexion sur l'usage de l'import des logiciels.

#9 2006-03-09 10:15:06

Re: Reflexion sur l'usage de l'import des logiciels.

#10 2006-03-09 21:49:00

Re: Reflexion sur l'usage de l'import des logiciels.

#11 2006-03-10 00:25:20

Re: Reflexion sur l'usage de l'import des logiciels.

#12 2006-03-10 00:56:33

Re: Reflexion sur l'usage de l'import des logiciels.

#13 2006-03-10 11:04:52

Re: Reflexion sur l'usage de l'import des logiciels.

#14 2006-03-10 11:34:34

Re: Reflexion sur l'usage de l'import des logiciels.

#15 2006-03-10 11:35:17

Re: Reflexion sur l'usage de l'import des logiciels.

#16 2006-03-10 12:00:06

Re: Reflexion sur l'usage de l'import des logiciels.

#17 2006-03-10 19:12:15

Re: Reflexion sur l'usage de l'import des logiciels.

#18 2006-03-29 15:08:31

Re: Reflexion sur l'usage de l'import des logiciels.

#19 2006-03-29 15:13:48

Re: Reflexion sur l'usage de l'import des logiciels.

Board footer