• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Failed to start the RPC server
#1
Bonjour, j'utilise en production GLPI 0.80.7 couplé à OCSInventory 2.0 (HTTPS + Authentification AD +SSO) sur DEBIAN LENNY et souhaiterai inventorier switchs, imprimantes réseaux et téléphones ToIP avec FusionInventory 2.1.10-1 déjà installé. Mais impossible de faire remonter l'agent une première fois à partir du serveur rien n'apparait dans "gestion des agents" côté GLPI.

En fait, j'ai du mal à saisir le comportement de l'agent voire la différence entre agent.cfg présent dans etc/fusioninventory et fusioninventory-agent dans /etc/default.

Dans mon cas, faut-il faire pointer la config de l'agent vers server=https://"serveur"/ocsinventory ou bien server=https://"DOMAIN"\compteAD:motdepasse@serveur/glpi/plugins/fusioninventory/front/
plugin_fusioninventory.communication.php ?

J'ai tenté de lancer l'agent de cette façon entre autre:

fusioninventory-agent -D --debug --ca-cert-file=/etc/fusioninventory/server.crt
C'est le chemin associé au certificat copié dans ce répertoire et déjà utilisé pour les remontées d'inventaire OCS. je ne sais d'ailleurs pas en lisant les docs s'il faut un autre certificat pour fusioninventory ou s'il peut fonctionner avec le même qu'OCS.

Le mode Debug me répond notamment:
[error] Failed to start the RPC Server et 500 SSL negotiation failed (le CN est bon pourtant)

Merci de votre aide.
#2
pluto server=https://"DOMAIN"\compteAD:motdepasse@serveur/glpi/plugins/fusioninventory/front/plugin_fusioninventory.communication.php puisqu'il doit remonter via le plugin FusionInventory pour GLPI
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
#3
Merci de votre réponse.

En fait, j'ai du mal à saisir la différence entre agent.cfg présent dans etc/fusioninventory et fusioninventory-agent dans /etc/default. Pouvez-vous m'éclairer?

Voilà le résultat:


