Error de resignación de paquete (transición WAPT 2.0)

[Cristóbal0110]

Hola,


finalmente me decidí a actualizar mi versión WAPT 1.8.2 Enterprise a WAPT 2.0 Enterprise.

Estoy usando dos servidores:
- Un servidor de prueba con Debian 10.
- Un servidor de producción con Windows Server.

Lógicamente, comencé actualizando el servidor de prueba con Debian.
Después de encontrar algunos problemas durante la actualización, logré actualizar a WAPT 2.0.

Luego vino la firma de los hosts y paquetes.
No hubo problemas con los hosts.
Sin embargo, la consola mostró varios errores de "tiempo de espera de lectura" para varios paquetes (algunos de los cuales eran de más de 4 GB).
Entonces, seguí el método de la documentación e intenté firmar directamente desde el servidor usando una línea de comandos.
Varios paquetes que inicialmente fallaron se firmaron correctamente, excepto tres que eran de 5.7 GB, 5.7 GB y 6.6 GB.
El error que se muestra es: BadZipFile('Número mágico incorrecto para el encabezado del archivo').

Con frecuencia me he encontrado con este error al desplegar paquetes grandes, y logré evitarlo modificando el parámetro `client_max_body_size` en el archivo `/etc/nginx/sites-enabled/wapt.conf` del servidor. El archivo sigue configurado correctamente (no ha cambiado tras la actualización), pero el problema persiste.

¿Tienen alguna sugerencia sobre cómo puedo desplegar estos paquetes sin tener que recompilar e instalar una nueva versión, lo que activaría una actualización en todas las máquinas (y dado el tamaño del paquete, realmente no quiero llegar a ese extremo)?

Gracias.

[Cristóbal0110]

Continuando con la saga:

Intenté actualizar el servidor WAPT a Windows 2.0.

Tras la actualización, no pude iniciar la consola...

Tuve que restaurar la máquina virtual y empezar de nuevo, y quién sabe por qué... Funcionó a la segunda...

Sin embargo, no pude volver a firmar los paquetes a través de la consola (recibí un mensaje de "Tiempo de espera de lectura agotado" en cuanto un paquete superó los 400 MB)...
Y, por supuesto, no hay documentación que explique cómo volver a firmarlos desde el servidor (Windows), a diferencia de Linux...

Esperaba tener problemas durante la actualización a la versión 2.0, pero no hasta este punto... Estoy bastante decepcionado...

No es muy fiable.

Así que probablemente tendré que pagar por tickets de soporte solo para actualizar a la versión 2.0... Y, francamente, me parece un poco excesivo...

Una solución más económica sería reconstruir los paquetes que no funcionan... Llevará tiempo, pero probablemente eso es lo que haré para evitar gastar 900 € en tickets de soporte...

[jacky35]

En el archivo Nginx - /etc/nginx/sites-enabled/wapt.conf
Tenga cuidado, hay dos lugares donde se encuentra client_max_body_size.

No sé por qué Tranquil IT no establece esta opción en client_max_body_size 0 de manera predeterminada;
Pero ciertamente hay una razón.

Investigué un poco para descubrir por qué mi paquete windows10-upgrade-data no se cargaba correctamente al servidor WAPT

Jacky

Hola,


finalmente decidí tomarme el tiempo para actualizar mi versión de WAPT de 1.8.2 Enterprise a WAPT 2.0 Enterprise.

Uso dos servidores:
- Un servidor de prueba que ejecuta Debian 10.
- Un servidor de producción que ejecuta Windows Server.

Lógicamente, comencé actualizando el servidor de prueba que ejecuta Debian.
Después de encontrar algunos problemas durante la actualización, actualicé con éxito a WAPT 2.0.

Luego vino la firma de los hosts y paquetes.
No hubo problemas con los hosts.
Sin embargo, a través de la consola, obtuve varios errores de "tiempo de espera de lectura" en varios paquetes (los más grandes de los cuales eran, en algunos casos, más de 4 GB).
Entonces seguí el método de la documentación al intentar una firma directamente desde el servidor usando un comando.
Varios paquetes que inicialmente fallaron fueron firmados con éxito, excepto tres de ellos, que eran 5.7 GB; 5.7 GB y 6.6 GB.
El error que se muestra es: BadZipFile('Número mágico incorrecto para el encabezado del archivo').

A menudo me he encontrado con este error al desplegar paquetes grandes, y pude evitarlo editando el parámetro client_max_body_size en el archivo /etc/nginx/sites-enabled/wapt.conf del servidor. El archivo sigue configurado correctamente (no ha cambiado después de la actualización), pero el problema persiste.

¿Tienen alguna sugerencia sobre cómo puedo desplegar estos paquetes sin tener que recompilar e instalar una nueva versión, lo que activaría una actualización en todas las máquinas (y dado el tamaño del paquete, realmente no quiero llegar a ese extremo)?

Gracias.

[Cristóbal0110]

¡Gracias por tu respuesta, jacky35!

Sí, en Linux pude editar ese archivo y ambas ubicaciones.

En Windows, encontré un archivo (con una sola ubicación) donde se encontraba ese parámetro.

Sin embargo, no cambia nada; la consola WAPT parece tener una verdadera aversión a los paquetes grandes.
No lo entiendo; seguro que no soy el único con paquetes de más de 400 MB...

Bueno, da igual, tendré que hacer lo que dije y recompilar los 11 paquetes que no funcionan...

[dcardón]

A menudo me he encontrado con este error al desplegar paquetes grandes, y pude evitarlo editando el parámetro `client_max_body_size` en el archivo `/etc/nginx/sites-enabled/wapt.conf` del servidor. El archivo sigue configurado correctamente (no ha cambiado después de la actualización), y el problema persiste.

