Foro de TI tranquilo

¿Se puede utilizar esta versión en producción en un servidor nuevo?

Hola,
utilizamos Wapt 1.5.1.8 en producción en el servidor Debian de nuestros clientes

Hubert.

En algunos equipos donde desinstalé el agente antiguo y reinstalé el nuevo, el botón "Buscar actualizaciones" o "Aplicar actualizaciones" aparece deshabilitado y no entiendo por qué.

¿Alguna idea?
Gracias.

guigeek escribió: ↑5 de diciembre de 2017 - 17:06 En algunos ordenadores donde desinstalé el agente antiguo y reinstalé el nuevo, el botón "Buscar actualizaciones" o "Aplicar actualizaciones" aparece atenuado y no entiendo por qué.

¿Alguna idea?
Gracias.

De hecho, todos los clientes instalados aparecen como "inalcanzables"...

Tengo la sensación de que el problema está en el WebSocket... en los registros de WaptService del cliente aparece esto:
Error en la conexión de socket io ConnectionError (código de estado inesperado (401 No autorizado)).

Los permisos en el servidor en /var/www/wapt son correctos.
Estoy un poco desconcertado

Aquí estoy de nuevo, enviando spam.
Al parecer, falta un archivo:
/var/www/wapt-host/45EC4D56-BA0D-3CFF-6F8C-8C1E31C46A3A.wapt" falló (2: No existe el archivo o directorio).

¿Cómo puedo recrearlo?

Hola,

el mensaje "(código de estado inesperado (401 No autorizado))" significa que la conexión WebSocket no está autorizada porque el equipo no está registrado en el servidor o la clave pública almacenada en la base de datos del servidor no coincide con la clave privada del equipo.

De hecho, en la versión 1.5, el equipo crea un par de claves pública/privada (usando su FQDN como objeto) y envía el certificado X.509 con la clave pública al servidor durante el registro inicial (al instalar el cliente waptagent.exe).

Este par de claves se utiliza para autenticar los inventarios enviados por el cliente y para autenticar las conexiones WebSocket.

Si el par de claves se genera después de que se haya iniciado el servicio waptservice, el equipo aparecerá desconectado hasta que se reinicie waptservice.

Si el equipo está registrado incorrectamente o no está registrado en absoluto, puede intentar ejecutar "wapt-get register -ldebug" en el cliente con privilegios de administrador y reiniciar el servicio ("net stop"). "waptservice" "net start waptservice"

Si la clave no coincide, puede intentar eliminar el cliente del inventario (esto eliminará el certificado/clave pública del cliente en cuestión de la base de datos) y volver a registrar el cliente.

Si aún así no funciona, es un error...

----

Respecto al segundo punto, el mensaje
"/var/www/wapt-host/45EC4D56-BA0D-3CFF-6F8C-8C1E31C46A3A.wapt" falló (2: No existe tal archivo o directorio)"
es normal siempre que no hayas creado una configuración para la máquina en la consola.

La máquina intenta recuperar su configuración de destino con cada actualización.

En wapt 1.3, los paquetes de máquina se nombraban con el FQDN de la máquina.

En wapt 1.5, los paquetes de máquina se nombran por defecto con el UUID de la máquina.

Un script te permite recrear paquetes de máquina en masa si es necesario. (/opt/wapt/waptserver/scripts/migrate-hosts.py)

Gracias,
ejecuté `wapt-get register` en modo depuración y todo salió bien. Dice "éxito". Pero en el servidor, sigo sin tener el UUID.wapt...

Para el repositorio CentOS Wapt 1.5, los paquetes están disponibles aquí: https://wapt.tranquil.it/centos7/wapt-1.5/
Requieren PostgreSQL 9.4 y Nginx

: https://www.wapt.fr/fr/doc-1.5/Installa ... _wapt.html

guigeek escribió: ↑6 de diciembre de 2017 - 10:20 a. m. Gracias,
ejecuté `wapt-get register` en modo depuración y todo salió bien. Dice "éxito". Pero en el servidor, sigo sin tener el UUID.wapt...

Al parecer, tras una actualización del servidor, el problema parece haberse resuelto...