You are not logged in.
Pages: 1
Bonjour à tous.
Nous utilisons GLPI en Version 0.78.5 et OCS en version 1.02RC.
La synchronisation entre les deux se fait via le plugin MASSIMPORT.
Pour notre paramétrage au niveau OCS nous supposions que le numéro de série (NS) était unique.
Du coup notre infrastructure était basé sur cette supposition. 1 machine = 1 numéro de série.
Nous venons de constater (chez LENOVO) qu'ils pouvaient avoir le même numéro de série pour plusieurs machines.
Vous pouvez vérifier par vous même. Pour retrouver une machine chez eux il faut donner le couple NS + Numéro de Modèle (NM) : http://support.lenovo.com/en_GB/product … ault.page?
Du coup dans OCS nous pouvons identifier une machine unique par le couple NS + NM.
Mais lors de la synchronisation... Que va-t-il se passer ?
Comment feriez-vous ?
Nous avons activé la liaison automatique entre OCS et GLPI sur le NS.
Comment le système va-t-il réagir si je met NS+NM dans OCS et que je laisse uniquement NS dans GLPI ?
Comment le système va-t-il réagir si je met NS+NM dans OCS et que je mets NS+MAC dans GLPI ?
Le choix du Nom ou de l'IP ne me semble pas convenir : Ces valeurs sont trop "volatiles"
La caractéristique "Modèle" n'est pas proposée afin d'identifier une machine (En tout cas en V0.78.5). Est-ce toujours le cas en v0.80 ?
Voilà des petites questions existentielles, merci d'avance pour votre expérience...
Test : Red Hat 5.1 / Apache 2.2 / MySQL 5.0.22 / PHP 5.1.6 / Perl 5.8.8 / GLPI 0.83.3 / OCS Server 2.0.4
Prod : Red Hat 5.1 / Apache 2.2 / MySQL 5.0.22 / PHP 5.1.6 / Perl 5.8.8 / GLPI 0.83.3 / OCS Serveur 2.0.4 / DataInjection v2.0.2
Offline
En 0.80 ça passe par le moteur de règles, mais il n'y a pas le modèle.
Offline
Nous avons découvert ce problème il y a longtemps. C'est pour cela qu'on a ajouté le "modèle" dans OCS.
Le cas ou 2 machines on le même N° de série, dans la même entités me semble quand même assez rare.
Chez nous, la liaison se fait sur N° de série + status = disponible.
Comme 2 machines avec le même numéro de série sont de 2 modèles différents, elles correspondront a 2 années d'achat différentes (donc, 1 déjà en production et l'autre en disponible).
De toute manière, même sans le statut
- première machine
- inventaire => liaison ok
- seconde machine (sans aucun doute, plus tard, puisque nouveau modèle)
- inventaire => liaison ok, puisque la machine précédente est ignorée (déjà liée).
Donc le risque me semble très minime.
J'ai quand même créé un ticket pour ne pas oublier ce truc : https://forge.indepnet.net/issues/3099
++
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Attention : ajouter le critère sur le modèle me semble quand même risqué.
Lors de la saisie initiale (BL) on risque d'avoir un modèle qui ne sera pas "exactement' ce qui va remonter par OCS.
Et dans ce cas, la liaison ne se fera pas.
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Merci pour vos réponses. Elles entrainent cependant quelques Questions/Remarques/Etc.
En 0.80 ça passe par le moteur de règles, mais il n'y a pas le modèle.
Donc si je comprend bien plus de plugin massimport en version 0.80 ?
Le cas ou 2 machines on le même N° de série, dans la même entités me semble quand même assez rare.
Pour la rareté, c'est clair sur un parc de 40000 machines nous avons environ 60 numéros de série concernés. Le truc c'est que cela touche plusieurs organismes dont un tout particulièrement (60/600) du coup pour cet organisme le problème est criant.
En ce qui concerne les entités, oui les machines sont dans deux entités différentes sauf que :
Dans OCS : Lors de son premier inventaire la machine 'A' s'inventorie avec le numéro de série 'A' (Qui n'est pas sur liste noire). Elle remonte bien lors de la synchronisation dans la bonne entité (grâce à son TAG). Lors du premier inventaire de la machine 'B' avec le numéro de série 'A' (comme le paramètre est de faire l'unicité sur uniquement le numéro de série) OCS va mettre à jour l'enregistrement sauf pour le TAG. Du coup les modifications seront reportées sur l'enregistrement de l'entité 'A' alors que cela concerne la machine de l'entité 'B' (Bon sang j'espère que je suis clair...).
Chez nous, la liaison se fait sur N° de série + status = disponible.
Chez nous impossible d'utiliser le status.
De toute manière, même sans le statut
- première machine
- inventaire => liaison ok
- seconde machine (sans aucun doute, plus tard, puisque nouveau modèle)
- inventaire => liaison ok, puisque la machine précédente est ignorée (déjà liée).
Avec dans OCS un paramètre qui dit qu'un enregistrement c'est un NS + NM je vais bien avoir la création de deux enregistrements (puisque les modèles sont différents) et si je comprends bien ce que vous venez d'écrire (en laissant le paramètre GLPI pour la liaison avec OCS sur uniquement le NS) je vais bien avoir création de deux enregistrements GLPI (et donc logiquement chacun dans son entité car les enregistrements OCS ont des TAG différents.) ?
Lors de la saisie initiale (BL) on risque d'avoir un modèle qui ne sera pas "exactement' ce qui va remonter par OCS.
Et dans ce cas, la liaison ne se fera pas.
Exact. Mais c'est le même problème si le NS n'est pas correct (soit dans OCS soit dans le BL).
Du coup nous préconiserions l'inventaire d'une machine via OCS avant l'injection d'un BL.
Cordialement,
Test : Red Hat 5.1 / Apache 2.2 / MySQL 5.0.22 / PHP 5.1.6 / Perl 5.8.8 / GLPI 0.83.3 / OCS Server 2.0.4
Prod : Red Hat 5.1 / Apache 2.2 / MySQL 5.0.22 / PHP 5.1.6 / Perl 5.8.8 / GLPI 0.83.3 / OCS Serveur 2.0.4 / DataInjection v2.0.2
Offline
Si vous lancez un inventaire OCS avant d'injecter le BL il n'y aura pas de problème.
Donc, dans OCS, il faut bien paramétrer NS + modèle.
Le critère modèle va être ajouté dans GLPI pour la version 0.80.3 (très très très bientot)
D'ailleurs si vous avez une plate-forme en 0.80, ce serait sympa de nous tester ce nouveau critère
Concernant le plugin massocsimport, il est toujours utile en 0.80
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Le fabricant et le model seront disponibles dans les critères de liaison en version 0.80.3. C'est prêt (codé).
@cnedi35 : si vous pouviez tester cette fonctionnalité sur votre plate-forme de test, à partir du cliché quotidien, et si possible rapidement (la sortie de la 0.80.3 est imminente)
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Merci pour les informations. Voilà une raison de plus d'accélérer nos travaux pour passer en 0.80.3.
Nous sommes actuellement sur l'intégration du Helpdesk (en version 0.78.5).
Nous souhaiterions aussi faire évoluer notre plateforme de production OCS (serveur et client).
Mais dès que nous aurons rattrapé notre retard et que nous arriverons à caler notre rythme sur le votre, nous pourrons tester sans problème.
Malheureusement, je crains que cela ne nous prenne un peu trop de temps par rapport à la sortie de la version 0.80.3.
Très cordialement,
Test : Red Hat 5.1 / Apache 2.2 / MySQL 5.0.22 / PHP 5.1.6 / Perl 5.8.8 / GLPI 0.83.3 / OCS Server 2.0.4
Prod : Red Hat 5.1 / Apache 2.2 / MySQL 5.0.22 / PHP 5.1.6 / Perl 5.8.8 / GLPI 0.83.3 / OCS Serveur 2.0.4 / DataInjection v2.0.2
Offline
Caler votre rythme sur le notre, ça va être difficile vu que nous ne mettrons pas en place la 0.80.3.
Il est prévu de passer de la 0.78.5 à la 0.83
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Pages: 1