Cron et plugin mass_import

JMD · 2009-02-23 17:13:45

C'est l'id de hardware si mes souvenirs sont bons.

Vous pouvez cherchez par vous même dans le fichier : https://dev.indepnet.net/glpi/browser/t … nction.php

petithomme · 2009-02-23 17:42:49

D'accord je vais aller voir ça.
J'avoue que j'avais cherché seulement dans les tables GLPI, je n'avais pas pensé que ca pouvait venir d'une table d'OCS.

Par contre en regardant de plus près le log, je me rends compte que je me suis encore une fois mis un doigt dans l'œil en croyant que ça marchait.
En fait, cela marche quand je tape une des deux commandes (run.php ou fullsync.sh) sur mon terminal, mais quand je l'inscris dans la crontab rien ne se passe.

Je vous met un une partie de mon log :

[...]
Mon, 23 Feb 2009 16:29:01 +0100 /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/run.php started
Mon, 23 Feb 2009 16:29:01 +0100 /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/run.php ended
Mon, 23 Feb 2009 16:30:01 +0100 /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/run.php started
Mon, 23 Feb 2009 16:30:01 +0100 /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/run.php ended
Mon, 23 Feb 2009 16:30:29 +0100 run.php started
Clean old Not Imported machine list (886)
Manage delete items in OCS server #1: "Inventaire"
Thread #1 : starting (1/1)
thread #1 : import computers from server: 'Inventaire'
thread #1 : 3862 computer(s)
.........................................................................................
Thread #1 : done ..
Mon, 23 Feb 2009 16:35:07 +0100 run.php ended
[...]

Les deux premières lignes correspondent au lancement du script par le cron et la dernière, par moi même en ligne de commande avec les mêmes valeur (--thread_nbr=1 --server_id=1)

[root@testrhweb scripts]# crontab -u apache -l
*/5 * * * * /usr/local/bin/php /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/run.php --thread_nbr=1 --server_id=1

Last edited by petithomme (2009-02-24 11:00:42)

JMD · 2009-02-23 18:00:33

A mon avis vous avez soit un problème de droit, soit un problème d'utilisateur pour lancer le script.

Mais bon là c'est plus de l'admin sys que du GLPI

petithomme · 2009-02-23 18:59:44

Oui tout à fait, d'ailleur je suis allé les voir pour demander de l'aide et pour l'instant pas de solution trouvées.
Pour résumer, les deux options, run.php ou fullsync.sh, marchent en ligne de commande à partir du terminal lancées en tant qu'utilisateur Apache ou Root.
Par contre, ces deux options ne fonctionnent pas une fois inscrit dans la crontab (cf log plus haut). Le script se lance et s'arrête dans la seconde.
Je continuerai a chercher demain, et je vous donnerai la solution (si il y a) dès que possible.
Si quelqu'un à une idée je prends

(Environnement VMWare avec Red Hat pour le serveur Apache/PHP)

JMD · 2009-02-23 19:17:24

J'ai pas d'idée là , le cron marche parfaitement chez moi sous Debian et sous Ubuntu.

Là il faut vérifier les droits dans votre installation, vérifiez que les scripts sont exécutables, le php.ini du cli , les propriétairs des fichiers etc...

petithomme · 2009-02-24 18:08:57

Bon, après moulte vérifications j'ai découvert que tout simplement le module php-cli n'était pas installé sur le serveur.
Je me suis attelé à ça avec grande difficulté, et maintenant j'ai droit à un message d'erreur en bonne et dû forme dans le fichier de log :

Tue Feb 24 17:03:02 CET 2009 /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh started
PHP Notice: Undefined variable: argv in /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/ocsng_fullsync.php on line 41
PHP Notice: Undefined variable: argv in /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/ocsng_fullsync.php on line 41
cleaning up.
Tue Feb 24 17:03:03 CET 2009 ended

je précise que cette erreur arrive quand je rempli la crontab de cette manière :

*/1 * * * * /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/ocsng_fullsync.sh --thread_nbr=1 --server_id=1

Quand je met

*/1 * * * * /usr/bin/php /var/www/glpi07-v3/plugins/mass_ocs_import/scripts/run.php --thread_nbr=1 --server_id=1

plus rien ne se passe

Last edited by petithomme (2009-02-24 18:28:46)

remi · 2009-02-24 18:26:32

> Je me suis attelé à ça avec grande difficulté,
Pourquoi ne pas tout simplement utiliser les RPM fournit avec la distribution ?
=> yum install php-cli

Positionne register_argc_argv à On da ta config (php-cli.ini, je pense)

+

JMD · 2009-02-24 18:28:38

Vous lui passez bien des arguments à oscng_fullsync.sh ?

petithomme · 2009-02-24 18:41:46

> Je me suis attelé à ça avec grande difficulté,
Pourquoi ne pas tout simplement utiliser les RPM fournit avec la distribution ?
=> yum install php-cli

-> parce que je ne connais pas grand chose à linux, et encore moins à redhat ^^

et yum il connait pas...

