Acceso lento a la página de inicio del servidor/tiempo de espera durante las actualizaciones

[Vincent38]

Hola,
llevo un tiempo con un problema que no consigo solucionar.
Cuando intento acceder a la página principal del servidor mediante HTTP, no hay problema; es instantáneo. Sin embargo, con HTTPS, tarda al menos diez segundos en llegar a la pantalla de inicio de sesión.
No hay problema al abrir la consola (que apunta a HTTPS), pero ocasionalmente se producen tiempos de espera en el lado de WUA en ciertos clientes (no siempre los mismos), con el mensaje de error "THttpClientSocket.OpenBind(wapt1.xxx.xxx.com:443): ¿Hay un servidor disponible en esta dirección:puerto? [remoteip=] [#3 No encontrado]". No

hay nada obvio en los registros de Nginx y Wapt. ¿Alguna idea de qué podría estar pasando?

Tengo la impresión de que empezó después de la actualización de la versión 2.5 a la 2.6.

Gracias.

WAPT 2.6.1.17576
Servidor Debian 12
, máquina de creación Win 11 24h2

[Sfonteneau]

Si el problema está relacionado con https, supongo que se debe a que faltan indicadores en el lado de la CPU.

¡Puedes devolver el resultado del pedido!

Código: Seleccionar todo

cat /proc/cpuinfo |grep flags

[Vincent38]

Allá :

Código: Seleccionar todo

root@WAPT1:~# cat /proc/cpuinfo |grep flags
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm cpuid_fault pti
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm cpuid_fault pti

Esta es una VM Proxmox, tipo de CPU x86-64-V2-AES, tipo de máquina i440fx

Comandante

[Sfonteneau]

Es una máquina virtual Proxmox, tipo de CPU x86-64-V2-AES, tipo de máquina i440fx

Sería interesante ver si se emula el AES (que consume energía).

Puede cambiar a la CPU de tipo host para ver si

Código: Seleccionar todo

cat /proc/cpuinfo |grep flags

siempre se refiere a aes

[Vincent38]

De hecho, el AES ha desaparecido, pero eso no ha resuelto el problema.

Código: Seleccionar todo

root@WAPT1:~# cat /proc/cpuinfo |grep flags
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat umip md_clear flush_l1d arch_capabilities
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat umip md_clear flush_l1d arch_capabilities
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml
root@WAPT1:~#

Este problema no existía (creo) en la versión 2.5, pero no recuerdo haber cambiado nada en el lado VM/OS durante la migración a 2.6.
¿Quizás hubo un problema durante la migración? Sobre todo porque creo recordar haber visto algo extraño con el certificado (uno autofirmado) hace unos días cuando buscaba la causa, pero lamentablemente no recuerdo cómo ni qué comando usé para detectarlo.
Estaba pensando en generar un nuevo certificado para fines de prueba, pero no pude encontrar el procedimiento a seguir.

[Vincent38]

Por suerte, recordé haber buscado este error en Google, así que pude encontrarlo en mi historial. El certificado es válido hasta 2033, pero muestra el mensaje "Error de validación de CRL en el certificado".
Debo haber cometido un error durante la migración; siempre me ha costado entender estos problemas con los certificados.

[Sfonteneau]

En efecto, AES ha desaparecido, pero eso no ha resuelto el problema.

AES está de hecho presente

Así que no es eso.

Uno de los grandes cambios que ocurrieron entre 2.5 y 2.6 es la autenticación del certificado de cliente.

Realmente no veo qué podría ralentizar las cosas.

[Vincent38]

Bueno, ya no me preocuparé más por eso. Como Debian 13 ya está disponible, haré una copia de seguridad del servidor y empezaré con una instalación limpia, con la esperanza de que eso resuelva el problema.

Dos preguntas:

me estoy quedando sin espacio debido a las actualizaciones antiguas de Windows que aún están en el servidor. Si no transfiero la carpeta /var/www/waptwua/ durante la copia de seguridad, ¿se limpiará todo? ¿Wapt volverá a descargar lo que necesita?

El procedimiento de restauración menciona una instalación estándar, pero ¿es necesario ejecutar postconf.sh? ¿
Sobre todo teniendo en cuenta que hay que reiniciarlo después de importar los datos antiguos?

[Vincent38]

De acuerdo, aún no he realizado una reinstalación limpia, pero curiosamente, después de actualizar el servidor WAPT ayer, el problema desapareció ; ya no hay lentitud ni tiempos de espera agotados.
¡Podemos cerrar este tema!