XIVO : erreur lors du provisionning de poste

Bon ben voilà, j'ai fais une migration aujourd'hui de Dalek à Gallifrey......

Tout c'est bien déroulé, enfin, je croyais.....

j'ai voulu mettre à jour, un de mes postes (Polycom IP 330), et lorsqu'il redemarre, il me dit, qu'il ne peut pas contacter le bootserver, et je vois ceci apparaitre dans les syslog : il y a donc un lien qui se fait ....

Code:

---

Oct 16 14:28:21 servxivo sysconfd[2992]: 'GET /server-version HTTP/1.1' 200 87
Oct 16 14:28:21 servxivo autoprovisioning[2967]: do_GET(): handling GET request to path /list for peer ('127.0.0.1', 39694)
Oct 16 14:28:21 servxivo autoprovisioning[2967]: handle_list(): handling /list GET request for peer ('127.0.0.1', 39694)
Oct 16 14:28:21 servxivo autoprovisioning[2967]: "GET /list HTTP/1.0" 200 -

---

Est-ce que quelqu'un aurait une petite idée d'ou me tourner ? car je dois avouer que depuis ce matin 5 h.... j'ai vraiment faits des tests dans tous les sens, et j'avoue que je ne vois plus vraiment quoi faire....

j'espère que l'un d'entre vous à déjà eu se problème et peut éventuellement me donner une soluce.....

j'ai l'impression que je peux contacter le serveur, mais qu'il ne renvoie rien...

Salut, as tu relancé un fetchfw ?

et les logs d'atftp ou de apache si tu provisionne en http disent quoi?

Cela ressemble à un souci de firmware.

Bon ben me revoilà......


un problème ne venant jamais seul, j'ai été coupé du net..... je n'ai donc pas pu vous répondre......


Alors voila :

Quintana :

Citation:

---

Salut, as tu relancé un fetchfw ?

---

Oui, j'ai fais un xivo_fetchw pour tout les firmwares que j'ai besoin.

_AK_ :

Citation:

---

et les logs d'atftp ou de apache si tu provisionne en http disent quoi?

---

apache2 : je n'ai rien du tout en erreur ou autre. le fichier xivo_error.log ainsi que error.log sont vide.

Atftp : j'ai ceci toutes les 5 min environ :

Code:

---

Oct 18 06:49:10 servxivo atftpd[4353.-1218733168]: socket may listen on any addr                                                                  ess, including broadcast
Oct 18 06:49:10 servxivo atftpd[4353.-1218733168]: Creating new socket: 127.0.0.                                                                  1:51460
Oct 18 06:49:10 servxivo atftpd[4353.-1218733168]: Invalid request <0> from 127.                                                                  0.0.1
Oct 18 06:49:10 servxivo atftpd[4353.-1218733168]: Server thread exiting

---

et enfin

Quintana :

Citation:

---

Cela ressemble à un souci de firmware.

---

j'espère que c'est juste cela...... ;)

Pour atftp c'est normal, c'est le monitoring. J'en parle avec Etienne pour qu'il regarde et test le polycom dans la journée.

merci,

si jamais c'est sur des IP 330 que le soucis apparait.

j'ai pas encore oser redémarrer les 650 :)

je reste à dispo si jamais il peut m'appeler sur mon portable

bon, je pense qu'une partie de la migration a foiré.....

aujourd'hui, lors d'un reload, voici les messages qui apparaissent :

Code:

---

[Oct 18 10:12:15] NOTICE[11360]: cdr.c:1449 do_reload: CDR simple logging enabled.
[Oct 18 10:12:15] NOTICE[11360]: res_smdi.c:884 smdi_load: Unable to reload config smdi.conf: SMDI untouched
[Oct 18 10:12:15] WARNING[11360]: res_smdi.c:1406 reload: No SMDI interfaces were specified to listen on, not starting SDMI listener.
[Oct 18 10:12:15] NOTICE[11360]: chan_iax2.c:11469 set_config: Ignoring bindport on reload
[Oct 18 10:12:15] NOTICE[11360]: chan_iax2.c:11528 set_config: Ignoring bindaddr on reload
[Oct 18 10:12:15] WARNING[11360]: chan_iax2.c:10992 build_peer: Set peer->pokefreqnotok to 10000
[Oct 18 10:12:15] WARNING[11360]: chan_iax2.c:10992 build_peer: Set peer->pokefreqnotok to 10000
[Oct 18 10:12:15] WARNING[11360]: chan_iax2.c:10992 build_peer: Set peer->pokefreqnotok to 10000
[Oct 18 10:12:15] NOTICE[11360]: indications.c:502 ast_unregister_indication_country: Removed default indication country 'fr'
[Oct 18 10:12:15] WARNING[11360]: app_voicemail.c:8726 load_config: maxsilence should be less than minmessage or you may get empty messages
[Oct 18 10:12:15] NOTICE[11360]: app_queue.c:6266 reload_penalty_rules: No queuerules.conf file found, queues will not follow penalty rules
[Oct 18 10:12:15] WARNING[11360]: pbx.c:6387 ast_context_verify_includes: Context 'default' tries to include nonexistent context 'parkedcalls'
[Oct 18 10:12:15] WARNING[11360]: pbx.c:6387 ast_context_verify_includes: Context 'from-cablecom' tries to include nonexistent context 'parkedcalls'
[Oct 18 10:12:15] WARNING[11360]: pbx.c:6387 ast_context_verify_includes: Context 'vicidial' tries to include nonexistent context 'parkedcalls'

