Cron ?

fdu · 2006-08-29 17:31:19

MoYo a dit :

il y a deja un système de cron qui le fait tout seul.
toutes les 5 mns si vous affichez une page il synchronisera une machine.
si vous voulez le faire tout le temps il faut croner un wget sur index.php

*

si je comprend bien cette affirmation , il suffit que qq soit connecté à GLPI pour que des maj OCSNG soit faites une par une en "tache de fond" ?
mais dans quel ordre , liens sur existant avant ou après import de nouveaux ???

en mettant le compteur dans la config de la 0.68.1 çà doit stopper cette fonctionnalité ?

nou voudrions faire de la mise a jour en masse , en batch de nuit ... mais je suis pas sur que faire un wget d'une page comme http://serveur/glpi/front/ocsng.link.php soit une bonne solution ...

des idées à me donner ????

merci a tous.

JMD · 2006-08-29 17:35:10

nou voudrions faire de la mise a jour en masse , en batch de nuit ... mais je suis pas sur que faire un wget d'une page comme http://serveur/glpi/front/ocsng.link.php soit une bonne solution ...

Vous devriez trouver votre bonheur ici :

https://dev.indepnet.net:8080/glpi/brow … nk/scripts

Les deux scripts avec ocsng_mass_*

A vous de faire les crons dessus correspondants et de gérer les pbs de timeouts et autres...

fdu · 2006-08-29 18:18:40

merci , vous avez répondu à la deuxème moitié de ma question ...
les deux scripts que vous m'indiquez semblent correspondre au options de l'interface glpi : mise a jour d'ordinateur déjà importé et import de nouveaux ordinateurs ....
il manque donc lier des nouveaux ordinateurs a des ordinateurs déjà existant ?

sinon qu'est ce qui est réelment importeé en tache de fond (cron.php) les mises a jour ou les nouveaux ? ou les deux deux mais dans quels ordre ?

merci beaucoup.

MoYo · 2006-08-29 19:27:36

il n'y a que la synchronisation en tache de fond.
Toutes les autres actions demandent une intervention ce qui semble logique vu que cela créé un lien entre les entrées OCS et GLPI et tous les postes remontés dans OCS ne doivent pas forcement être dans GLPI.

Pour le lien il n'y a pas de script de synchro car le lien en lui même est infaisable sans intervention humaine (choix de la machine destination)

fdu · 2006-08-30 11:04:57

Bonjour ,

infaisable sans intervention humaine

????
Pour des raisons de reprise de données ... nous sommes partis d'une base préremplie dans glpi qui est enrichie des données issues de OCS . Du coup la grosse majorité des mises à jour se font via l'option 'lier un matériel déjà crée' avec la destination soit '---' soit la machine dont le nom est trouvé et PRE-REMPLI , si l'option est pré-remplie alors ont peu automatiser ce processus ! non ? nous sommes en phase de test sur un parc de 350 machines parmi environ 5500 est c'est très long à faire via l'interface ..

d'autre part je trouve que l'argument

tous les postes remontés dans OCS ne doivent pas forcement être dans GLPI.

est en contradiction avec l'articulation actuelle des deux projets, notamment le choix des historiques dans glpi ...

Mais bon, je veux pas faire de polémique, mais PHP c'est pas trop mon truc , je vais chercher une autre solution ...
a ce rythme là nous seront en test sur tout le parc et jamais en production ;-)

MoYo · 2006-08-30 12:21:38

c'est long a faire via l'interface ?
Affichage 99999 -> valider ca doit bien prendre 3 secondes.

Grosse majorité des mises à jour : lier les ordinateurs ne doit se faire qu'une seule fois.
Quelle version de GLPI et d'OCS utilisez vous ?

Bref, je comprend rien... Explicitez complètement votre problème en donnant toutes les informations parce que je pense qu'on perd du temps pour rien.

chacawaca · 2006-08-30 13:25:12

2 boutons a peser je ne vois pas qu'est - ce qui est long la dedans

fdu · 2006-08-30 15:39:53

Bon,
alors si je mets 99999 ma page s'affiche en 3 Minutes (250 machines a importer) , pas 3 secondes , c'est vrai que teste sur des vieux PC vermoulus, mais si ça fonctionne avec çà, on nous fera un beau cadeau de chez HP pour la prod ;-)
mes versions : en test 1 serveur slackware 10.2 xampp 1.5.3.a glpi 0.68.1 pour tests unitaires et plugins, 1 serveur ubuntu 6.06 lamp (mysql 5.1.4 ...) avec OCS inventory RC3-1 et glpi 0.68 pour tester un plugin (edition de fiche de pret à signer), en pseudo-preprod un serveur w2k3 avec xammp (ancienne install ocs , lequel est désactivé) en version 0.68 mais sans plugins sans OCS !
pourquoi faire simple ???
je récupère des infos d'un autre serveur ocs mais en version RC3 seulement.

