lenteur acces page accueil serveur/ timeout lors des maj

[Vincent38]

bonjour
je rencontre depuis un moment un problème que je n'arrive pas a résoudre.
lorsque je tente d’accéder a la page d'accueil du serveur en http, aucun soucis c'est instantané, par contre en https, il faut une dizaine de seconde au minimum avant que je n'arrive a la demande d'identification.
aucun soucis pour lancer la console (qui pointe sur le https), par contre j'ai de temps en temps des timeout coté WUA sur certains clients (pas toujours les mémes), avec comme message d'erreur "THttpClientSocket.OpenBind(wapt1.xxx.xxx.com:443): Is a server available on this address:port? [remoteip=] [#3 Not Found]"

rien de flagrant coté logs nginx & wapt, une idée de ce qui pourrait se passer?

j'ai l'impression que c'est apparu lors de l'update de la 2.5 vers la 2.6.

merci

WAPT 2.6.1.17576
Serveur debian 12
machine de création win 11 24h2

[sfonteneau]

Si le problème est lier a https je suppose que c'est des flags manquant coter cpu.

Vous pouvez renvoyer le résultat de la commande !

Code : Tout sélectionner

cat /proc/cpuinfo |grep flags

[Vincent38]

voila :

Code : Tout sélectionner

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

il s'agit d'une VM proxmox, cpu type x86-64-V2-AES, machine type i440fx

Cdt

[sfonteneau]

il s'agit d'une VM proxmox, cpu type x86-64-V2-AES, machine type i440fx

Il serais interessant de voir si l'aes est émuler (ce qui consomme)

Vous pouvez basculer en cpu de type host pour voir si

Code : Tout sélectionner

cat /proc/cpuinfo |grep flags

renvoie toujours aes

[Vincent38]

effectivement l'aes a disparu, mais ca n'a pas résolu le pb.

Code : Tout sélectionner

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

ce problème n'existait pas (il me semble) sur la 2.5, or je n'ai pas le souvenir d'avoir changé quoi que ce soit coté VM/OS lors de la migration en 2.6.
peut-étre un problème qui s'est produit lors de la migration? surtout qu'il me semble avoir vu un truc bizarre coté certificat (un self-signed) il y a qq jours quand je cherchais la cause, mais malheureusement impossible de retrouver comment/suite a quelle commande j'avais vu ce truc bizarre
je pensait a générer un nouveau certificat pour tester, mais je n'ai pas trouvé la procédure a suivre.

[Vincent38]

chance, je me suis rappelé avoir fais une recherche google sur cette erreur, du coup j'ai pu la retrouver dans mon historique, le certif est valide jusqu'en 2033 mais ça dit "CRL validation error on certificate".
j'ai du faire une erreur de manip lors de la migration, j'ai toujours eu du mal a comprendre ces histoires de certificats

[sfonteneau]

effectivement l'aes a disparu, mais ca n'a pas résolu le pb.

aes est bien présent

Du coup ce n'est pas ça.

Un des gros changement qu'il y a eu entre 2.5 et 2.6 c'est l'authentification par certificat client.

Je ne vois pas trop ce qui pourrais ralentir le truc

[Vincent38]

ok, bon je ne vais pas m’embêter plus, vu que la debian 13 est sortie, je vais faire un backup du serveur et repartir sur une installation propre, en esperant que ca resolve le soucis

2 questions :

je commence a étre limité en place a cause de vielles maj windows encore sur le serveur, si lors du backup je ne transfère pas le dossier /var/www/waptwua/ , ca fera du ménage exact? wapt re-téléchargera ce qu'il lui faut?

dans la procédure de restauration, il est noté de faire une installation standard, mais est-il nécessaire d'exécuter le postconf.sh?
sachant qu'il faut le relancer apres import des vielles données?