je trouve pas de fichier php-cli.ini

remi · 2009-02-24 19:52:45

On est vachement loin des problème de GLPI là... si faut en plus faire de l'administration système.

PHP prend sa configuration dans le fichier php.ini
En ligne de commande, le fichier php-cli.ini est prioritaire. S'il n'existe pas, il suffit de le créer (ou de modifier le php.ini, solution que je n'aime pas).

Maintenant on ne sait vraiment pas grand chose sur ta config (OS, version, ...)
Mais pour info, Redhat est une distribution commerciale avec un support (pour lequel tu dois payer), alors autant l'utiliser. Et installer PHP à partir des sources (ce que visiblement tu as fais) me semble la pire des solutions pour un débutant (surtout que ça fait sauter la garantie).

+

petithomme · 2009-02-25 10:19:37

Mais y'a pas de souci Rémi, je vais me démerder, si vous (la communauté en générale) voulez m'aider à résoudre ce problème tant mieux, sinon c'est pas grave je trouverai bien une solution.
C'était juste étonnant de voir que le log du cron ne me mettait aucune erreur et travaillait (même partiellement) sans me prévenir qu'il lui manquait quelque chose d'essentiel.
Si j'avais pas essayé le plugin, j'aurais pu continuer à douter.
Un petit test dans le script qui vérifie la présence du module php-cli serait peut être intéressant à rajouter.

[root@testrhweb ~]# uname -a
Linux testrhweb 2.6.17.8 #3 SMP Sat Aug 19 06:09:14 CEST 2006 i686 i686 i386 GNU/Linux

et c'est une vmware même si je pense que ça change pas grand chose.

à priori c'est un problème d'environnement pour apache.

Last edited by petithomme (2009-04-09 09:37:39)

petithomme · 2009-03-04 18:43:31

Bon, j'ai réussi à le faire fonctionner en modifiant le script du .sh.
J'ai rajouter la localisation de php en dure.

[...] php -q [...]

devient

[...] /usr/bin/local/php -q [...]

Par contre, j'ai remarqué quelque chose d'étonnant.
Si j'ai une machine remontée par le cron depuis OCS dans GLPI, et, si je la supprime d'OCS, elle disparait de la table de lien de GLPI et se retrouve "à la corbeille" (déjà peut on empêcher ça ?).
Si je la remets sur le parc et donc dans OCS, GLPI la reconnait et la ressort de la corbeille à une condition : si cette machine à les mêmes caractéristiques hardware définies dans la configuration du mode OCSNG, mais surtout si elle réponds aux mêmes règles d'importations...
Et ce deuxième choix me chagrine...

En effet, mes règles d'importations des postes dans les différentes entités sont basées sur le nom logique de la machine (ex: AAA-132 est un poste étant dans l'entité AAA, BBB-123 dans l'entité BBB, etc...). En supposant qu'un poste de l'entité AAA aille dans l'entité BBB, je devrais le renommer, et donc GLPI créera deux postes alors qu'un seul ne sera réellement en fonction.

J'ai bien compris que GLPI ne pourra pas me transféré mon poste d'une entité à une autre, mais est il possible de garder le lien avec OCS?
Sinon, est ce un choix de développement ou est ce moi qui ai loupé une configuration dans ce mécanisme ?

Last edited by petithomme (2009-03-05 15:00:49)

petithomme · 2009-03-06 15:25:13

Personne n'a de réponse ? Peut être que c'est pas très clair...

Pour condenser, les questions sont :
- Est ce qu'on peut empêcher GLPI de mettre un poste à la corbeille quand il est supprimé d'OCS ?
- Est ce que le Cron peut retrouvé un poste précédemment remonté dans GLPI malgré une affectation d'entité différente?

Last edited by petithomme (2009-04-09 09:35:35)

wawa · 2009-03-06 15:28:25

petithomme wrote:

- Est ce qu'on peut empêcher GLPI de mettre un poste à la corbeille quand il est supprimé d'OCS ?

non

petithomme wrote:

- Est ce que le Cron peut retrouvé un poste dans précédemment remonté dans GLPI malgré une affectation d'entité différente?

oui

petithomme · 2009-03-06 16:57:34

Malheureusement j'ai constaté un résultat différent dans mes tests.

Je remonte un PC via le plugin mass_import, qui se fait affecté dans l'entité A grâce à une règle qui dit que : si le nom machine commence par A-... alors affectation dans entité A.
Je supprime ce poste d'OCS.
Le poste se retrouve à la corbeille dans l'entité A.
Je remasterise le poste et le renomme B-....
Là, le plugin me le remonte dans l'entité B d'après la règle qui dit que si le nom machine commence par B-... alors affectation dans entité B.
Je me retrouve alors avec un doublon de machine sous GLPI mais pas sous OCS.
L'unicité de mes machines est déterminé par la Mac Adresse et le N° de Série sous GLPI et sous OCS.

remi · 2009-03-06 19:15:56

Oui c'est normal...

Au lieu de le supprimer d'OCS, perso :
- désinstallation (pas obligatoire, mais plus simple)
- transfert dans la nouvelle entité (uniquement si on veut conserver son historique, sinon : purge)

+

petithomme · 2009-03-09 10:31:27

Oui, à priori, nous allons tendre vers une corrélation complète entre OCS et GLPI et enlever de la robotisation la suppression d'un poste d'OCS dans le cas d'un remplacement.

Après le problème reste le transfert qui est une action manuelle. Je pense que l'on va développer un script pour automatiser ca.

Par contre, qu'appelles-tu "désinstallation" ?

Last edited by petithomme (2009-03-09 10:42:40)

wawa · 2009-03-09 10:34:48

petithomme wrote:

Par contre, qu'appelle-tu "désinstallation" ?

je vous conseille de regarder la doc du plugin, je pense que c'est compréhensible : http://glpi-project.org/wiki/doku.php?i … nstall_use

petithomme · 2009-03-09 10:46:39

Si j'avais su qu'il parlait d'un plugin je n'aurais pas poser la question.

Merci malgré tout pour le lien...

Et merci à Rémi de m'éclairer sur mes résultats de tests

Last edited by petithomme (2009-03-09 10:57:59)

petithomme · 2009-04-09 09:55:45

Bonjour,

Je remonte ce topic parce que j'ai encore un "souci" avec le pugin mass_import.

J'ai installé ce plugin sur les serveurs de production et je constate un résultat étonnant sous GLPI.
En effet, je ne retrouve qu'une seule ligne dans "Central > Plugins > Import en masse OCS > Informations sur l'exécution des scripts".
Installé hier, avec en option de lancement deux threads, je me retrouve donc avec une seule ligne avec
nombre de threads = 6 (nombre de passage du cron * 2)
date de début = heure de début du premier lancement
date de fin = heure de fin du dernier lancement
machines synchro / importées / non import / liés = total des machines sur l'ensembles des passages du cron
durée = différence entre le début du script et le dernier passage

Bref tout est faussé...

Il me semble que j'avais lu que c'était possible dans le cas où le script n'avais pas pu finir son travail dans les 30s alloué à son exécution. Est-ce que ca pourrait venir de là?

Après dans les faits, le cron/plug fait bien son travail.

J'ai pas encore accès aux log, mais il me semble de toute manière que ecs éxécution ne duraient pas plus de 20/25sc.

Last edited by petithomme (2009-04-09 10:50:43)

wawa · 2009-04-09 10:01:39

oui effectivement il y a un soucis avec la version 1.2.1 du plugin
je note dans ma todolist de sortir une 1.2.2 rapidement
Remi a fait les corrections nécessaires

petithomme · 2009-04-09 10:52:19

Ok vous me rassurez

Merci pour la réponse rapide et pour ce plugin indispensable.

Je guette avec impatience la sortie du petit

wawa · 2009-04-09 17:08:21

voilà,
je viens de publier la version 1.2.2 avec les modifications apportées par Remi

petithomme · 2009-04-09 17:09:47

j'y saute dessus

edit : nickel, ca marche !

Last edited by petithomme (2009-04-09 17:53:30)

Forum GLPI-Project

Announcement

#26 2009-02-23 17:13:45

Re: Cron et plugin mass_import

#27 2009-02-23 17:42:49

Re: Cron et plugin mass_import

#28 2009-02-23 18:00:33

Re: Cron et plugin mass_import

#29 2009-02-23 18:59:44

Re: Cron et plugin mass_import

#30 2009-02-23 19:17:24

Re: Cron et plugin mass_import

#31 2009-02-24 18:08:57

Re: Cron et plugin mass_import

#32 2009-02-24 18:26:32

Re: Cron et plugin mass_import

#33 2009-02-24 18:28:38

Re: Cron et plugin mass_import

#34 2009-02-24 18:41:46

Re: Cron et plugin mass_import

#35 2009-02-24 19:52:45

Re: Cron et plugin mass_import

#36 2009-02-25 10:19:37

Re: Cron et plugin mass_import

#37 2009-03-04 18:43:31

Re: Cron et plugin mass_import

#38 2009-03-06 15:25:13

Re: Cron et plugin mass_import

#39 2009-03-06 15:28:25

Re: Cron et plugin mass_import

#40 2009-03-06 16:57:34

Re: Cron et plugin mass_import

#41 2009-03-06 19:15:56

Re: Cron et plugin mass_import

#42 2009-03-09 10:31:27

Re: Cron et plugin mass_import

#43 2009-03-09 10:34:48

Re: Cron et plugin mass_import

#44 2009-03-09 10:46:39

Re: Cron et plugin mass_import

#45 2009-04-09 09:55:45

Re: Cron et plugin mass_import

#46 2009-04-09 10:01:39

Re: Cron et plugin mass_import

#47 2009-04-09 10:52:19

Re: Cron et plugin mass_import

#48 2009-04-09 17:08:21

Re: Cron et plugin mass_import

#49 2009-04-09 17:09:47

Re: Cron et plugin mass_import

Board footer