Grosse majorité des mises à jour : lier les ordinateurs ne doit se faire qu'une seule fois.

peut-être le fait d'importer alternativement des infos des deux serveurs ocs met qq chose en vrac ?
Tous les pc modifiés dans OCS se retrouvent dans 'lier des nouveaux ordinateurs ...' avec la destination pré-remplie et non modifiable ...
quand je clique 'importer' çà prens un quart d'heure pour environ 100 machines ....

Si vous trouvez çà cool ....

MoYo · 2006-08-30 15:53:27

2 serveurs OCS ?
Est-ce qu'un jour vous avez vu quelquepart sur le site de GLPI qu'il était possible d'utiliser 2 serveurs OCS ?

Bref, je pense que je vais trouver cool de ne plus vous répondre.

fdu · 2006-08-30 16:27:30

MoYo wrote:

2 serveurs OCS ?
Est-ce qu'un jour vous avez vu quelquepart sur le site de GLPI qu'il était possible d'utiliser 2 serveurs OCS ?
Bref, je pense que je vais trouver cool de ne plus vous répondre.

Pourquoi, c'est interdit de changer de serveur dans la Configuration et d'alterner les imports ????? comment vous faites avec des inventaires sur des réseaux différents ???

je vous trouve un peu "étroit" dans votre dernière remarque ...

si vous voulez absolument vous retrouver avec un 'fork' de votre projet , continuez avec ce style de remarques ....

MoYo · 2006-08-30 16:51:58

hahahahahahhaah trop fort.....
Je l'attendais celle là

Quand on utilise des outils on se renseigne d'abord sur leurs limites.
Et actuellement la limite de l'import OCS dans GLPI c'est 1 serveur OCS pas 2 ni 3 ni 4.
Sachant que rien ne vous empèche d'avoir un seul serveur OCS sur plusieurs réseaux enfin je dis ca je dis rien.

En cherchant un peu partout sur le site on trouve :
0.7 : gestion multi-entités
qui fournira ce genre de support

GLPI a une certaine logique de fonctionnement, si vous voulez l'adapter à vos besoins libre à vous.

Pour info j'ai exactement la même problèmatique : plusieurs réseaux / entités disjointes et nécessité à terme de n'avoir qu'un seul GLPI. Or pour le moment c'est impossible ....
Ce qui fait que la solution est :
- pour le moment :
- 1 serveur OCS commun à tous les réseaux, il n'y a aucune limitation pour ca
- 1 GLPI pour chaque entité avec import depuis OCS en utilisant les TAGS qui sont là pour ca
- A terme (0.7) :
- 1 serveur OCS toujours
- fusion des GLPI en un GLPI unifié

Sachant que le volume de postes géré n'a rien a voir avec vos petits 5500 postes.
Ca fonctionne très bien le tout est de réfléchir correctement à l'architecture mise en place et à son dimensionnement

PS : pour le style de ma réponse précédente elle n'est que toute relative avec le ton que vous employez dans vos précédents messages.

fdu · 2006-08-30 17:15:01

MoYo wrote:

hahahahahahhaah trop fort.....
Je l'attendais celle là
Quand on utilise des outils on se renseigne d'abord sur leurs limites.
Et actuellement la limite de l'import OCS dans GLPI c'est 1 serveur OCS pas 2 ni 3 ni 4.
Sachant que rien ne vous empèche d'avoir un seul serveur OCS sur plusieurs réseaux enfin je dis ca je dis rien.
En cherchant un peu partout sur le site on trouve :
0.7 : gestion multi-entités
qui fournira ce genre de support
GLPI a une certaine logique de fonctionnement, si vous voulez l'adapter à vos besoins libre à vous.
Pour info j'ai exactement la même problèmatique : plusieurs réseaux / entités disjointes et nécessité à terme de n'avoir qu'un seul GLPI. Or pour le moment c'est impossible ....
Ce qui fait que la solution est :
- pour le moment :
- 1 serveur OCS commun à tous les réseaux, il n'y a aucune limitation pour ca

si si , les droits d'admin ....

MoYo wrote:

- 1 GLPI pour chaque entité avec import depuis OCS en utilisant les TAGS qui sont là pour ca
- A terme (0.7) :
- 1 serveur OCS toujours
- fusion des GLPI en un GLPI unifié

c'est vrai qu'on est impatient ...

MoYo wrote:

Sachant que le volume de postes géré n'a rien a voir avec vos petits 5500 postes.

je note votre suffisance ...

MoYo wrote:

Ca fonctionne très bien le tout est de réfléchir correctement à l'architecture mise en place et à son dimensionnement

