Foro de TI tranquilo

Hola,
después de actualizar a la versión 1.5 de la consola, ya no puedo ver mis estaciones de trabajo. La actualización del servidor parece haberse realizado correctamente. Todo parece funcionar excepto que mis estaciones de trabajo ya no son visibles, lo que me impide implementar el nuevo agente.
Seguí el procedimiento paso a paso; ¿pude haber omitido algo?

viewtopic.php?f=9&t=886

Sin siquiera saber si usas Windows o Linux, será difícil ayudarte...

Lo siento,

servidor Linux Debian 9
, consola en Windows 10 Pro,
clientes Windows 7 Pro con agente 1.3

en el servidor.
Versión del servidor WAPT: 1.5.1.16,
versión del agente WAPT: 1.5.1.16,
versión de la configuración WAPT: 1.5.1.16,
versión de la implementación WAPT: 1.5.1.16,

versión de la consola: 1.5.1.16

Al instalar manualmente el nuevo agente en una máquina cliente (que no responde), este vuelve a aparecer en la consola. ¿
Es posible que el agente antiguo no se comunique con el nuevo servidor?

beemoon escribió: ↑24 de enero de 2018 - 15:02 Al instalar manualmente el nuevo agente en una máquina cliente (que no responde), vuelve a aparecer en la consola.
¿El agente antiguo no se comunica con el nuevo servidor?

No, de hecho, el nuevo agente debe ser la versión 1.5

Normalmente, cuando se inicia postconf en Linux, se inicia la migración de la base de datos MongoDB.

Estoy haciendo algunas pruebas internas más.

Volví a ejecutar el comando

sudo -u wapt python /opt/wapt/waptserver/waptserver_upgrade.py upgrade2postgres

y aquí está el resultado

volcando datos de mongodb
2018-01-24T15:59:36.855+0100 I NETWORK [initandlisten] conexión aceptada desde 127.0.0.1:41962 #1 (1 conexión ahora abierta)
2018-01-24T15:59:36.856+0100 Falló: Nombre de base de datos no válido: '/var/lib/mongodb/'
Traceback (última llamada más reciente):
Archivo "/opt/wapt/waptserver/waptserver_upgrade.py", línea 200, en
upgrade2postgres()
Archivo "/opt/wapt/waptserver/waptserver_upgrade.py", línea 158, en upgrade2postgres
jsondata = create_import_data()
Archivo "/opt/wapt/waptserver/waptserver_upgrade.py", línea 77, en create_import_data
data = subprocess.check_output('mongoexport -d wapt -c hosts --jsonArray --db=%s' % mongo_datadir,shell=True)
Archivo "/usr/lib/python2.7/subprocess.py", línea 219, en check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: El comando 'mongoexport -d wapt -c hosts --jsonArray --db=/var/lib/mongodb/' devolvió un estado de salida distinto de cero 1
2018-01-24T15:59:36.862+0100 I NETWORK [conn1] fin de conexión 127.0.0.1:41962 (0 conexiones abiertas actualmente)

Ah, cambié --dbpath a --db porque estaba causando un error

Finalmente, eliminé `--dbpath` y su parámetro porque al ejecutar `mongoexport --help`, la opción no existe.
El comando
`/usr/bin/python /opt/wapt/waptserver/scripts/postconf.py`

se ejecuta sin errores.

¡Pero aún no aparecen máquinas en la consola!

Dado que es una versión beta/RC... voy a volver a desplegar mis agentes.

Sí, ¡lo encontré!

Es el script /opt/wapt/waptserver/waptserver_upgrade.py el que tiene errores para Linux.

Esto es lo que cambié:

+ data = subprocess.check_output('mongoexport -d wapt -c hosts --jsonArray ',shell=True)^M
- data = subprocess.check_output('mongoexport -d wapt -c hosts --jsonArray --dbpath=%s' %

+ jsondata = json.loads(data)^M
- jsondata = json.load()^M

Ahora el comando
sudo -u wapt python /opt/wapt/waptserver/waptserver_upgrade.py upgrade2postgres/opt/wapt/waptserver/waptserver_up

ya no da un error y muestra correctamente las exportaciones; los PC están de vuelta en la consola.