-
Error actualización a 6.0
-
-
Los datos de mi sistema son correctos, y actualizado mediante paquetes.
Al igual que jbarba, he instalado (en este orden) libencode-locale-perl, reinicio y el error persiste. También he instalado Encode::Locale mediante cpan, y lo mismo.
He comprobado los paquetes que comentabas al final, y tengo todos instalados. He añadido las repos non-free, actualizo, reinicio y el error persiste.Como última opción se puede hacer una instalación limpia de cero e importar la base de datos y archivos de configuración (collections, plugins, etc…), pero prefiero resolver cuál es el problema en concreto.
Un saludo, sigo cacharreando
-
-
-
-
Hola a todos,
No, Sergio, no debería ser problema.
Como os digo, repliqué todo el proceso en mi propia máquina y no me dio ningún problema. La solución sería reinstalar y migrar, como apuntó Sergio.
No llego a entender por qué os falla a vosotros, la verdad. Porque Gutiall informa de que importando tampoco parece haber mejoría.Un saludo,
Emilio. -
Hola a todos:
Debian 8.2 x64 bits instalado desde cero (virtualizado sobre VMware ESXi 5.5), y sólo restauradas la base de datos de pandora, pandora_server.conf y pandora_agent.conf de mi anterior instalación de Pandora FMS v6 (que a su vez provenía de una v5.2 actualizada a v6). No tengo plugins, ni collections, …
Paquetes de Pandora FMS instalados por dpkg desde Sourceforge (antes fue por repositorio deb).
Y el error persiste… :(… al dispararse una alarma que manda correo, vuelve a aparecer el mismo error no controlado…
¿Se os ocurre algo que pueda hacer? Por el momento voy a tener que volver a la v5.2, pero me temo que esto no se corrija y por tanto no pueda migrar a la v.6.x 🙁
-
-
Buenos días:
Gracias a todos por vuestras pruebas. Yo estoy comenzando a sospechar de “algo” relacionado con la base de datos, sobre todo después de la ultima prueba de Sergio.
Mi monitorización es muy simple, en todos los casos son módulos host alive y/o host latency, desde el agente de la misma máquina de pandora (consola, server, agente.. todo me corren en la misma máquina Debian, una VM en ESXi). Algunas otras consultas son mediante WMI (carga de CPU, memoria física libre, disco físico libre…). Sólo tengo un agente en una máquina Windows (más como prueba que otra cosa, y lo mismo lleva un tiempo sin actualizarse de versión).
Luego también recibo traps snmp.
Voy a probar, sobre mi instalación limpia de ayer, a mantener el server.conf y agent.conf, pero a borrar la BBDD y a forzar la creación de una nueva desde el asistente de instalación (install.php), a crear un agente y un módulo host alive y su correspondiente alerta y envío de mail, a ver si se reproduce el problema o no. Si se reproduce, me compraré un circo y me forraré haciendo crecer a los enanos, y si no, cada vez me olerá más a algo relacionado con la base de datos (estructura y/o registros).
Ahora os cuento…
-
Efectivamente, en una instalación limpia, creando las acciones, alertas, agentes y módulos, no da error, y el correo de alerta se genera y envía correctamente. Por tanto, debe ser algo relacionado con la base de datos.
Eso ya es un problema que se me escapa de poder acotar más.
Me veo obligado a volver a la v5.2. Espero se pueda resolver con algún update. Saludos.
-
-
En mi caso volver a la 5.1SP3 supone solicitar de nuevo la licencia de esa versión e importar la bd, que tampoco es tanto…
Así a priori no veo la relación entre las librerías de perl (la subrutina que no encuentra) y la base de datos, pero las pruebas llevan hasta ahora a que van por ahí los tiros.
A mí se me acaban las ideas… Emilio, ¿sabes si el equipo de desarrollo podría darnos alguna pista mas? Simplemente que considerasen mi sugerencia de añadir el “use Encode” en el Core.pm, por si puede ayudar en algo… que no dudo de su trabajo (excelente por cierto), sólo es una sugerencia.
Incluso podría darles acceso temporal al servidor para que echasen un ojo, lo que haga falta.
Un saludo
-
-
-
Creo que lo he solucionado. Al menos ahora tengo la versión 6.0 con las alertas totalmente funcionales. Os pongo los pasos que he seguido:
Estaba revisando la configuración de la parte web (en el propio servidor, en mi caso un Debian 7.9), y me fijo en un directorio DEBIAN que, lógicamente, pone ahí el instalador de pandora_console de esta distro. Dentro, vemos el archivo conffiles, que contiene la ruta a al php de configuración (/var/www/pandora_console/include/config.php). Esto me hizo darme cuenta de que tenía mal la ruta del directorio pandora_console. Puesto que venía de un CentOS, había puesto pandora_console debajo de /var/www/html/, para no tener que cambiar la configuración de Apache. Lo pongo bajo /var/www/ directamente (como debería ser en Debian), y cambio la configuración de Apache.
Me vuelvo a fijar en el error que lanzaba Pandora, y veo que ahora (no sé si debido a esto o no), ya no hace referencia al binario (antes lanzaba /PandoraFMS/Core.pm line 1062), sino que pone directamente el archivo donde casca (/usr/lib/perl5/PandoraFMS/Core.pm). Pruebo a meter un “use Encode” en la sección donde pone use JSON, use DBI, etc etc. Reinicio pandora_server (quito la protección frente a tormenta de eventos), lanzo una alerta manual, et voilà, ahí esta!
Esta es mi solución, no sé si os funcionaría al resto. Teniendo en cuenta los fallos míos y los cambios que he tenido que hacer, realmente sólo faltaba el use Encode en el Core.pm. Pero repito, esto es lo que me ha funcionado a mí.
Un saludo
-
Sergio… GRRAAAAACIIIIAAAAAASSSS !!!!!!
Oleeeee !!!!
Resuelto. He añadido, como bien explicas, la cadena “use Encode;” justo tras esa sección donde viene el use JSON, use DBI, …, se reinicia el server de Pandora, se fuerza alarma… y correo enviado, y no se registra error en pandora_server.log. Genial.
En mi caso, como ya anticipabas, no he tenido el problema de las rutas de la consola en Apache (había actualizado Pandora dentro del mismo servidor Debian, sin cambio de SO).
Insisto, Gracias !!!!!
Me pongo manos a la obra y vuelvo a la 6.0 !!! Y eso que no me gusta tanto la consola, porque en la actualización automática cada ‘x’ tiempo según lo definas, al refrescar se cierra el panel de los últimos eventos producidos, muy útil para ver el estado de un vistazo.
-
Me alegro de que lo tengas ya funcionando 😉
Lo que comentas del panel de los últimos eventos, si quieres repórtaselo al equipo como una sugerencia/idea, suelen tener en cuenta todas las peticiones y les ayuda a mejorar la herramienta (no es peloteo).
Yo por ejemplo, tengo una pantalla permanentemente con los módulos en crítico, y me gustaría que el filtro de arriba fuera colapsable, ya que quita mucho espacio de la pantalla…
En fin, que marco el hilo como SOLUCIONADO, no?
Gracias a todos por vuestras aportaciones, y especialmente a Emilio, que se ha tirado sus buenos ratos haciendo pruebas y pruebas.
Un saludo!
