Anomalie #5810
ferméImpossible de se connecter à des salons visio.chapril le 2 mars autour de 19 h
90%
Description
Anomalie observée sur Android le 2 mars 2022 entre 18 h 45 et 19 h 15 environ. Le message en pj n'arrêtait pas de s'afficher. Observé sur plusieurs salons visio.chapril et sur plusieurs appareils mobiles.
J'arrive à me connecter au moment où j'écris, mais je signale au cas où.
Fichiers
Mis à jour par davidd09 . il y a environ 2 ans
Le problème semble toujours présent sur mobile (constaté par mes soins):
- système /e/ (android 11) sur Fairphone
- client "natif" jisti-meet ( venant de F-droid )
Une recherche dans les forums jitsi paraît incriminer 'prosody', en particulier les certificats.
https://community.jitsi.org/t/jitsi-meet-in-android-11-stopped-connecting/98291/25
Si je regarde la configuration de prosody sur "allo", les certificats son obsolètes depuis 2021 :
cat auth.visio.chapril.org.crt | openssl x509 -noout -enddate
notAfter=Mar 24 20:22:38 2021 GMT
cat visio.chapril.org.crt | openssl x509 -noout -enddate
notAfter=Mar 24 20:22:38 2021 GMT
Mis à jour par Pierre-Louis Bonicoli il y a presque 2 ans
- Statut changé de Nouveau à En cours de traitement
- Assigné à
François Poulainsupprimé - % réalisé changé de 0 à 90
davidd09 . a écrit :
1. leurs chemins complets sont indiqués dansLe problème semble toujours présent sur mobile (constaté par mes soins):
- système /e/ (android 11) sur Fairphone
- client "natif" jisti-meet ( venant de F-droid )Une recherche dans les forums jitsi paraît incriminer 'prosody', en particulier les certificats.
https://community.jitsi.org/t/jitsi-meet-in-android-11-stopped-connecting/98291/25
Si je regarde la configuration de prosody sur "allo", les certificats son obsolètes depuis 2021 :
/etc/prosody/conf.d/visio.chapril.org.cfg.lua
:
/etc/prosody/certs/visio.chapril.org.crt
/etc/prosody/certs/auth.visio.chapril.org.crt
2. La commande prosodyctl check certs
les mentionne (et indique qu'ils sont expirés)*
3. Les trois modules activés sont bosh
( allows to use HTTP to communicate with XMPP servers) , ping
et pubsub
. L'option consider_bosh_secure
du module bosh n'est pas activée, il ne semble pas qu'il y ait de reverse proxy gérant les certificats et placé devant le prosody.
maine
ou coon
suivant le serveur porteur de l'IP flottante):
- le port UDP 10000 est NATé vers la VM allo (
/etc/firehol/firehol.conf
) - mais pas le port 4443 qui est pourtant également ouvert en entrée (
/etc/firehol/services/jitsi.conf
).
Les deux ports sont ouverts au niveau de la VM allo (/etc/firehol/services/jitsi.conf). Mais aucun service n'écoute sur le port TCP 4443.
tcp 0 0 0.0.0.0:5222 0.0.0.0:* LISTEN 874/lua5.2 tcp 0 0 0.0.0.0:5269 0.0.0.0:* LISTEN 874/lua5.2 tcp 0 0 0.0.0.0:5280 0.0.0.0:* LISTEN 874/lua5.2 tcp 0 0 127.0.0.1:5347 0.0.0.0:* LISTEN 874/lua5.2
- le port 5280 est exposé à travers le nginx de la VM allo
/etc/nginx/sites-available/visio.chapril.org
:proxy_pass http://localhost:5280/http-bind
- je ne suis pas certain que 5222 et 5269 soient utilisés ?
6. les logs de l'application Android Jitsi indiquent :
E JitsiMeetSDK: [features/base/lib-jitsi-meet] Failed to load config from https://visio.chapril.org/config.js?room=XXXX Error(Error) { "message": "TypeError: cannot write property 'sourceNameSignaling' of undefined", "code":"EUNSPECIFIED", "stack":"index.android.bundle:37:1105\nindex.android.bundle:1593:322\np@index.android.bundle:1593:2026\nindex.android.bundle:1593:1775\np@index.android.bundle:1593:2026\ni@index.android.bundle:1593:2441\nindex.android.bundle:1593:2584\nu@index.android.bundle:85:157\nindex.android.bundle:85:866\nindex.android.bundle:92:1662\nk@index.android.bundle:92:498\nw@index.android.bundle:92:888\ncallReactNativeMicrotasks@index.android.bundle:92:3055\nvalue@index.android.bundle:45:2868\nindex.android.bundle:45:960\nvalue@index.android.bundle:45:2504\nvalue@index.android.bundle:45:919\nvalue@[native code]\nvalue@[native code]" }
Le flag sourceNameSignaling
est activé dans le fichier /etc/jitsi/meet/visio.chapril.org-config.js
:
config.flags.sourceNameSignaling = true;
J'ai modifié le fichier de configuration ainsi /etc/jitsi/meet/visio.chapril.org-config.js
et l'erreur du client Android a disparu:
diff --git a/jitsi/meet/visio.chapril.org-config.js b/jitsi/meet/visio.chapril.org-config.js index e10399a..f127c4f 100644 --- a/jitsi/meet/visio.chapril.org-config.js +++ b/jitsi/meet/visio.chapril.org-config.js @@ -67,6 +67,12 @@ var config = { // callStatsThreshold: 5 // enable callstats for 5% of the users. }, + flags: { + sourceNameSignaling: true, + sendMultipleVideoStreams: true, + receiveMultipleVideoStreams: true, + }, + // Enables reactions feature. // enableReactions: false, @@ -981,8 +987,3 @@ var config = { // no configuration value should follow this line. }; - -/* eslint-enable no-unused-vars, no-var */ -config.flags.sourceNameSignaling = true; -config.flags.sendMultipleVideoStreams = true; -config.flags.receiveMultipleVideoStreams = true;
Mis à jour par Pierre-Louis Bonicoli il y a presque 2 ans
- les certificats autosignés et expirés ne semblent pas être un problème
- les renouveler n'en serait pas un non plus, la commande
prosodyctl
semble permettre de le faire, aux animsys de décider :) - il y a un problème avec le port TCP 4443 sur le bastion : est ce qu'il faut le fermer ou activer le NAT ?
- il me semble que le diff entre
/etc/jitsi/meet/ori
et/etc/jitsi/meet/visio.chapril.org-config.js
pourrait être réduit. - la syntaxe du fichier de configuration
/etc/jitsi/meet/visio.chapril.org-config.js
pourrait être vérifiée (un check icinga, un hook de pre-commit ?).
Mis à jour par davidd09 . il y a presque 2 ans
J'ai renouvelé les certificats avec prosodyctl generate <vhost>, tout semble fonctionner.
En ce qui concerne le port 4443, il n'est plus utilisé dans les versions récentes de jitsi-meet (Cf. https://community.jitsi.org/t/port-4443-connection-refused/29527/2 ), on peut donc le fermer coté bastion, je pense. Je l'ai mis en commentaires dans la config. de firehol
En ce qui concerne les autres ports :
D'après : https://community.jitsi.org/t/ports-5222-5269-5280-5347/36862/2
5222/tcp is for XMPP client connections. You need to accessble by jitsi-videobridge and jicofo. Web clients don’t use this (see below)
=> doit être ouvert pour les clients "lourds"
5269/tcp is the XMPP server. It doesn’t need to be open.
=> En local uniquement
5280/tcp is XMPP BOSH. It doesn’t need to be accessible because clients using BOSH (such as web clients) connect through the proxy on 443/tcp*
=> En local uniquement
5347/tcp is the XMPP component port. It needs to be accessible only by jicofo, not publically.
=> En local uniquement
En résumé, les ports 5269, 5280 et 5347 n'ont pas besoin d'être ouverts sur le bastion. Le port 5222 doit être accessible depuis "l'extérieur"
Mis à jour par Pierre-Louis Bonicoli il y a presque 2 ans
Suite à un échange avec David, je précise le commentaire précédent :)
- Par "réduire le diff" je voulais dire :
- sauvegarder le fichier
/etc/jitsi/meet/visio.chapril.org-config.js
- copier le fichier pointé par le lien symbolique
/etc/jitsi/meet/ori
vers/etc/jitsi/meet/visio.chapril.org-config.js
./etc/jitsi/meet/ori
est un lien symbolique vers/usr/share/jitsi-meet-web-config/config.js
, ce dernier appartient lui-même au paquet Debianjitsi-meet-web-config
. - modifier appliquer le minimum de changements requis au fichier
/etc/jitsi/meet/visio.chapril.org-config.js
- ainsi la différence entre le fichier fourni par le packaging et la configuration appliquée est minimale. Quand le packaging est mis à jour, il est ainsi plus facile d'identifier les paramètres par défaut modifiés et les nouveaux paramètres ajoutés dans le fichier par les packagers. Il faut alors mettre à jour notre fichier et pour chacun de ces paramètres, se poser la question d'utiliser la valeur par défaut ou non.
- sauvegarder le fichier
- La syntaxe du fichier peut être vérifiée à l'aide d'un linter javascript ou via l'exécution de
nodejs /etc/jitsi/meet/visio.chapril.org-config.js
(la 1ère option me semble plus adéquate).
Mis à jour par davidd09 . il y a 10 mois
- Statut changé de En cours de traitement à Fermé
Le problème ne s'est pas représenté. D'après les quelques traces dans les LOGs, ce pouvait être un problème de performance sur l'ancienne infrastructure.