• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[Résolu]Lancement de l'agent depuis GLPI
#1
Bonjour à tous,

Suite à l'installation de GLPI, nous avons souhaité installer fusion inventory dessus.
L'installation du plugin s'est bien déroulée et semble opérationnelle depuis GLPI, mais nous rencontrons des soucis pour lancer la découverte.

L'agent est installé sur le même serveur que GLPI. Voici le code d'erreur retourné lorsque nous lançons la découverte:
"PHP ERROR: fopen(http://ip_serveur:62354/now/) [function fopen]: failed to open stream: HTTP request failed! HTTP/1.1 500 Internal Error in /var/www/glpi/plugin/fusioninventory/inc/task.class.php at line 248"

Merci à vous.
Cordialement,
Anthony
  Reply
#2
Il faut lancer l'agent en mode daemon (avec l'argument -D ou -d ) pour que ca puisse fonctionner et relier l'agent à un ordinateur dans glpi.
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#3
Merci pour ce retour! Smile

Nous avons maintenant un nouveau problème. L'agent a d'abord été configuré sans ssl, et il marchait très bien.
Nous souhaitons maintenant utiliser ssl.
Nous avons édité le fichier /etc/fusioninventory/agent.cfg de manière à utiliser le cryptage:

server=https://glpi...

Le daemon a ensuite été redémarré.
Cependant, GLPI ne semble pas retrouver l'agent (si on essaye de lancer une recherche d'équipement, glpi affiche : "plugin indisponible")

Nous avons alors essayé d'exécuter l'agent depuis le serveur, mais nous obtenions une erreur concernant le certificat:
fusioninventory-agent --debug

[fault] You need to use either --ca-cert-file or --ca-cert-dir to give the location of your SSL certificat. You can also disable SSL check with --no-ssl-check but this is very unsecure.


Suite à cette erreur, nous avons spécifié le certificat manuellement:

fusioninventory-agent --debug --ca-cert-file notre_certificat

