Accesso lento alla homepage del server/timeout durante gli aggiornamenti

[Vincent38]

Ciao,
ho un problema da un po' di tempo che non riesco a risolvere.
Quando provo ad accedere alla homepage del server tramite HTTP, non ci sono problemi; è istantaneo. Tuttavia, con HTTPS, ci vogliono almeno dieci secondi prima che arrivi alla schermata di login.
Non ci sono problemi ad avviare la console (che punta a HTTPS), ma occasionalmente ricevo timeout sul lato WUA su alcuni client (non sempre gli stessi), con il messaggio di errore "THttpClientSocket.OpenBind(wapt1.xxx.xxx.com:443): Is a server available on this address:port? [remoteip=] [#3 Not Found]".

Non c'è nulla di evidente nei log di Nginx e Wapt. Qualche idea su cosa potrebbe succedere?

Ho l'impressione che sia iniziato dopo l'aggiornamento dalla versione 2.5 alla 2.6.

Grazie.

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

[sfontenau]

Se il problema è legato a https, suppongo che sia dovuto alla mancanza di flag sul lato CPU.

Puoi rispedire indietro il risultato dell'ordine!

Codice: Seleziona tutto

cat /proc/cpuinfo |grep flags

[Vincent38]

Là :

Codice: Seleziona tutto

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

Questa è una VM Proxmox, tipo CPU x86-64-V2-AES, tipo macchina i440fx

Comandante

[sfontenau]

È una VM Proxmox, tipo di CPU x86-64-V2-AES, tipo di macchina i440fx

Sarebbe interessante vedere se viene emulato l'AES (che consuma energia).

Puoi passare alla CPU di tipo host per vedere se

Codice: Seleziona tutto

cat /proc/cpuinfo |grep flags

si riferisce sempre ad aes

[Vincent38]

In effetti, l'AES è scomparso, ma questo non ha risolto il problema.

Codice: Seleziona tutto

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

Questo problema non esisteva (credo) nella versione 2.5, ma non ricordo di aver modificato nulla sul lato VM/OS durante la migrazione alla versione 2.6.
Forse c'è stato un problema durante la migrazione? Soprattutto perché mi sembra di ricordare di aver notato qualcosa di strano con il certificato (un certificato autofirmato) qualche giorno fa, mentre cercavo la causa, ma purtroppo non ricordo come o quale comando ho usato per vedere quella cosa strana.
Stavo pensando di generare un nuovo certificato a scopo di test, ma non sono riuscito a trovare la procedura da seguire.

[Vincent38]

Per fortuna, mi ricordavo di aver cercato questo errore su Google, quindi sono riuscito a trovarlo nella cronologia. Il certificato è valido fino al 2033, ma viene visualizzato il messaggio "Errore di convalida CRL sul certificato".
Devo aver commesso un errore durante la migrazione; ho sempre avuto difficoltà a comprendere questi problemi relativi ai certificati.

[sfontenau]

In effetti, AES è scomparso, ma questo non ha risolto il problema.

aes è effettivamente presente

Quindi non è questo.

Uno dei grandi cambiamenti avvenuti tra la versione 2.5 e la 2.6 è l'autenticazione del certificato client.

Non vedo davvero cosa potrebbe rallentare le cose.

[Vincent38]

Okay, beh, non me ne occuperò più. Dato che Debian 13 è uscito, farò un backup del server e inizierò con un'installazione pulita, sperando che questo risolva il problema.

Due domande:

sto iniziando a rimanere senza spazio a causa dei vecchi aggiornamenti di Windows ancora presenti sul server. Se non sposto la cartella /var/www/waptwua/ durante il backup, verrà eliminata? Wapt scaricherà di nuovo ciò di cui ha bisogno?

La procedura di ripristino menziona un'installazione standard, ma è necessario eseguire postconf.sh?
Soprattutto perché deve essere riavviato dopo l'importazione dei vecchi dati?

[Vincent38]

Ok, non ho ancora effettuato una reinstallazione completa, ma stranamente, dopo aver aggiornato il server WAPT ieri, il problema è scomparso ; niente più rallentamenti o timeout.
Possiamo chiudere questa discussione!