You are not logged in.
Pages: 1
Bonjour, j'ai installé le plugin OCS NG. Donc après après avoir lu la doc, si j'ai bien compris, il faut aller recherche le script run.bat pour le lancer. Seulement, lorsque je lance le script, il me dit que le chemin vers run.php est incorrect, où dois-je modifier ceci ?
Merci d'avance.
Offline
Comme c'est marqué dans la même doc que vous avez lu : http://glpi-project.org/wiki/doku.php?i … _du_script
Offline
j'ai mis ceci dans le run.bat:
SET path_php="C:\OCSNG\xampp\php"
SET plugin_glpi="C:\www\glpi\plugins\mass_ocs_import\scripts"
Mais quand je lance le script j'ai des erreurs de dll introuvables (ntwdblib.dll, OCI.dll, LIBPQ.dll, sqlite3.dll, libcs.dll.....)
Comment faire ?
Offline
Je ne suis pas sûr des chemins qu'il faut mettre dans le run.bat.
SET path_php=
SET plugin_glpi=
Pour le path_php, il faut aller rechercher quoi?
Et pour le plugin_php, je crois que c'est bien ce que j'ai mis précédemment ?
Merci encore.
Offline
SET path_php= le répertoire ou se trouver l'executable php (php.exe)
SET plugin_glpi= répertoire ou se trouve le dossier script de massocsimport de glpi
Offline
Donc c'est bien ce que j'ai fait, pour moi ça donne ceci:
SET path_php="C:\www\php-5"
SET plugin_glpi="C:\www\glpi\plugins\mass_ocs_import\scripts"
Mais j'ai toujours le problème des dll introuvables (apparemment c'est à l'exécution de php.exe) qui n'est pas résolu.
Y'a-t-il un client à installer sur les postes client ?
J'ai besoin d'aide svp.
Merci encore.
Last edited by serviceinfo (2009-03-27 12:00:21)
Offline
Bonjour,
Je me décarcasse également pour faire tourner ce script. Et je pense avoir trouvé une solution que j'aimerais vous soumettre.
Mon serveur Web hôte de GLPI a la config suivante:
- Windows Server 2003 SP2
- Server Web IIS
- MySQL Ver 14.12 Distrib 5.0.77, for Win32 (ia32)
- PHP 5.2.9-2 (cli) (built: Apr 9 2009 08:23:19)
J'ai également eu les mêmes problèmes que toi. DLL introuvables et avertissements pour LIBPQ.DLL et consorts.
Ma solution (temporaire), commenter les entrées qui sont dites introuvables dans le fichier php.ini, tout simplement.
Cela ne déstabilisera-t-il pas php en tant que tel? Certainement, si un logiciel se base sur les extension commentées...
Mais je pense qu'on peut spécifier le fichier php.ini lors de l'exécution de php.exe run.php... Dès lors, on pourrait utiliser un autre php.ini propre au lancement des processus d'import de masse.
Je dois aller prendre mon train. J'ai donc plus le temps de tester. J'ai préféré écrire ici pour ne pas oublier de donner du feedback.
J'espère que je suis dans le bon.
Amicalement
Laurent
Offline
Me revoilà
Bon, il existe l'option -c avec l'interpréteur php qui permet de donner un fichier ini différent de celui par défaut. Cependant, le "threading" de OSC dans run.php fait également appel à php; ce qui revient à dire que même si on force l'utilisation d'un php.ini lors de l'exécution de run.php, ce .ini n'est pas répercuté dans les sous-processus.
Ce que j'ai donc fait:
1)copier le php.ini original de PHP dans un endroit particulier
2)le modifier en commentant tout les entrées qui posent problème (ce qui veut dire que les entrées sont disponibles dans le php.ini original)
3)modifier run.php comme suit pour qu'il prenne en compte un nouveau paramètre que j'ai nommé --php_ini et qui pourra contenir le chemin d'accès vers le php.ini particulier (attention ce n'est pas le code source complet!..!):
<?php
...
function usage() {
echo "Usage:\n";
echo "\t" . $_SERVER["argv"][0]. " [--args]\n";
echo "\n\tArguments:\n";
echo "\t\t--thread_nbr=num: number of threads to launch\n";
echo "\t\t--server_id=num: GLPI ID of the OCS server to synchronize from. Default is ALL the servers\n";
echo "\t\t--nolog: use standard output rather than log file\n";
echo "\t\t--php_ini=path to PHP ini file\n";
}
function readargs () {
global $server_id, $thread_nbr, $log, $php_ini;
for ($i=1 ; $i<$_SERVER["argc"] ; $i++) {
$it = split("=",$_SERVER["argv"][$i]);
switch ($it[0]) {
case '--server_id':
$server_id=$it[1];
break;
case '--thread_nbr':
$thread_nbr=$it[1];
break;
case '--nolog':
fclose($log);
$log=STDOUT;
break;
case '--php_ini':
$php_ini=$it[1];
break;
default:
usage();
exit(1);
}
}
}
...
if ($php_ini == "" ) {
$cmd="php -q -d -f ocsng_fullsync.php --ocs_server_id=$server_id --managedeleted=1";
}
else {
$cmd="php -c $php_ini -q -d -f ocsng_fullsync.php --ocs_server_id=$server_id --managedeleted=1";
}
$out=array();
$ret=0;
exec($cmd, $out, $ret);
foreach ($out as $line) fwrite ($log, $line."\n");
...
} else {
# Windows - No fork, so Only one process :(
if ($php_ini == "" ) {
$cmd="php -q -d -f ocsng_fullsync.php --ocs_server_id=$server_id --managedeleted=1";
}
else {
$cmd="php -c $php_ini -q -d -f ocsng_fullsync.php --ocs_server_id=$server_id --thread_nbr=1 --thread_id=1 --process_id=$process_id";
}
$out=array();
exec($cmd, $out, $ret);
foreach ($out as $line) fwrite ($log, $line."\n");
}
...
?>
4)modifier run.bat de la sorte (même remarque que pour run.php!):
...
echo Lancement du script
php -c %path_php%\OCS %plugin_glpi%\run.php --php_ini=%path_php%\OCS
...
Dès lors lorsque je lance run.bat manuellement, je n'ai plus de message d'erreur et l'importation se déroule bien. Ne reste donc plus qu'à définir un appel chronique pour l'automatiser totalement.
Last edited by PaliPalo (2009-04-16 13:56:26)
Offline
Pages: 1