[debug] sending XML
[error] Cannot establish communication with `https://glpi-test.notre_domaine.fr/plugins/fusioninventory/front/plugin_fusioninventory.communication.php: 500 SSL negotiation failed: `
[error] No anwser from the server
[debug] [https://glpi-test.notre_domaine.fr/plugi...cation.php] Next server contact'd just been planned for Mon Jul 12 10:03:20 2010

Nous n'arrivons pas à trouver la source de cette erreur "500 SSL negotiation failed"

Par contre, l'exécution de l'agent avec l'option --no-ssl-check fonctionne et nous obtenons bien la remontée d'information dans glpi.
  Reply
#4
essayez avec : --ca-cert-file=notre_certificat

et le nom du fichier du certificat doit être :
* soit avec le chemin complet
* soit chemin relatif à partir de l'endroit ou vous allez lancer l'agent

Pour pouvoir le démarrer à partir du serveur, il faut le lancer en mode daemon (-d)
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#5
Nous avons entré la commande:

fusioninventory-agent -d --debug --ca-cert-file=notre_certificat (chemin complet)

[debug] FusionInventory unified agent for UNIX, Linux and MacOSX 2.0.6
[debug] Log system initialised (Stderr)
[debug] --scan-homedirs missing. Don't scan user directories
[debug] vardir: /var/lib/fusioninventory-agent/https:__glpi-test.ipoc.btservices.fr_plugins_fusioninventory_front_plugin_fusioninventory.communication.php
[debug] No accountinfo file defined
[debug] [https://glpi-test.notre_domaine.fr/plugi...cation.php] Next server contact planned for Mon Jul 12 10:13:20 2010
[debug] Time to call Proc:Big Grinaemon

Le daemon semble bien être exécuté:

ps aux | grep fusion
root 9573 3.5 6.5 97516 25048 ? Sl 10:13 0:00 /usr/bin/perl /usr/bin/fusioninventory-agent -d --debug --ca-cert-file=certif

Cependant l'agent reste indisponible depuis GLPI
  Reply
#6
l'ip du pc est bonne dans glpi et l'agent est bien associé à un ordi de glpi ?
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#7
Oui, je viens juste de vérifier

Edit: Je viens d'essayer de lancer la deamon avec l'option no-ssl-check pour voir si glpi trouvais l'agent, mais il est toujours en statut " agent(s) indisponible(s)"
  Reply
#8
essaye de lancer avec -D à la place de -d pour tester et voir ce qu'il te donne
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#9
# fusioninventory-agent -D --debug --ca-cert-file=certif

[debug] FusionInventory unified agent for UNIX, Linux and MacOSX 2.0.6
[debug] Log system initialised (Stderr)
[debug] --scan-homedirs missing. Don't scan user directories
[debug] vardir: /var/lib/fusioninventory-agent/https:__glpi-test.domaine.fr_plugins_fusioninventory_front_plugin_fusioninventory.communication.php
[debug] No accountinfo file defined
[debug] [https://glpi-test.domaine.fr/plugins/fus...cation.php] Next server contact planned for Mon Jul 12 11:04:46 2010
[debug] FusionInventory Agent initialised
[info] RPC service started at: http://akira:62354/
[debug] Compress::Zlib is available.
[debug] token is :XXXXXXXXXXXXXXXXXXXXXXXXWWOFKRESBRHBAVFNKOMFSOHCXPCAKNXJRVFNBJLJTNFJOVRHWLIXSOOOQUHTAKXHJWHNRWPGKURJFKAI
[debug] sending XML
[error] Cannot establish communication with `https://glpi-test.domaine.fr/plugins/fusioninventory/front/plugin_fusioninventory.communication.php: 500 SSL negotiation failed: `
[error] No anwser from the server
[debug] [https://glpi-test.domaine.fr/plugins/fus...cation.php] Next server contact'd just been planned for Mon Jul 12 11:06:23 2010
  Reply
#10
Et si j'essaye la commande
# fusioninventory-agent -D --debug --no-ssl-check

La remonté d'information dans GLPI se fait bien...
  Reply
#11
regardez les logs d'apache ssl , à mon avis il dois y avoir un soucis avec le certificat
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#12
Ok, je regarde et vous tiens au courant si j'ai du nouveau.
Merci pour votre aide Wink
  Reply
#13
Alors, quelques nouvelles!

D'après les logs d'apache ( error.log, access.log et other_vhosts_access.log), il n'y a pas de problème détecté.

Etat actuel:

L'agent est visible et à été automatiquement ajouté dans GLPI lorsque je l'ai lancer depuis le serveur.
Dans GLPI, il est correctement lié au serveur sur lequel il est installé. De même, les informations du serveur dans glpi sont exactes.
SI j'essaye de lancer la découverte depuis GLPI, il m'affiche une erreur "Agent(s) indisponible(s)" (l'agent est en lancé en mode daemon -d).
Par contre, si je relance l'agent avec l'option -D, je m'aperçois qu'il scanne bien la plage ip sélectionnée dans glpi.

Voici la commande que j'utilise pour lancer l'agent:

# fusioninventory-agent --debug --ca-cert-file=certif.pem --no-ssl-check
avec les options -D ou -d
  Reply
#14
Est-ce que vous avez plusieurs interface / ip réseaux ?
Vous êtes sur quel système d'exploitation?
Quelle version de l'agent fusioninventory ?

Que de questions :p
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#15
Bonjour! Smile

L'agent tourne sous une Debian Lenny, et 2 interfaces réseaux sont configurées dessus (de même pour GLPI).
L'agent lui est en version 2.0.6.

Cdt,
Anthony
  Reply
#16
on va chercher alors
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#17
Bonjour,

Après avoir fais quelques tests et recherches sur le serveur, je me suis aperçu que le script d'init de l'agent fonctionnait mal (du moins, sur notre serveur). Même si je doute qu'il y ai un quelconque rapport avec mon autre problème, je tenais à le signaler, pour savoir si c'était un cas isolé par exemple Smile

Voici ce qu'il se passait (de mémoire, j'ai modifié le script pour que le tout fonctionne correctement)

# /etc/init.d/fusioninventory start

--> le daemon se lance et apparait bien dans la liste des processus

# /etc/init.d/fusioninventory statut

--> indique que le daemon n'est pas lancé : failed

# /etc/init.d/fusioninventory stop

--> après cette commande, le daemon apparaissait toujours dans la liste des processus, je devais le killer pour l'arréter

Voici une partie du code original du script:

start)
echo -n "Starting $DESC: "
start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON -- $DAEMON_OPTS || true
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON || true
echo "$NAME."
;;
restart|force-reload)
echo -n "Restarting $DESC: "
start-stop-daemon --stop --quiet --pidfile \
/var/run/$NAME.pid --exec $DAEMON || true
sleep 1
start-stop-daemon --start --quiet --pidfile \
/var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS || true
echo "$NAME."
;;
status)
status_of_proc -p /var/run/$NAME.pid "$DAEMON" fusioninventory-agent && exit 0 || exit $?
;;
*)
echo "Usage: $NAME {start|stop|restart|status}" >&2
exit 1
;;



