Slow access to the server homepage/timeout during updates

[Vincent38]

Hello,
I've been having a problem for a while now that I can't seem to solve.
When I try to access the server's homepage via HTTP, there's no problem; it's instantaneous. However, with HTTPS, it takes at least ten seconds before I even get to the login prompt.
There's no problem launching the console (which points to HTTPS), but I occasionally get timeouts on the WUA side on certain clients (not always the same ones), with the error message "THttpClientSocket.OpenBind(wapt1.xxx.xxx.com:443): Is a server available on this address:port? [remoteip=] [#3 Not Found]".

There's nothing obvious in the Nginx and Wapt logs. Any idea what could be happening?

I have the impression that it started after the update from version 2.5 to 2.6.

Thank you

WAPT 2.6.1.17576
Debian 12 server
, creation machine Win 11 24h2

[sfonteneau]

If the problem is related to https, I suppose it's due to missing flags on the CPU side.

You can send back the order result!

Code: Select all

cat /proc/cpuinfo |grep flags

[Vincent38]

There :

Code: Select all

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

This is a Proxmox VM, CPU type x86-64-V2-AES, machine type i440fx

Commander

[sfonteneau]

It's a Proxmox VM, CPU type x86-64-V2-AES, machine type i440fx

It would be interesting to see if the AES is emulated (which consumes power).

You can switch to host-type CPU to see if

Code: Select all

cat /proc/cpuinfo |grep flags

always refers to aes

[Vincent38]

Indeed, the AES has disappeared, but that hasn't solved the problem.

Code: Select all

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:~#

This problem did not exist (I think) on version 2.5, but I don't remember changing anything on the VM/OS side during the migration to 2.6.
Perhaps there was a problem during the migration? Especially since I seem to remember seeing something strange with the certificate (a self-signed one) a few days ago when I was looking for the cause, but unfortunately I can't remember how or which command I used to see that strange thing.
I was thinking of generating a new certificate for testing purposes, but I couldn't find the procedure to follow.

[Vincent38]

Luckily, I remembered doing a Google search for this error, so I was able to find it in my history. The certificate is valid until 2033, but it says "CRL validation error on certificate."
I must have made a mistake during the migration; I've always had trouble understanding these certificate issues.

[sfonteneau]

Indeed, AES has disappeared, but that hasn't solved the problem.

aes is indeed present

So that's not it.

One of the big changes that occurred between 2.5 and 2.6 is client certificate authentication.

I don't really see what could slow things down.

[Vincent38]

Okay, well, I won't bother with it any longer. Since Debian 13 is out, I'll back up the server and start with a clean install, hoping that will resolve the issue.

Two questions:

I'm starting to run out of space because of old Windows updates still on the server. If I don't transfer the /var/www/waptwua/ folder during the backup, will it clean things up? Will Wapt re-download what it needs?

The restore procedure mentions doing a standard installation, but is it necessary to run postconf.sh?
Especially since it needs to be restarted after importing the old data?

[Vincent38]

Okay, I haven't done a clean reinstall yet, but strangely enough, after updating the WAPT server yesterday, the problem disappeared ; no more slowness or timeouts.
We can close this topic!