You are not logged in.
Environnement Windows
GLPI : 0.78.5
glpi-massocsimport-1.4.2
Je fonctionne en multi entités : en gros chaque site correspond à une entité.
Le critère de liaison est Nom de machine + Numéro de série
Jusqu'à présent je faisais la synchro manuellement en faisant d'abord une liaison des ordinateurs existants avant d'importer de nouveaux ordinateurs. J'ai défini des règles basées sur l'adresse IP pour affecter les PC dans la bonne entité.
Depuis que j'ai mis en place le script de synchro ocs, je constate des doublons sur des portables que je retrouve dans plusieurs entités. Cela semble lié au fait que l'ordinateur change d'ID OCS lorsqu'il passe du réseau filaire au réseau WIFI lorsqu'il change de site. Du coup à la prochaine synchro, le script considère qu'il s'agit d'un nouveau PC et comme il n'existe pas sur le site de passage où s'est connecté l'utilisateur, la règle d'import crée un nouveau PC dans l'entité correspondante.
Je n'avais pas ce problème lorsque je faisais d'abord la liaison manuel des ordinateurs, car apparement dans ce cas le lien est préservé même en cas de changement d'ID et de site.
Quelle est la solution ?
Merci
Offline
Personne pour me répondre ?
Suis-je le seul à constater des changement intempestifs d'ID OCS ?
Offline
bonjour,
est-ce qu'il y a des doublons au niveau OCS ?
quelles sont les règles d'affectation d'ordinateurs à des entités que vous avez mises en place ?
Offline
J'ai une règle par entité du style
- Si adresse commence par 192.168.1. alors entité = entité1
- Si adresse commence par 192.168.2. alors entité = entité2
...
Je problème n'est pas dans les règles mais dans le fait que des PC changent d'ID OCS de façon intempestive. S'ils restent sur un même site, la liaison se fait sur le PC existant et on voit bien dans l'historique des changements d'ID OCS.
Par contre si le PC s'est connecté sur un autre site ça génère un doublon.
Comment se fait-il que les portables changent régulièrement d'ID ????
S'ils n'en changeaient pas, la syncho OCS se ferait sur l'ID sans repasser par les règles. Non ?
Offline
Ci-dessous l'historique d'un portable pris au hasard :
Volume suppression d'un élément : Volume (Donn)
192999 18/11/2011 10:29 Volume suppression d'un élément : Volume (Syst)
192996 18/11/2011 10:29 L'ordinateur a changé d'ID OCSNG : "8665" --> : "9551"
186109 17/11/2011 05:00 Volume suppression d'un élément : Volume (Donn)
186108 17/11/2011 05:00 Volume suppression d'un élément : Volume (Syst)
186107 17/11/2011 05:00 Volume ajout d'un élément : Volume (Donn)
186106 17/11/2011 05:00 Volume ajout d'un élément : Volume (Syst)
186105 17/11/2011 05:00 Carte réseau Suppression d'un composant : "Pilote de serveur d''acc"
186104 17/11/2011 05:00 Carte réseau Suppression d'un composant : "Carte Mini de r"
186102 17/11/2011 05:00 Carte réseau Ajout d'un composant : "Pilote de serveur d''acc"
186100 17/11/2011 05:00 Carte réseau Ajout d'un composant : "Carte Mini de r"
178007 15/11/2011 05:00 Volume suppression d'un élément : Volume (Donn)
178006 15/11/2011 05:00 Volume suppression d'un élément : Volume (Syst)
178002 15/11/2011 05:00 L'ordinateur a changé d'ID OCSNG : "8326" --> : "8665"
170287 11/11/2011 05:00 Volume suppression d'un élément : Volume (Donn)
170286 11/11/2011 05:00 Volume suppression d'un élément : Volume (Syst)
170283 11/11/2011 05:00 L'ordinateur a changé d'ID OCSNG : "7871" --> : "8326"
164452 10/11/2011 05:00 Volume suppression d'un élément : Volume (Donn)
164451 10/11/2011 05:00 Volume suppression d'un élément : Volume (Syst)
164450 10/11/2011 05:00 Volume ajout d'un élément : Volume (Donn)
164449 10/11/2011 05:00 Volume ajout d'un élément : Volume (Syst)
164448 10/11/2011 05:00 Carte réseau Suppression d'un composant : "Pilote de serveur d''acc"
164447 10/11/2011 05:00 Carte réseau Suppression d'un composant : "Carte Mini de r"
164445 10/11/2011 05:00 Carte réseau Ajout d'un composant : "Pilote de serveur d''acc"
164443 10/11/2011 05:00 Carte réseau Ajout d'un composant : "Carte Mini de r"
161995 09/11/2011 10:52 Volume suppression d'un élément : Volume (Donn)
161994 09/11/2011 10:52 Volume suppression d'un élément : Volume (Syst)
161993 09/11/2011 10:52 Volume ajout d'un élément : Volume (Donn)
161992 09/11/2011 10:52 Volume ajout d'un élément : Volume (Syst)
161990 09/11/2011 10:52 Logiciel Désinstallation d'un logiciel : "Mise à jour de sécurité pour Windows Internet Explorer 7 (KB2586448) 1"
161989 09/11/2011 10:52 Carte réseau Suppression d'un composant : "Pilote de serveur d''acc"
161988 09/11/2011 10:52 Carte réseau Suppression d'un composant : "Carte Mini de r"
161986 09/11/2011 10:52 Carte réseau Ajout d'un composant : "Pilote de serveur d''acc"
161984 09/11/2011 10:52 Carte réseau Ajout d'un composant : "Carte Mini de r"
144393 08/11/2011 09:08 Volume suppression d'un élément : Volume (Donn)
144392 08/11/2011 09:08 Volume suppression d'un élément : Volume (Syst)
144389 08/11/2011 09:08 L'ordinateur a changé d'ID OCSNG : "7822" --> : "7871"
134617 07/11/2011 17:00 Volume suppression d'un élément : Volume (Donn)
134616 07/11/2011 17:00 Volume suppression d'un élément : Volume (Syst)
134613 07/11/2011 17:00 L'ordinateur a changé d'ID OCSNG : "7694" --> : "7822"
125987 07/11/2011 13:06 Volume suppression d'un élément : Volume (Donn)
125986 07/11/2011 13:06 Volume suppression d'un élément : Volume (Syst)
125983 07/11/2011 13:06 L'ordinateur a changé d'ID OCSNG : "6035" --> : "7694"
103911 25/10/2011 16:40 Volume suppression d'un élément : Volume (Donn)
103910 25/10/2011 16:40 Volume suppression d'un élément : Volume (Syst)
103900 25/10/2011 16:40 L'ordinateur a changé d'ID OCSNG : "4748" --> : "6035"
Offline
>Comment se fait-il que les portables changent régulièrement d'ID ????
c'est un problème de l'agent OCS.
Souvent lié au changement de carte réseau (carte virtuelle, VPN, ...)
Normalement, ça doit être mieux avec l'agent 2.0 (non testé)
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
Je n'ai pas vraiment l'intention de déployer un nouveau client ...
De plus, je ne vais pas déployer un nouveau client sans avoir compris le pourquoi du comment de mon problème.
Pour info je vise en parc de 2000 machines (moitié fixes, moitié portables) sur une vingtaine de sites, autant d'entités, et une demi-douzaine d'annuaires Active Directory.
J'ai vraiment besoin d'une solution ! et pour le moins de comprendre ce qui ce passe, quels équipements sont concernés ...
Cela dit j'ai aussi l'impression que le soucis est lié aux cartes VPN. Il faut que je creuse de ce coté pour voir si seuls les portables équipés VPN ont le problème ...?
Personne n'a t-il déjà rencontré et résolu cette question ?
Déjà, quelqu'un peut-il expliquer où, comment, sous quelles conditions est censé être généré cet ID ?
Et pourquoi le script de synchro OCS n'est-il pas capable de lier des ordinateurs déjà existants dans d'autres entité comme on peut le faire via le menu 'lier de nouveaux ordinateurs à des ordinateurs existants' ?
Dites moi si je me trompe, mais je script fourni avec le plugin massocsimport automatise uniquement l'action 'importation de nouveaux ordinateurs' ?
Merci.
Offline
Je constate sur mon portable connecté en filaire, qu'il suffit que j'active ou désactive ma carte Wifi pour qu'un nouvel ID OC soit attribué au prochain inventaire ..! Est-ce bien normal ????
C'est tellement gros que je ne comprends pas pourquoi je suis si seul avec ce problème ...
Offline
Oui le changement de la configuration matériel entraine un changement d'ID.
Quelle version de l'agent OCS ? Normalement, la version 2.0 est prévue pour éviter cela.
Si OCS élimine proprement le doublon, la synchro doit prendre en compte ce changement sans problème en 0.80.5 (il y a quelques petits bugs dans les versions précédentes)
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
JJ'utilise OCS 1.3.2 et le client 4.0.6.1 avec GLPI 0.78.5
Je mets en oeuvre la solution dans le cadre d'un projet pour un client. Le projet à démarré fin Mai 2011. A l'époque OCS2.0 et GLPI 0.80 balbutiaient … d’où l’utilisation d’OCS 1.3.2, du client 4.0.6.1 et de GLPI 0.78.5.
Aujourd’hui le projet se termine ; nous venons de généraliser le déploiement du client OCS sur l'ensemble des entités et je constate ce problème seulement maintenant (et pour cause).
Difficile de dire au client qu’il faut tout reprendre et tout upgrader ! A la limite je préfère acter que le couple OCS/GLPI ne sait pas gérer convenablement un parc de portable en mode multi-entités et proposer à mon client de revenir au mode mono-entité.
Je suis tout de même surpris par cette regénération intempestive de l'ID et encore plus d’avoir le sentiment d’être le seul que ça dérange … !
Difficile de dire au client qu’il faut tout reprendre et tout upgrader !
Offline
Difficile de dire au client qu’il faut tout reprendre et tout upgrader ! A la limite je préfère acter que le couple OCS/GLPI ne sait pas gérer convenablement un parc de portable en mode multi-entités et proposer à mon client de revenir au mode mono-entité.
Ce serait franchement dommage.
Après il faut voir tout les combien passe la synchro.
Dans l'idéal : le plus souvent possible, pour éviter d'avoir 2 changements d'ID entre 2 synchro (chez nous, toutes les 2 minutes)
GLPI gère normalement bien 1 changement d'ID (si OCS élimine correctement le doublon)
Voir aussi pour blacklister les adresses MAC virtuelles dans OCS.
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
J'ai poussé un peu plus me investigations. Je constate bien que l'agent OCS informe immediatement le serveur OCS dès qu'on active ou désactive une carte réseau sur le poste (au passage un nouvel ID est généré) et envoie la config modifiée, ceci sans attendre que TTO_WAIT arrive à zéro et sans tenir compte de FREQUENCY (=1) !. Je ne vois pas bien l'interêt, ni ce qu'on pourrait faire mais c'est un problème OCS que j'ai posté sur leur forum.
Cela dit le script de syncho OCS/GLPI, en ne gérant qu'un seul changement d'ID n'apporte pas une solution satisfaisante.
Je comprends bien qu'en raccourcissant la synchro on diminue le risque d'avoir 2 changements d'ID dans un même intervalle de temps mais j'ai une crainte au niveau des historiques (plusieurs lignes ajoutées à chaque changement d'ID) qui vont exploser ...
Par ailleurs en descendant à 2 minutes, le suivi de l'historique des synchro devient inexploitable (trop de lignes !).
Avez-vous fait quelque chose pour contrôler la taille de l'historique ?
Cordialement
Offline
Cela dit le script de syncho OCS/GLPI, en ne gérant qu'un seul changement d'ID n'apporte pas une solution satisfaisante.
Pour ne pas me répéter:
http://forums.ocsinventory-ng.org/viewt … 624#p44624
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
ok, ok j'ai bien compris et je te remercie pour tes informations.
Dans mon précédent message mail j'expliquais simplement ce que j'avais constaté pour en faire profiter tout le monde.
Ma question (ma crainte !) portait sur la taille des historiques ..? Après je ne vous embête plus sur ce sujet.
That's all folks.
Offline