# fusioninventory-agent -D --debug --ca-cert-file=/etc/fusioninventory/server.crt
[debug] FusionInventory unified agent for UNIX, Linux, Windows and MacOSX 2.1.10
[debug] Log system initialised (2)
[debug] --scan-homedirs missing. Don't scan user directories
[debug] vardir: /var/lib/fusioninventory-agent/__LOCAL__
[debug] [/tmp] Next server contact planned for Tue Jun 5 15:08:42 2012
[debug] No accountinfo file defined
[debug] vardir: /var/lib/fusioninventory-agent/https:__DOMAIN\*****:******@******_glpi_plugins_fusioninventory_front_plugin_fusioninventory.communication.php
[debug] [https://DOMAIN\*****:*****@******/glpi/plugins/fusioninventory/front/plugin_fusioninventory.communication.php] Next server contact planned for Tue Jun 5 15:14:39 2012
[debug] No accountinfo file defined
[debug] [RPC] static files are in /usr/share/perl5/auto/share/dist/FusionInventory-Agent/html
[debug] FusionInventory Agent initialised
[error] Failed to start the RPC server


Je ne parviens donc pas à joindre l'adresse en http sur le port 62354 avec les options /now/TOKEN.

EDIT: Entre temps j'ai upgradé la version d'ocs-server en 2.0.5, même résultat.

Par contre lorsque je tente une connexion avec l'adresse: https://127.0.0.1:62354/now à partir du serveur j'obtiens:

------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Échec de la connexion sécurisée

Une erreur est survenue pendant une connexion à 127.0.0.1:62354.

SSL a reçu un enregistrement qui dépasse la longueur maximale autorisée.

(Code d'erreur : ssl_error_rx_record_too_long)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

En http avec l'adresse http://127.0.0.1:62354/now, j'obtiens une erreur 404.
#4
Bonjour, du nouveau après upgrade du plugin en 0.80+4, j'ai enfin réussi à démarrer le service RPC parcontre sur le serveur lui-même lorsque je tente un 127.0.0.1:62354/now j'ai une erreur 500. J'ai donc essayé sur un client window de lancer un inventaire et j'obtiens un bad token:

fusioninventory-agent -D --debug --ca-cert-file=/etc/apache2/server.crt
[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:__DOMAIN\fusioninventory:fusioninventory@192.168.***.***_glpi_plugins_fusioninventory_front_plugin_fusioninventory.communication.php
[debug] No accountinfo file defined
[debug] [https://DOMAIN\*******:******@192.168.*.***/glpi/plugins/fusioninventory/front/plugin_fusioninventory.communication.php] Next server contact planned for Sat Jun 9 12:18:12 2012
[debug] FusionInventory Agent initialised
[info] RPC service started at: http://serveur-glpi-ocs:62354/
[debug] [RPC]Err, 500
[debug] [RPC]Err, 500
[debug] [RPC]Err, 500
[debug] [RPC]'now' catched
[debug] token is TongueDJARTGCARNRRBGMGJSBHANQTAKJKOOUDPMAATLXBKFRWVWKHMGSGVGJXBVMWFDSPVGLUJDEXXJHMMJDSXGXPAELRGBHCCCMCHGMH
[debug] token is TongueDJARTGCARNRRBGMGJSBHANQTAKJKOOUDPMAATLXBKFRWVWKHMGSGVGJXBVMWFDSPVGLUJDEXXJHMMJDSXGXPAELRGBHCCCMCHGMH
[debug] [RPC] bad token token != PDJARTGCARNRRBGMGJSBHANQTAKJKOOUDPMAATLXBKFRWVWKHMGSGVGJXBVMWFDSPVGLUJDEXXJHMMJDSXGXPAELRGBHCCCMCHGMH

Une solution pour avoir la joie de constater une ligne dans la gestion des agents sur GLPI? Smile
#5
T'as un agent des années 60 là, met le à jour déjà
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
#6
tu as pris l'agent par défaut dans debian, il faut mieux partir sur un agent de ce dépôt là : http://fusioninventory.org/wordpress/debian/
#7
Euh pardon je voulais dire 0.80+1.4, la dernière version stable:

[Image: m_20120609-d9k9-45kb.jpg]

J'avais aussi tenté avec la source list Debian avec le même résultat.

J'ai l'impression que le problème est lié à l'authentification côté serveur ou côté certificat. Pourtant ce certificat fonctionne aussi bien pour les remontées OCS que le SSO côté GLPI.
#8
wawa Wrote:tu as pris l'agent par défaut dans debian, il faut mieux partir sur un agent de ce dépôt là : http://fusioninventory.org/wordpress/debian/

Il a indiqué utiliser l'agent version 2.1.10-1, donc la même version que sur le dépôt.
#9
non le token aussi long dis qu'est c'est un agent 2.0.x, pas 2..x ou 2.2.x
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
#10
bonjour, en effet j'ai fait un apt-get update et ré-installer la mise à jour à partir du dépôt DEBIAN comme vous me l'avez conseillé. Ca fonctionne pas mal, j'arrive bien à accéder à partir du serveur à la page 127.0.0.1:62354. Cette partie fonctionne maintenant, merci.

Par contre, lorsque je force un inventaire, j'ai à nouveau un problème avec le certificat: "500 BAD SSL certificate subject"
#11
Bon voilà, une bonne nouvelle. L'agent est bien remonté dans GLPI en démarrant l'agent avec un --no-ssl-check. Merci à vous deux pour votre aide.

Est ce que je peux commencer à travailler avec cet agent sans que ça ne pose de problème de sécurité? Il me reste à comprendre l'erreur dû au certificat. D'après mes recherches, il faut que le CN corresponde à l'adresse de serveur déclaré dans agent.cfg si j'ai bien compris. Ca a l'air d'être le cas pourtant vu qu'il fonctionne pour GLPI et OCS.

Peut-on créer un nouveau certificat, qui ne servirait qu'à authentifier l'agent FUSION sans avoir à modifier celui déjà en place? Si oui, je ne sais pas trop comment m'y prendre.

Je vais déjà vérifier mes conf réseaux et apache.
#12
Bonjour, juste pour info, j'ai réussi à démarrer la conversation de l'agent en SSL avec certificat auto-signé + SSO.

J'ai configuré l'agent.cfg avec:
- l'option no-ssl-check=1,
- en mettant des guillemets et en utilisant le nom de serveur plutôt que l'adresse IP sur l'adresse car mon CN de certificat possède le nom de serveur --> server="https://DOMAINE\login:mdp@NomduServeur/glpi/plugins/fusioninventory/front/plugin_fusioninventory.communication.php"

------------------------------------------------------------------------

Sur une nouvelle installation, l'agent remonte bien mais il m'est impossible de réaliser une découverte. Toutes les tentatives se terminent par "impossible d'agir sur l'agent":

En fait chaque tâche reste bloquée comme suit:

[Wed Jan 9 17:47:10 2013][debug] [http server] request / from client 127.0.0.1
[Wed Jan 9 17:47:44 2013][debug] [http server] request /now/token from client 127.0.0.1
[Wed Jan 9 17:47:44 2013][debug] [http server] valid request, forcing execution right now
[Wed Jan 9 17:47:44 2013][debug] [http server] request /now/site.css from client 127.0.0.1
[Wed Jan 9 17:47:44 2013][debug] [http server] valid request, forcing execution right now
[Wed Jan 9 17:47:45 2013][debug] [http client] Using Compress::Zlib for compression
[Wed Jan 9 17:47:45 2013][debug2] [http client] sending message:
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
<DEVICEID>srvlinglpi1-2012-06-23-23-36-10</DEVICEID>
<QUERY>PROLOG</QUERY>
<TOKEN>JREWNNND</TOKEN>
</REQUEST>

[Wed Jan 9 17:47:45 2013][debug2] format: Zlib
[Wed Jan 9 17:47:45 2013][debug2] [http client] receiving message:
<?xml version="1.0" encoding="UTF-8"?>
<REPLY>
<OPTION>
<NAME>NETDISCOVERY</NAME>
<DICOHASH>794844b7864d452b1ce918057c953bbf</DICOHASH>
<PARAM CORE_DISCOVERY="1" THREADS_DISCOVERY="10" PID="117">
</PARAM>
<RANGEIP ID="3" IPSTART="10.50.0.2" IPEND="10.50.0.254" ENTITY="356">
</RANGEIP>
<AUTHENTICATION ID="1" VERSION="1" COMMUNITY="public">
</AUTHENTICATION>
<AUTHENTICATION ID="2" VERSION="2c" COMMUNITY="public">
</AUTHENTICATION>
<AUTHENTICATION ID="3" VERSION="2c" COMMUNITY="***@snmp**">
</AUTHENTICATION>
<AUTHENTICATION ID="4" VERSION="2c" COMMUNITY="****** ">
</AUTHENTICATION>
<AUTHENTICATION ID="5" VERSION="" COMMUNITY="public">
</AUTHENTICATION>
</OPTION>
<RESPONSE>SEND</RESPONSE>
<PROLOG_FREQ>24</PROLOG_FREQ>
</REPLY>

[Wed Jan 9 17:47:45 2013][debug] running task NetInventory in process 8107
[Wed Jan 9 17:47:45 2013][debug] No SNMPQuery requested in the prolog
[Wed Jan 9 17:47:45 2013][info] task NetInventory is not enabled


J'ai tenté de mettre à jour l'agent mais je suis sur la dernière version apparemment (2.2.3) sur glpi 0.83.7. Si vous avez une idée?
#13
L'agent a été installé comment ?

Que retourne la commande suivante :

fusioninventory-netdiscovery --first 10.50.0.2" --last 10.50.0.254 --debug
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
#14
Merci de ton aide goneri.

Voilà la conf de l'agent.cfg:

server="https://DOMAINE\***:***@***/glpi/plugins/fusioninventory/front/plugin_fusioninventory.communication.php"

# OCS Inventory server with SSL
# server=https://yourserver/ocsinventory
# server=

# Store inventory in a local directory
#local=/tmp

# Agent's logfile
logfile=/var/log/fusioninventory.log

# Max log file size. Useful if the system has no log
# rotation mechanism
logfile-maxsize=10

# Time in second before the first agent execution
delaytime=30

# Debug mode (0)
debug=2
# Save in HTML the inventory requested by --local (0)
html=0

# Network options
# proxy address. e.g: http://user:pass@proxy:port ()
proxy=
# realm for server HTTP auth. e.g: 'Restricted Area' ()
realm=
# user name to use for server auth
user=
# password for server auth
password=

# SSL certificat directory ()
#ca-cert-dir=
# SSL certificat file ()
ca-cert-file=/etc/apache2/ssl/server.crt

#Disable options:
# Do not deploy packages or run command (0)
no-ocsdeploy=0
# Do not generate inventory (0)
no-inventory=0
# Do not return printer list in inventory 0)
no-printer=0
# Don't allow remote connexion (0)
no-socket=0
# Do not return installed software list (0)
no-software=0
# Do not check the SSL connexion with the server (0)
no-ssl-check=1
# Do not use wakeonlan function (0)
no-wakeonlan=0
# Do not use snmpquery function (0)
no-snmpquery=0
#Do not use netdiscovery function (0)
no-netdiscovery=0

#Extra options:
# Set a max delay time of one inventory data collect job (180)
backend-collect-timeout=180
# Indicate the directory where should the agent store its files
#basevardir=/var/lib/fusioninventory-agent
# Use color in the console (0)
color=0
# Detach the agent in background (0)
daemon=0
# Daemon but don't fork in background (0)
daemon-no-fork=0
# Set a max delay time (in second) if no PROLOG_FREQ is set (3600)
delaytime=3600
# Search for Backend mod in ./lib only (0)
devlib=0
# Do not load Perl lib from PERL5LIB and PERLIB environment variable (0)
disable-perllib-envvar=0
# Always send data to server (Don't ask before) (0)
force=0
# Verbose mode (1)
info=1
# Do not contact the server more than one time during the PROLOG_FREQ (0)
lazy=0
# Logger you want to use, can be Stderr,File or Syslog (Stderr)
logger=Stderr
# Ip of the interface to use for peer to peer exchange, default ALL
rpc-ip=
# Port of the RPC, default 62354
rpc-port=
# Allow local users to http://127.0.0.1:62354/now to force an inventory
rpc-trust-localhost=1
# Permit to scan home user directories (0)
scan-homedirs=0
# Path to the directory where are stored the shared files (./share)
share-dir=./share
# Do not write or post the inventory but print it on STDOUT
stdout=0
# Use TAG as tag () Will be ignored by server if a value already exists
tag=
# Wait during a random periode between 0 and DURATION seconds before contacting server ()
wait=

----------------------------------------------------------------------------------------------------------------------------------------

La commande fusioninventory-netdiscovery --first 10.50.0.2" --last 10.50.0.254 --debug ne donne rien du tout, juste un prompt. Je suis en mode CLI sur GLPI, j'ai tenté avec un push ou un pull, c'est idem. Le contact de l'agent se fait lorsque je force un inventaire.
#15
En fait, la description faite ici du lancement des tâches est similaire sauf que c'est sur Windows: http://forum.fusioninventory.org/viewtopic.php?id=1489

Les tâches passent de l'état "préparé" et reste "démarré" avant de s'arrêter au bout d'un temps variable (une dizaine de minutes voire plusieurs heures). Pendant ce temps aucun matériel ne remonte.

j'ai remarqué qu'après avoir purgé l'agent sur glpi et après en avoir recréé un en forçant un inventaire, il portait exactement le même identifiant que le précédent: srvlinglpi1-2012-06-23-23-36-10, je ne sais pas si c'est normal.
#16
Peux-tu lancer : (il y avait un " en trop)

fusioninventory-netdiscovery --first 10.50.0.2 --last 10.50.0.254 --debug
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
#17
Bien vu pour les guillemets. La commande renvoit "bash: fusioninventory-netdiscovery : commande introuvable

Ca a l'air d'être la source du problème.
#18
Peux-tu essayer d'installer libfusioninventory-agent-task-network-perl :

apt-get install libfusioninventory-agent-task-network-perl
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
#19
Ok c'est fait, j'ai mis à jour avec la source dispo ici: http://www.fusioninventory.org/documenta...linux/deb/

Le fait de l'installer oblige la désinstallation du libfusioninventory-agent-task-netdiscovery-perl, c'est normal?

Après plusieurs tentatives, toujours pareil, les tâches de découvertes restent bloquées à 50% puis s'arrête après 20 mn environ.

EDIT: La commande "fusioninventory-netdiscovery --first 10.50.0.2 --last 10.50.0.254 --debug" démarre bien la tâche mais elle bloque toujours à 50% avant de s'arrêter.
#20
fusioninventory-netdiscovery --first 10.50.0.2 --last 10.50.0.254 --debug n'est pas sensée utiliser la tâche du serveur, il faut lancer fuionisnventory-agent pour ça
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
#21
Ok la tâche fonctionne bien avec cette commande mais elle ne remonte aucun équipement sur la plage:

fusioninventory-netdiscovery --first 10.50.0.1 --last 10.50.0.254 --debug
[debug] FusionInventory NetDiscovery task 2.2.0
[debug] Dictionary loaded.
[debug] Thread 1 created
[debug] Thread 1 switched to RUN state
[debug] thread 1: scanning 10.50.0.1
[debug] scanning range: 10.50.0.1-10.50.0.254
[debug] thread 1: nothing found for 10.50.0.1
[debug] thread 1: scanning 10.50.0.2
[debug] thread 1: nothing found for 10.50.0.2
[debug] thread 1: scanning 10.50.0.3
[debug] thread 1: nothing found for 10.50.0.3
[debug] thread 1: scanning 10.50.0.4
[debug] thread 1: nothing found for 10.50.0.4
[debug] thread 1: scanning 10.50.0.5
[debug] thread 1: nothing found for 10.50.0.5
[debug] thread 1: scanning 10.50.0.6
[debug] thread 1: nothing found for 10.50.0.6
[debug] thread 1: scanning 10.50.0.7
[debug] thread 1: nothing found for 10.50.0.7
[debug] thread 1: scanning 10.50.0.8
[debug] thread 1: nothing found for 10.50.0.8
[debug] thread 1: scanning 10.50.0.9
[debug] thread 1: nothing found for 10.50.0.9
[debug] thread 1: scanning 10.50.0.10
[debug] thread 1: nothing found for 10.50.0.10
[debug] thread 1: scanning 10.50.0.11
[debug] thread 1: nothing found for 10.50.0.11
[debug] thread 1: scanning 10.50.0.12
[debug] thread 1: nothing found for 10.50.0.12
[debug] thread 1: scanning 10.50.0.13
[debug] thread 1: nothing found for 10.50.0.13
[debug] thread 1: scanning 10.50.0.14
[debug] thread 1: nothing found for 10.50.0.14
[debug] thread 1: scanning 10.50.0.15
[debug] thread 1: nothing found for 10.50.0.15
[debug] thread 1: scanning 10.50.0.16
[debug] thread 1: nothing found for 10.50.0.16
[debug] thread 1: scanning 10.50.0.17
[debug] thread 1: nothing found for 10.50.0.17
[debug] thread 1: scanning 10.50.0.18
[debug] thread 1: nothing found for 10.50.0.18
[debug] thread 1: scanning 10.50.0.19
[debug] thread 1: nothing found for 10.50.0.19
[debug] thread 1: scanning 10.50.0.20
[debug] thread 1: nothing found for 10.50.0.20
[debug] thread 1: scanning 10.50.0.21
[debug] thread 1: nothing found for 10.50.0.21
[debug] thread 1: scanning 10.50.0.22
[debug] thread 1: nothing found for 10.50.0.22
[debug] thread 1: scanning 10.50.0.23
[debug] thread 1: nothing found for 10.50.0.23
[debug] thread 1: scanning 10.50.0.24
.../...
#22
Il devrait y avoir des équipements justement ? Tu arrives à les pinger depuis la machine ?
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
#23
Oui tous les équipements réseaux switchs, serveurs téléphonie...etc... Je ne comprends vraiment pas ce qu'il se passe. Je ping parfaitement l'ensemble des équipements depuis le serveur.

Je ne sais vraiment plus où chercher. Peut-être une analyse de trames?

Merci en tous les cas de votre aide.

Edit: lorsque je supprime l'agent et que j'en créé un nouveau en forçant un inventaire, j'obtiens toujours le même: srvlinglpi1-2012-06-23-23-36-10, je devrais avoir la date et l'heure du jour non? De ce fait, je ne peux pas travailler avec plusieurs agents. Le problème ne viendrait-il pas de là? La version de l'agent est toujours une astérisque "*" !?!
#24
Ca fonctionne à nouveau, le problème venait bien de l'agent. J'ai désactivé complètement le plugin sur glpi, j'ai désintallé l'agent sur le serveur et supprimer les .conf de l'agent. Après réinstallation de fusioninventory-agent et réédition des fichiers de conf tout est ok.

Merci encore pour le coup de main.


Forum Jump:


Users browsing this thread: 1 Guest(s)