• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Solaris 10 - Problème démarrage agent
#1
Bonjour,

Lorsque j'essaye de démarrer l'agent "standalone" (version 2.2.7-3) sur un Solaris 10, j'ai l'erreur suivante:

ld.so.1: perl: fatal : erreur de réadressage : fichiers /tmp/fusioninventory-agent_solaris-10-sparc_2.2.7-3/perl/lib/5.12.1/sun4-solaris-thread-multi/auto/Socket/Socket.so : symbole inet_aton : symbole référencé introuvable
Tué

J'ai vu sur le net que le problème était connu... mais demander une recompil.... est ce que quelqu'un a une idée ?

Merci
  Reply
#2
Bon, je sais que mon problème n'est pas très sexy mais une aide serait la bienvenue ! ^^

Je pense qu'il me manque une librairie... mais ce n'est qu'une hypothèse... Est ce que quelqu'un sait quels sont les pré requis en terme de librairies ?
Il faut mais libc... mais ensuite ?

Merci
  Reply
#3
Bonjour,

Je vais tenter de t'aider, mais je viens de mettre en place la prebuilt 2.2.7-3 sur un Solaris 10 Sparc (l'agent en service était un 2.2.5-1), et je n'ai eu aucun problème d'exécution :-(

En tapant la commande ldd sur le fichier Socket.so qui te pose problème j'ai vu qu'il faut les libc et libm :
Code:
#ldd fusioninventory-agent_solaris-10-sparc_2.2.7-3/perl/lib/5.12.1/sun4-solaris-thread-multi/auto/Socket/Socket.so
        libc.so.1 =>     /usr/lib/libc.so.1
        libm.so.2 =>     /usr/lib/libm.so.2
        /lib/libm/libm_hwcap1.so.2
        /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1

Ton problème se situe peut-être du côté des variables PATH ou plutôt LD_LIBRARY_PATH ?
Voici le mien :
Code:
LD_LIBRARY_PATH=/usr/openwin/lib:/usr/lib:/usr/local/lib:/usr/ccs/lib:/usr/ucblib

Marc
GLPI 9.4.5 - Fusioninventory for GLPI 9.4+2.4 - Fusioninventory Agent 2.5.2
  Reply
#4
Pouvez-vous essayer cette version : http://prebuilt.fusioninventory.org/gene...121019.zip ?
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
  Reply
#5
Merci à vous deux !

Goneri,
j'ai installé la version mais j'ai le message suivant "[error] Can't load Proc:Big Grinaemon. Is the module installed?"


ZenAdm,
J'ai comparé entre deux serveurs, l'un fonctionnant et l'autre pas et j'ai le même résultat pour un ldd sur le fichier Socket.so Sad
  Reply
#6
Le résultat de ldd est le même sur les deux serveurs, est-ce que la variable d'environnement LD_LIBRARY_PATH est identique elle aussi ?
Il faut a priori qu'elle contienne au moins /usr/lib.
GLPI 9.4.5 - Fusioninventory for GLPI 9.4+2.4 - Fusioninventory Agent 2.5.2
  Reply
#7
Celle du serveur qui fonctionne: echo $LD_LIBRARY_PATH=/usr/openwin/lib

Celle du serveur qui ne fonctionne pas: echo $LD_LIBRARY_PATH=/usr/openwin/lib:/opt/dsrk/lib

J'ai essayé de mettre la seconde à la même valeur que la première, sans résultat
  Reply
#8
En faisant des recherches sur Google avec les mots "solaris ldd not working", je suis tombé sur 2 articles qui expliquent que la variable LD_LIBRARY_PATH n'est plus la réponse sur les dernières versions de Solaris, et qu'il faut même l'éviter maintenant (mes connaissances deviennent décidément trop vieilles Wink) :
http://linuxmafia.com/faq/Admin/ld-lib-path.html
http://prefetch.net/articles/linkers.badldlibrary.html

Mais je trouve que ça ne donne pas vraiment de réponse sur comment résoudre ton problème Sad

Peut-être la variable PATH ? La version de perl appelée ne serait peut-être pas la même sur tes deux serveurs ?
Je ne sais pas trop comment t'aider, mais si tu trouves la réponse elle m'intéresse.
GLPI 9.4.5 - Fusioninventory for GLPI 9.4+2.4 - Fusioninventory Agent 2.5.2
  Reply
#9
La solution serait là....

http://stackoverflow.com/questions/37516...solaris-10

mais demanderait une recompil de l'agent... ce que je ne veux pas faire dans mon cas: j'ai très peu de serveurs impactés (moins d'une dizaine sur 200 déployés actuellement), pas de serveurs de dev... et il faudrait que je sois capable d'avoir un serveur de compil installé exactement de la même façon que ceux qui posent problème...
  Reply
#10
Goneri
Je reproduis le problème sur un solaris 10u2 et un solaris 10u4
Pour ma part j'utilise les prebuild des agents, le perl est donc embded.
Comment se fait il dans ce cas que ldd voir les libs pointer sur celle du socle?
  Reply
#11
Voici les différences que j'ai trouvées entre un serveur qui fonctionne et un en erreur. Celui qui fonctionne a ces paquets en plus:
application SMCbison bison
application SMCcurl curl
application SMCexpat expat
application SMCfontc fontconfig
application SMCftype freetype
application SMCgcc gcc
application SMCgd gd
application SMCjpeg jpeg
application SMClibart libart_lgpl
application SMClibpng libpng
application SMCncurs ncurses
application SMCnetsnmp netsnmp
application SMCossl openssl
application SMCpopt popt
application SMCre2c re2c
application SMCreadl readline
application SMCrrdt rrdtool
application SMCxpm xpm
application SMCzlib zlib
  Reply
#12
Par rapport aux paquets de pitpoule sur son serveur qui fonctionne, voici les paquets que j'ai et que je n'ai pas sur mes serveurs Solaris 10u10 (8/11) qui fonctionnent (un hôte et 4 zones) :

application SMCbison bison NON (mais SUNWbison)
application SMCcurl curl NON
application SMCexpat expat NON (mais SUNWlexpt)
application SMCfontc fontconfig OUI
application SMCftype freetype NON (mais SUNWfreetype2)
application SMCgcc gcc OUI (et SUNWgcc)
application SMCgd gd NON
application SMCjpeg jpeg OUI
application SMClibart libart_lgpl NON
application SMClibpng libpng NON
application SMCncurs ncurses OUI
application SMCnetsnmp netsnmp NON
application SMCossl openssl OUI (et SUNWopenssl)
application SMCpopt popt OUI
application SMCre2c re2c NON
application SMCreadl readline NON
application SMCrrdt rrdtool NON
application SMCxpm xpm NON
application SMCzlib zlib OUI (et SUNWzlib)

Les packages dont le nom commence par SMC proviennent du site SunFreeware alors que les packages en SUNW sont ceux de Sun. On a donc ajouté manuellement tous ces packages sur le serveur qui fonctionne, ce ne sont pas des packages Sun d'origine.

Un bon candidat me semble être gcc, qu'en dites-vous ?
Marc
GLPI 9.4.5 - Fusioninventory for GLPI 9.4+2.4 - Fusioninventory Agent 2.5.2
  Reply
#13
ZenAdm Wrote:Par rapport aux paquets de pitpoule sur son serveur qui fonctionne, voici les paquets que j'ai et que je n'ai pas sur mes serveurs Solaris 10u10 (8/11) qui fonctionnent (un hôte et 4 zones) :

Un bon candidat me semble être gcc, qu'en dites-vous ?
Marc

hum oui et non parce que sur celui qui ne fonctionne pas, il y a
application SMClgcc346 libgcc

Il y a aussi d'ailleurs
application SMCliconv libiconv
application SMClintl libintl
application SMClsof lsof
application SMCsudo sudo

Est ce que libiconv ou libintl ne viendrait pas mettre le binz ?
  Reply
#14
pitpoule Wrote:Est ce que libiconv ou libintl ne viendrait pas mettre le binz ?

Je ne pense pas, car je les ai tous les deux sur mes serveurs qui fonctionnent...
Voici la liste de tous les packages SMC installés sur mes serveurs :

application SMCgcc gcc
application SMCjpeg jpeg
application SMClgcc346 libgcc
application SMClibidn libidn
application SMCliconv libiconv
application SMClintl libintl
application SMCncftp ncftp
application SMCncurs ncurses
application SMCossl openssl
application SMCpopt popt
application SMCrsync rsync
application SMCtar tar
application SMCtop top
application SMCwget wget
application SMCx11vnc x11vnc
application SMCyarbu yarbu
application SMCzlib zlib
GLPI 9.4.5 - Fusioninventory for GLPI 9.4+2.4 - Fusioninventory Agent 2.5.2
  Reply
#15
pitpoule Wrote:Goneri,
j'ai installé la version mais j'ai le message suivant "[error] Can't load Proc:Big Grinaemon. Is the module installed?"


Il faut désactiver l'utilisation du mode “daemon” dans le fichier agent.cfg, de toutes façons a ma connaissance Proc:Big Grinaemon ne marche pas sur Solaris.
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
  Reply
#16
goneri Wrote:
pitpoule Wrote:Il faut désactiver l'utilisation du mode “daemon” dans le fichier agent.cfg, de toutes façons a ma connaissance Proc:Big Grinaemon ne marche pas sur Solaris.

Ca me surprend puisque j'ai plein de Solaris qui fonctionne en mode daemon !

Sinon, j'ai maintenant cette erreur
[error] [http client] communication error: 501 Protocol scheme 'https' is not supported (Crypt::SSLeay or IO::Socket::SSL not installed)
[fault] No answer from the server at lib/FusionInventory/Agent.pm line 248.

Je précise que le serveur GLPI tourne en https
  Reply
#17
Goneri Wrote:Il faut désactiver l'utilisation du mode “daemon” dans le fichier agent.cfg, de toutes façons a ma connaissance Proc:Big Grinaemon ne marche pas sur Solaris.
Sur mes serveurs en Solaris 10u10, je n'ai aucun souci avec le mode "daemon", ça fonctionne très bien. Je ne sais pas ce qu'il en est pour les autres versions...
GLPI 9.4.5 - Fusioninventory for GLPI 9.4+2.4 - Fusioninventory Agent 2.5.2
  Reply
#18
pitpoule Wrote:Sinon, j'ai maintenant cette erreur
[error] [http client] communication error: 501 Protocol scheme 'https' is not supported (Crypt::SSLeay or IO::Socket::SSL not installed)
[fault] No answer from the server at lib/FusionInventory/Agent.pm line 248.

De mon côté je fonctionne en HTTP, même si ce n'est pas recommandé...

Est-ce que le package SMCossl est bien installé sur le serveur en question ?
GLPI 9.4.5 - Fusioninventory for GLPI 9.4+2.4 - Fusioninventory Agent 2.5.2
  Reply
#19
je confirme le https ne fonctionne pas sur agent standalone
  Reply
#20
Je constate que je me suis trompé sur Proc:Big Grinaemon, tant mieux Smile. Pour le HTTP vous pouvez l'utiliser a condition de désactiver surtout le module Deploy.
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
  Reply
#21
La désactivation du module Deploy si on utilise HTTP, c'est pour des raisons de sécurité ?
GLPI 9.4.5 - Fusioninventory for GLPI 9.4+2.4 - Fusioninventory Agent 2.5.2
  Reply
#22
Oui, pour éviter qu'un serveur hostile fasse des ordres d'installation.
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
  Reply
#23
tout ça ne m'arrange pas tellement parce que j'ai besoin, du https et du mode daemon !
  Reply
#24
goneri Wrote:Oui, pour éviter qu'un serveur hostile fasse des ordres d'installation.

je ne vois pas trop comment c'est possible puisque l'url du serveur est stocké dans le fichier de config
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#25
Tu peux très bien avoir un serveur hostile qui prend la même IP que ton serveur légitime.
Please contact Fusioninventory Partners companies if you look for a FusionInventory on site expert.
http://www.fusioninventory.org/partners/
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)