henri-allauch

Je ne suis pas du tout spécialiste de Haproxy, mais en suivant le tutoriel de @mprinfo je suis arrivé à une configuration qui fonctionne. J'accède par: https://domlinux.MonDomaine.fr/domocharts/index.php aux graphiques ... SI cela peut t'aider .... #************************************************************************************ # Déclaration HAPROXY #************************************************************************************ global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners stats timeout 30s user haproxy group haproxy daemon maxconn 2048 # Default SSL material locations ca-base /etc/ssl/certs crt-base /etc/ssl/privatte # Default ciphers to use on SSL-enabled listening sockets. # For more information, see ciphers(1SSL). This list is from: # https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ # An alternative list with additional directives can be obtained from # https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 tune.ssl.default-dh-param 2048 defaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http # ------------------------------------------------------------------------ # - H T T P # ------------------------------------------------------------------------ frontend http- option http-keep-alive compression algo gzip compression type text/html text/plain text/css application/x-javascript bind *:80 mode http option httplog acl letsencrypt-acl path_beg /.well-known/acme-challenge/ #********************************** # Define hosts http MonDomaine #********************************** acl domlinux hdr(host) domlinux.MonDomaine.fr #********************************** # Forcer Redirection vers Https #********************************** redirect scheme https if !{ ssl_fc } domlinux use_backend letsencrypt-backend if letsencrypt-acl default_backend backend_DEFAULT # ------------------------------------------------------------------------ # - H T T P S # ------------------------------------------------------------------------ frontend https-in bind *:443 ssl crt /etc/haproxy/certs/ no-sslv3 mode http option httplog acl letsencrypt-acl path_beg /.well-known/acme-challenge/ #******************************************************** # Define hosts https MonDomaine #******************************************************** acl domlinux hdr(host) domlinux.MonDomaine.fr #******************************************************** # Use backend #******************************************************** use_backend backend_DOMLINUX if domlinux use_backend letsencrypt-backend if letsencrypt-acl default_backend backend_DEFAULT # ------------------------------------------------------------------------ # - Define backend # ------------------------------------------------------------------------ #--------------------- Backend pour le renouvellement du certificat letsencrypt backend letsencrypt-backend server letsencrypt 127.0.0.1:8888 #--------------------- Backend pour DOMLINUX backend backend_DOMLINUX mode http option httpchk option forwardfor except 127.0.0.1 http-request add-header X-Forwarded-Proto https if { ssl_fc } server DOMLINUX 192.168.82.8:5080 maxconn 15 #--------------------- Backend pour DEFAULT backend backend_DEFAULT http-request deny

S'il s'agit bien de Monsieur Boris D. : on peut dire qu'il à toujours été très correct, compréhensif, et compétent. Je luis souhaite plein de succès en récupérant les clients Que domotique-store à fait fuir.

Ton message est rassurant Merci beaucoup. Oui je suis d'accord en médecine c'est pareil avec les moyens actuels on trouve toujours un truc qui va pas. Je vais arrêter de me poser des questions à ce sujet et dormir sur mes deux oreilles ...

Merci moi non plus je ne connais pas les détails du réseau. Mais je suis tombé sur ce problème par hasard . Le fonctionnement global du réseau n'est pas perturbé. Je changerai bien mes centaines de mètres de câbles ... mais c'est un chantier colossal.

Effectivement j'ai des câbles installés il y a plusieurs années et il ne sont certainement pas au top. Mais je ne comprend pas : quand la machine dit X paquets dropped. C'est sur des paquets qui lui sont destinés ou sur l'ensemble des paquets du réseau. Je penche pour le cas 1 puisque ifconfig dit RX donc reçus Dans ce cas avec un cat 6 je ne devrais plus ( ou moins ) avoir d'erreur en connexion directe sur la box. ( La livebox 6 Orange peut elle être en cause ?)