Si client_max_body_size en nginx no se ha modificado después de la actualización, es porque no has lanzado el postconf y por lo tanto no has seguido el procedimiento hasta el final (client_max_body_size aún no está parametrizado en la plantilla nginx).

[dcardón]

En el archivo Nginx - /etc/nginx/sites-enabled/wapt.conf
Tenga cuidado, hay dos lugares donde puede encontrar client_max_body_size.

No sé por qué Tranquil IT no establece esta opción en client_max_body_size 0 por defecto;
pero ciertamente hay una razón.

El servidor necesita almacenar los archivos en caché. Permitir subidas ilimitadas corre el riesgo de saturar el espacio temporal en disco o la RAM disponible, lo que podría provocar un ataque DoS. Así que sí, hay una razón. Sin embargo, esta configuración se almacenará en waptserver.ini en el futuro y se usará automáticamente en el archivo de configuración de nginx.

[dcardón]

Gracias por tu respuesta, jacky35!

Sí, en Linux pude editar ese archivo y esas dos ubicaciones.

En Windows, encontré un archivo (con una sola ubicación dentro del archivo) donde se encontraba ese parámetro.

Sin embargo, no cambia nada; la consola WAPT parece ser completamente alérgica a los paquetes grandes.
No lo entiendo; seguramente no soy el único con paquetes de más de 400 MB...

Bueno, no importa, tendré que hacer lo que dije y recompilar los 11 paquetes que no funcionan...

Nota: Nginx necesita tener suficiente espacio en disco disponible para almacenar los fragmentos de archivos durante la carga.

[dcardón]

Hola Christophe,

Así que probablemente tendré que pagar por tickets de soporte solo para actualizar a la versión 2.0... Y, francamente, me parece un poco excesivo...

Una solución más económica sería reconstruir los paquetes defectuosos... Llevará tiempo, pero probablemente eso es lo que haré para evitar gastar 900 € en tickets de soporte...

Información privilegiada: Tranquil IT es una editorial de software, no una empresa de servicios de TI. No intentamos impulsar la venta de tickets; no es nuestra principal fuente de ingresos (ni mucho menos). Y quiero destacar que la mayoría de las solicitudes de soporte que recibimos están documentadas en la documentación de WAPT, así que, en cierto modo, se trata más bien de ahorrar tiempo a los clientes (el tiempo es oro). Intentamos abarcar la mayor cantidad de escenarios posibles en el proceso de actualización (y nos lleva mucho tiempo), pero no podemos dar cuenta de todas las rarezas que la gente comete en su red (la creatividad, ya sea necesaria o superflua, no tiene límites) ni de todos los errores que se cometen al seguir los procedimientos.

Atentamente,

Denis Cardón

[Cristóbal0110]

Buen día,

Si el client_max_body_size en nginx no se ha modificado después de la actualización, es porque no ha ejecutado el postconf y, por lo tanto, no ha seguido el procedimiento hasta el final (el client_max_body_size aún no está parametrizado en la plantilla de nginx).

Si estamos hablando del comando /opt/wapt/waptserver/scripts/postconf.sh, sí, lo lancé y seguí el procedimiento hasta el final.
Por lo tanto, he leído (aún dentro del procedimiento) la siguiente instrucción justo encima del comando:

Si ha personalizado la configuración de Nginx, no responda Sí cuando postconf le solicite configurar Nginx

Como ese fue el caso, no respondí "Sí" y, por lo tanto, probablemente esa es la razón por la que la configuración de nginx no cambió en mi caso...

Nota: Nginx necesita tener suficiente espacio en disco disponible para almacenar los fragmentos del archivo durante la carga.

Si hablamos del espacio restante en el servidor Windows en el que está instalado WAPT, hay 443 GB de espacio libre... No creo, por tanto, que esta sea la causa del problema.

Hola Christophe,

Información privilegiada: Tranquil IT es una empresa editora de software, no una empresa de servicios de TI. No intentamos impulsar la venta de tickets; no es nuestra principal fuente de ingresos (ni mucho menos). Y quiero enfatizar que la mayoría de las solicitudes de soporte que recibimos están documentadas en la documentación de WAPT, así que, en cierto modo, se trata más de ahorrar tiempo a los clientes (el tiempo es dinero)... Intentamos cubrir tantos escenarios como sea posible en los procesos de actualización (y nos lleva mucho tiempo), pero no podemos prever todas las cosas extrañas que la gente hace en su red (la creatividad, ya sea necesaria o superflua, no tiene límites) ni todos los errores que la gente comete al seguir los procedimientos.

Saludos cordiales,

Denis Cardon

No considero que mis paquetes sean nada inusuales. Son bastante básicos, y cuando quiero implementar un paquete de AutoCAD en masa (y no puedo ser el único en esta situación), me parece lógico que el paquete supere los 400 MB... En cuanto a seguir el procedimiento, puedo decir que lo seguí al pie de la letra (y en el caso del servidor Windows, dos veces, como expliqué antes). No me importa pagar tickets de soporte si tengo que reinstalar un servidor y encuentro un problema, o si intento crear un paquete que no funciona. Pero tener que pagar soporte para una actualización que no funciona, aunque haya seguido la documentación correctamente, no me parece correcto. Es solo mi opinión.


Cristóbal.

[vcardón]

Sin embargo, la documentación indica claramente que un servidor Linux es más adecuado para producción.

Escribo esto para recalcar a quienes lean esta publicación que usar un servidor WAPT con Windows es una cortesía, no un compromiso.

La solución a tu problema está en tu primera publicación. ¿Por qué no usar Debian 10 para tu entorno de producción, como ya lo haces con éxito en tu entorno de preproducción? Si la gerencia insiste en usar un sistema operativo compatible para tu entorno de producción, Red Hat será tu mejor opción.