On voit qu'un fichier .pid devait être créé dans /var/run/ et devais contenir le PID du process. Cependant, ce fichier n'apparaissait pas dans le répertoire.
après un passage dans le manuel de start-stop-daemon, j'ai essayé de rajouter l'option -m dans la commande la commande d'exécution, afin de l'obliger à créer le fichier. Par la suite, un PID était bien stocké dans le fichier fusioninventory.pid, mais il ne correspondait pas au pid du process... (en général, le numéro du pid stocké était très proche du bon pid, 5000 à la place de 5002 par ex.)

Je me suis alors lancé dans la réécriture complète des fonctions start, stop, restart et status, voici le résultat:

#CONSTANTES
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/fusioninventory-agent
DAEMON_OPTS="-d --ca-cert-file=cert (chemin absolu) --no-ssl-check"
NAME=fusioninventory-agent
DESC=fusioninventory-agent
PID=/var/run/fusioninventory-agent.pid

[...]

case "$1" in
start)
echo -n "Starting $DESC: "
start-stop-daemon --start --quiet --pidfile -m $PID --exec $DAEMON -- $DAEMON_OPTS
touch $PID
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
pgrep fusioninventory > $PID
start-stop-daemon --stop --quiet --pidfile $PID
rm $PID
echo "$NAME."
;;
restart|force-reload)
echo -n "Restarting $DESC: "
pgrep fusioninventory > /var/run/fusioninventory-agent.pid
start-stop-daemon --stop --quiet --pidfile $PID
sleep 1
start-stop-daemon --start --quiet --pidfile $PID --exec $DAEMON -- $DAEMON_OPTS
echo "$NAME."
;;
status)
if [ -e $PID ]
then
echo "Usage: $NAME started"
else
echo "Usage $NAME stopped"
fi
# status_of_proc -p /var/run/$NAME.pid "$DAEMON" fusioninventory-agent && exit 0 || exit $?
;;
*)
echo "Usage: $NAME {start|stop|restart|status}" >&2
exit 1
;;
esac


Savez vous si il s'agit d'un cas isolé ou bien d'autres ont-ils rencontrés le même problème?
Cordialement,
Anthony
  Reply
#18
Si tu utilise le package apt on nous a reporté le problème la semaine dernière, il est ou va être corrigé
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#19
Ok, merci beaucoup Smile
  Reply
#20
Oui corrigé y a 3 jours : http://packages.debian.org/changelogs/po.../changelog
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#21
Problème réglé!

Comme pour la plupart des bugs, l'erreur était humaine... Je n'ai pas pensé à regarder le firewall... Maintenant que les 2 flux sont ouvert, ça marche beaucoup mieux!

Désolé pour le dérangement, mais un grand merci pour votre aide! Smile

Cordialement,
Anthony
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)