Ce n'est pas un sujet Fibaro ... Je cherche à comprendre des erreurs réseau ethernet du style : ipconfig RX packets 41716140 bytes 40711495202 (40.7 GB) RX errors 0 dropped 1879 overruns 0 frame 0 soit 4,5 paquets en erreur pour 100.000 24 heures après boot : 5.279 erreurs pour 116.916.068 0,0045 4,5 pour 100.000 Cela se produit : Sur une machine ubuntu quelle que soit la carte réseau (Interne ou par usb-ethernet) en 1000 Mb/s -> Donc c'est pas la carte C'est idem avec une machine ubuntu sur un pc hp pavilon usb-ethernet en 1000 Mb/s -> Donc c'est pas la machine C'est idem si la connexion ethernet est directe sur la box sans passer par les switch et avec un cable neuf. Donc c'est pas le cable ni le switch Par contre la commande ipconfig sur un autre serveur ubuntu dans ce réseau mais en 100 Mb/s RX packets 276648494 (316.1 GB) RX errors 0 dropped 0 overruns 0 frame 0 Pourquoi des erreurs seulement en réception ? je n'ai pas d'idée pour poursuivre mes essais. Est-ce un taux normal d'erreur pour 1Gb/s ? je n'ai pas d'éléments de comparaison à part un Imac mais sur puce M3 et ifconfig ne me fourni pas les infos TX RX paquets Si quelq'un à un conseil je suis preneur. Merci

@Lazer Merci pour tes vœux et pour ton implication sur ce forum À mon tour je présente tous mes vœux pour une heureuse année à toutes et tous les membres de ce forum N'hésites pas à nous annoncer les besoins financiers 2025 pour la vie de ce forum.

Bon bout d'an

OK je me doutais un peu que sur des QA complexes on mesure mal les conséquences Oui ça fonctionne Peut être insérer une fonction appelée de l'extérieur qui le fait planter c'est aussi une solution Merci de tes réponse j'abandonne le re onInit()

j'ai un QA qui modifie plusieurs autres autres QA pour ce changement de serveur donc c'est plus pratique que de tous les faire les uns après les autres via l'interface graphique Pour les autres QA je charge la variable ( or oninit() ) donc au moment ou j'en ai besoin -> pas de PB j'ai pas besoin de les réinitialiser. Mais pour domochart je ne souhaite pas faire de modifications Je me demandais au niveau du QA si le fait de le relancer par son onInit() c'était comme quand il est relancé par la HC3 Le processus unix de ce QA est peut être killé puis relancé quand c'est le système HC3 qui le réinitialise alors que relancer le onInit() on reste dans le même processus .

J'ai besoin de changer de serveur php+sql je lance un php qui dump la base graph puis la charge sur un nouveau serveur, ça c'est OK. Ensuite j'ai besoin d'informer domochart de ce changement Pour éviter les fausses manip, et pour le faire à distance : Je pense utiliser un truc du genre : -- réinitialiser domochart pour recharger la variable Adresse serveur Php self.QA_Domochart = 128 fibaro.call(self.QA_Domochart, "setVariable", "NAS_Address", 192.168.1.66) fibaro.setTimeout(1*1000, function() fibaro.call (self.QA_Domochart, "onInit") end) A part la perte d'une mise à jour, @lazer vois-tu un autre risque et plus généralement : réinitialiser un QA de cette manière est-ce acceptable ?

Mais bonne nouvelle à 8h27 c'est reparti

Ce matin à 7H00 le QA à signalé que demain jeudi nous serons en Jour BLANC ( comme aujourd'hui ) mais depuis le site RTE est en erreur : Code de statut HTTP = 502

Quand je dépose en déchèterie un appareil électrique HS je récupère systématiquement à minima le câble d'alim avec sa prise pour 2 raisons Il me servira sûrement pour un bricolage. Cela évite que "certains employés de la déchèterie" remettent le produit en circuit au marché aux puces.

Le site fonctionne de nouveau ...