tout a fait d'accord et c'est pour cela que je pose tant de questions .... je suis pas tout seul a intervenir sur ce projet et je crois que vous ne connaissez peut-être pas très bien la problématique (politique) de certaines entreprises ....

MoYo wrote:

PS : pour le style de ma réponse précédente elle n'est que toute relative avec le ton que vous employez dans vos précédents messages.

CQFD vous me prenez pour un ... , ce que je suis peut-être , mais je ne vous autorise pas à utiliser cet argument !

pour en revenir à MES moutons
pourquoi dois-je les relier à chaque fois ? peut-être que cette question peut influencer le développement de la future version 0.7

MoYo · 2006-08-30 18:49:34

fdu wrote:

MoYo wrote:
- 1 GLPI pour chaque entité avec import depuis OCS en utilisant les TAGS qui sont là pour ca
- A terme (0.7) :
- 1 serveur OCS toujours
- fusion des GLPI en un GLPI unifié
c'est vrai qu'on est impatient ...

C'est sur qu'en étant obligé de gérer des personnes comme vous, elle risque d'arriver super vite la 0.7...

fdu wrote:

MoYo wrote:
PS : pour le style de ma réponse précédente elle n'est que toute relative avec le ton que vous employez dans vos précédents messages.
CQFD vous me prenez pour un ... , ce que je suis peut-être , mais je ne vous autorise pas à utiliser cet argument !

Je ne vous prend pour rien du tout...
Je vous répond sur le même ton hautain et désagréable que vos questions et remarques.
Un petit tour sur les règles du forum vous aurait évité ce genre de réponses.

fdu wrote:

pour en revenir à MES moutons
pourquoi dois-je les relier à chaque fois ? peut-être que cette question peut influencer le développement de la future version 0.7

Vous devez les relier à chaque fois parce que vous utilisez GLPI d'une manière qui n'est pas prévue du tout.
Je vous le répète pour la x ieme fois : GLPI fonctionne en liaison avec un serveur OCS unique.
Les liens inexistants sont nettoyés de la DB ce qui engendre un relink obligatoire dans votre cas d'utilisation.

Si vous ne voulez pas avoir de problème vous mettez un GLPI par serveur OCS et basta.
Il y a une autre solution plus simple dans votre cas mais vu le dialogue cordial que l'on peux avoir avec vous je vous laisse la trouver seul.

Mais je ne comprend pas l'argument des droits d'admin.
Vu que d'après vous je ne connais rien aux problématiques des entreprises... c'est surement pour ca que je ne comprend pas.
Mais pour info, notre serveur OCS recolte les données de plusieurs entités distinctes sur lesquelles nous n'avons aucun accès.

MoYo · 2006-08-30 19:33:21

allez je suis trop bon... ca me perdra.
https://dev.indepnet.net:8080/glpi/brow … n.php#L761

fdu · 2006-08-31 12:16:12

Merci ,
je crois que dans mon cas , en attendant, je doit désactiver la fonction ocsCleanLinks .
bonne fin de journée.
FD

fdu · 2006-09-05 11:15:10

Bonjour ,
j'ai mis en commentaires la deuxième partie de la fonction ocsCleanLinks
après plusisurs jours de tests :
l'import et la synchro sont 100 fois plus rapides , ma base est stable et j'importe des machines des deux bases sans problèmes.

peut-être serait-il bon de migrer l'appel à cette fonction plutot quelque part dans le plugin utilitaires que de faire un nettoyage global de liens pour l'import de chaque machine ;-) ?

merci encore du tuyau

MoYo · 2006-09-05 14:56:34

ce n'est pas faitpour chaque import de machine mais juste avant l'affichage des machines à importer.

Forum GLPI-Project

Announcement

#1 2006-08-29 17:31:19

Cron ?

#2 2006-08-29 17:35:10

Re: Cron ?

#3 2006-08-29 18:18:40

Re: Cron ?

#4 2006-08-29 19:27:36

Re: Cron ?

#5 2006-08-30 11:04:57

Re: Cron ?

#6 2006-08-30 12:21:38

Re: Cron ?

#7 2006-08-30 13:25:12

Re: Cron ?

#8 2006-08-30 15:39:53

Re: Cron ?

#9 2006-08-30 15:53:27

Re: Cron ?

#10 2006-08-30 16:27:30

Re: Cron ?

#11 2006-08-30 16:51:58

Re: Cron ?

#12 2006-08-30 17:15:01

Re: Cron ?

#13 2006-08-30 18:49:34

Re: Cron ?

#14 2006-08-30 19:33:21

Re: Cron ?

#15 2006-08-31 12:16:12

Re: Cron ?

#16 2006-09-05 11:15:10

Re: Cron ?

#17 2006-09-05 14:56:34

Re: Cron ?

Board footer