---

le plus fou, c'est que hier il n'y avait rien.....

Bon definitivement, il y a eu un problème lors de la migration....

car lorsque je fais un apt-get upgrade, voici le retour :

Code:

---

servxivo:/usr/src/MigrGalli# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
7 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? y
Setting up monit (1:4.10.1-4+pf.1) ...
Starting daemon monitor: monitinvoke-rc.d: initscript monit, action "start" failed.
dpkg: error processing monit (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of pf-monitoring-monit:
 pf-monitoring-monit depends on monit; however:
  Package monit is not configured yet.
dpkg: error processing pf-monitoring-monit (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of pf-xivo:
 pf-xivo depends on pf-monitoring-monit; however:
  Package pf-monitoring-monit is not configured yet.
dpkg: error processing pf-xivo (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of pf-xivo-backup:
 pf-xivo-backup depends on pf-xivo; however:
  Package pf-xivo is not configured yet.
dpkg: error processing pf-xivo-backup (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of pf-stats:
 pf-stats depends on pf-server (>> 1:0.3~svn88-1) | pf-common-2; however:
  Package pf-server is not installed.
  Package pf-common-2 is not installed.
  Package pf-xivo which provides pf-common-2 is not configured yet.
dpkg: error processing pf-stats (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of pf-stats-munin:
 pf-stats-munin depends on pf-stats; however:
  Package pf-stats is not configured yet.
dpkg: error processing pf-stats-munin (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of pf-asternic-stats:
 pf-asternic-stats depends on pf-stats; however:
  Package pf-stats is not configured yet.
dpkg: error processing pf-asternic-stats (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 monit
 pf-monitoring-monit
 pf-xivo
 pf-xivo-backup
 pf-stats
 pf-stats-munin
 pf-asternic-stats
E: Sub-process /usr/bin/dpkg returned an error code (1)

---

est-ce que je peux relancer le script de migration ce soir ? ou je risque d'autres problèmes ?

Pour les erreurs de l'apt-get upgrade, j'ai eu ce problème lorsque j'ai voulu installer une XiVO depuis le script. Pensant que ça venait de ma VM qui avait planté j'ai relancé le script et ça a très bien fonctionné par la suite sans erreur.

Je ne sais pas si c'est très propre mais je n'ai aucun problème depuis et tout semble fonctionner.

Cependant ça n'explique pas le pourquoi du comment :P

Alors,

je continue, ma découverte...... :)

Après contact, avec avencall, merci pour la dispo d'ailleures ;)

on a déjà trouvé, une partie du problème..... il s'agissait de modules non chargé, suite à la migrations du fichier modules.conf.

Il reste encore à voir pour le problème des dépendances.....

Salut,

à propos de ton problème avec les Polycom, voici quelques informations et des pistes de solution...

• dans xivo 1.0 et 1.1, les Polycom essaient d'obtenir leurs fichiers de configurations/firmware via le serveur HTTP 'de provisioning'. C'est donc dans le fichier /var/log/xivo_access_provi_http.log (et xivo_error_provi_http.log) qu'il faut regarder pour voir les requetes faites par ces téléphones. En passant, c'est normal que les requêtes pour les fichiers xxx-license et xxx-directory ainsi que les requêtes PUT mènent à des erreurs 404/405.
• aussi, la requete /list sur le serveur de provisioning (i.e. l'extrait de log dans ton premier message) n'a pas de lien avec le provisioning des Polycom. D'ailleurs, la requete provient de 127.0.0.1...

Il y a quelques différences au niveau de l'arrangement des fichiers de configuration pour les Polycom entre xivo 1.0 et xivo 1.1. Bref, normalement, pour résoudre le problème, il faut (manuellement) les forcer à effacer leurs paramètres qu'ils ont en mémoire.

La première étape est normalement de les 'power cycler' en les débranchant puis en les rébranchant.

Si ca ne règle pas le problème, via le téléphone, tu peux les remettre par défault en pesant sur la touche menu, puis 'configuration', puis 'avancé', puis rentre le mot de passe (456), puis 'paramètre de l'administration', puis 'réinit config défault'. À noter que 'réinit config défault' et différent de 'réinitialisation du téléphone', qui se trouve directement en-dessous du menu 'avancé'. Il se peut que les deux opérations soient à faire (les Polycom sont plutôt difficile à resetter complètement).

Par contre... le problème est que je ne sais pas si tu as accès à ce menu si tes téléphones ne sont pas capable de booter...

Bref, si c'est le cas, réfère toi à ce document de Polycom à la page 5 qui propose une combinaison de touche pour faire un reset de la configuration (équivalent à un 'réinitialisation du téléphone', ce n'est pas un 'factory reset', mais il se peut que ca soit suffisant pour te sortir de l'impasse).