Re: Jitsi sur serveur debian/testing
Bonjour à tous,
J'ai enfin réussi à configurer jitsi correctement. C'est une saleté,
mais une fois fait, ça fonctionne raisonnablement bien. Si quelqu'un
veut faire un tuto quelque part (je n'aurai pas le temps), vous pouvez
me contacter par mail.
En fait, la doc de jitsi est fausse. Totalement. But de la manoeuvre :
avoir un serveur (ici Debian testing sur amd64, un i7/4770 avec 16 Go de
RAM, sur une connexion PPPoA). En aparté, le PPPoA fonctionne mieux que
le PPPoE parce qu'il y a moins de latence. Mais ça fonctionne aussi sur
du PPPoE à partir du moment où l'on chiade la QoS.
Connexion principale : ADSL (PPPoA), modem Netopia avec QoS.
Connexion secondaire pour certains utilisateurs : OpenVPN (tap sur udp)
sur une connexion VDSL2 (PPPoE), modem CISCO avec QoS.
Les deux connexions sont natées.
Utilisation :
- possibilité pour certains utilisateurs de créer une conférence.
- les invités doivent s'authentifier. Un invité ne peut créer une
conférence.
Pour cela, il faut :
- prosody ;
- jicofo ;
- jitsi-meet (videobridge) ;
- apache
Commençons par apache. Il faut activer le module proxy. Une fois cela
fait, j'ai créé un fichier de conf pour rendre accessible
jitsi.systella.fr en http et https :
ServerName jitsi.systella.fr
Redirect permanent / https://jitsi.systella.fr/
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
ServerName jitsi.systella.fr
SSLProtocol TLSv1 TLSv1.1 TLSv1.2
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/systella.fr/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/systella.fr/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/systella.fr/chain.pem
SSLCipherSuite
"EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED"
SSLHonorCipherOrder on
Header set Strict-Transport-Security "max-age=31536000"
DocumentRoot "/usr/share/jitsi-meet"
Options Indexes MultiViews Includes FollowSymLinks
AddOutputFilter Includes html
AllowOverride All
Order allow,deny
Allow from all
ErrorDocument 404 /static/404.html
Alias "/config.js" "/etc/jitsi/meet/jitsi.systella.fr-config.js"
Require all granted
Alias "/external_api.js" "/usr/share/jitsi-meet/libs/external_api.min.js"
Require all granted
ProxyPreserveHost on
ProxyPass /http-bind http://localhost:5280/http-bind/
ProxyPassReverse /http-bind http://localhost:5280/http-bind/
RewriteEngine on
RewriteRule ^/([a-zA-Z0-9]+)$ /index.html
Un utilisateur se connecte directement en http, il est redirigé
automatiquement sur le site https, le proxy est en route et se
débrouille avec le reste de la communication. Les certificats sont ici
des certificats étoilés de letsencrypt (j'héberge mon propre DNS rien
que pour cela).
Une fois cela fait, il faut réussir à faire parler jicofo et prosody
pour l'authentification. Commençons par prosody. La configuration se
fait ici : /etc/prosody/conf.d/jitsi.systella.fr.cfg.lua. Attention,
l'ordre des lignes est importante, ça évitera se s'arracher les cheveux !
Pour éviter les erreurs SSL, rajouter au _début_ du fichier :
consider_bosh_secure = true;
https_key = "/etc/prosody/certs/jitsi.systella.fr.key";
https_certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
qui sont des liens vers les certificats du domaine (étoilés dans mon
cas, sinon, corriger pour que cela soit cohérent avec sa propre
configuration).
Ensuite, on crée les différents sous-domaines :
VirtualHost "jitsi.systella.fr"
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false
VirtualHost "guest.jitsi.systella.fr"
authentication = "internal_plain"
c2s_require_encryption = false
-> pour que les invités soient contraints à 'authentifier (forme
inv...@jitsi.systella.fr, pas de guest devant !)
Component "conference.jitsi.systella.fr" "muc"
storage = "memory"
admins = { "fo...@auth.jitsi.systella.fr" }
-> le nom de l'administrateur autorisé à créer des conférences
Component "jitsi-videobridge.jitsi.systella.fr"
component_secret = "lkjhlkjolkj"
VirtualHost "auth.jitsi.systella.fr"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
authentication = "internal_plain"
Component "focus.jitsi.systella.fr"
Re: Jitsi sur serveur debian/testing
bonjour un article sur Jitsi : https://linuxfr.org/news/organiser-des-visioconferences-de-haute-qualite-avec-le-logiciel-libre-jitsi-meet amitié socialement distancée Erwann Le 11/04/2020 à 14:49, BERTRAND Joël a écrit : Bonjour à tous, J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai besoin d'une authentification (je ne veux pas que n'importe qui puisse faire n'importe quoi sur un serveur accessible sur internet). J'ai donc installé les paquets suivants : - jicofo - jitsi-meet - jitsi-meet-prosody - jitsi-meet-web - jitsi-meet-web-config - jitsi-videobridge et configuré apache en conséquence pour qu'il réponde sur https://jitsi.systella.fr Lorsque j'entre le nom d'une conférence, il me propose d'entrer un login et un mot de passe, ce que je fais (login et mot de passe configuré dans /etc/jitsi/jicofo/config). Le couple login/mot de passe est le bon, parce que si j'en essaie un autre, je me prends directement une erreur d'authentification. Le problème est qu'avec le bon login/mot de passe, ça reste bloqué à l'étape "connecting"... Et je ne sais pas comment débuguer la chose. Dans le fichier /var/log/jitsi/jvb.log, j'ai un certain nombre de lignes qui se répètent, mais je ne sais pas si c'est relié à mon problème : JVB 2020-04-11 14:46:44.857 PRÉCIS: [308] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId IJ696-532242): JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId wrGd7-1419318): http://jabber.org/protocol/disco#info"/> JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component 'JitsiVideobridge') Processing IQ request (packetId wrGd7-1419318). JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Responding to IQ (packetId wrGd7-1419318) with: http://jabber.org/protocol/disco#info;>http://jabber.org/protocol/disco#info"/>http://jitsi.org/protocol/colibri"/>http://jitsi.org/protocol/healthcheck"/> JVB 2020-04-11 14:46:49.330 INFOS: [26] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=ddae609a65851434 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0 JVB 2020-04-11 14:46:49.363 INFOS: [26] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 33ms. Sticky failure: false JVB 2020-04-11 14:46:54.858 PRÉCIS: [543] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId IJ696-532244): JVB 2020-04-11 14:46:59.363 INFOS: [26] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=311f6df3b210cfb8 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0 JVB 2020-04-11 14:46:59.397 INFOS: [26] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 34ms. Sticky failure: false Ce que je cherche à faire : - que seul un utilisateur ayant un certain login/mot de passe puisse créer une conférence ; - que les autres utilisateurs ne peuvent l'utiliser qu'en étant authentifiés eux aussi. Toute idée sera la bienvenue. Bien cordialement, JKB
Re: [à moitié résolu] Re: Jitsi sur serveur debian/testing
BERTRAND Joël writes: > 1.0.4101-1 Oui bien je suis resté à celle-là. Je ne me suis pas penché sur le système d’authentification. > > C'est tout de même un truc tordu à configurer. Si j'ai autant de mal > après une mise à jour, je sens que je vais jeter l'éponge. Ça me > rappelle iFolder sur Sparc il y a une quinzaine d'années... Ce n’est pas hyper intuitif en effet. -- Raphaël www.leclavierquibave.fr
Re: [à moitié résolu] Re: Jitsi sur serveur debian/testing
Raphaël POITEVIN a écrit : > Je ne répons pas à la question mais par curiosité, quelle version de > jitsi-meet ? > > Car la mise à jour me propose la version 2 et plus rien ne fonctionne, > le port 4443 n’est plus ouvert comme sur la version 1.0.4101-1 1.0.4101-1 C'est tout de même un truc tordu à configurer. Si j'ai autant de mal après une mise à jour, je sens que je vais jeter l'éponge. Ça me rappelle iFolder sur Sparc il y a une quinzaine d'années...
Re: [à moitié résolu] Re: Jitsi sur serveur debian/testing
Je ne répons pas à la question mais par curiosité, quelle version de
jitsi-meet ?
Car la mise à jour me propose la version 2 et plus rien ne fonctionne,
le port 4443 n’est plus ouvert comme sur la version 1.0.4101-1
Cordialement,
Raphaël
BERTRAND Joël writes:
> Bonjour à tous,
>
> J'ai bien progressé et j'ai trouvé le responsable du problème (enfin,
> _les_ responsables).
>
> J'ai viré l'authentification dans prosody :
>
> VirtualHost "jitsi.systella.fr"
> -- enabled = false -- Remove this line to enable this host
> -- authentication = "internal_plain"
> authentication = "anonymous"
> ...
>
> Et ça fonctionne avec les ports 443/80 (pour apache, sans rediriger).
> Il suffit d'ouvrir le 4443/TCP sur le firewall et le 1/UDP. Jitsi
> fonctionne maintenant sur le LAN (au travers de VPN) et depuis le WAN
> (au travers de NAT). C'est un peu laborieux depuis mon portable de test
> qui est un core2duo de 13 ans parce que ça consomme beaucoup de
> ressources, mais malgré la vieillesse de la chose et une connexion au
> travers d'un modem 3G, ça fonctionne encore.
>
> Problème : comment mettre en place cette authentification ? Pour
> l'instant, j'ai utilisé :
> # Jitsi Conference Focus settings
> # sets the host name of the XMPP server
> JICOFO_HOST=localhost
>
> # sets the XMPP domain (default: none)
> JICOFO_HOSTNAME=jitsi.systella.fr
>
> # sets the secret used to authenticate as an XMPP component
> JICOFO_SECRET=
>
> # sets the port to use for the XMPP component connection
> JICOFO_PORT=5347
>
> # sets the XMPP domain name to use for XMPP user logins
> JICOFO_AUTH_DOMAIN=auth.jitsi.systella.fr
>
> # sets the username to use for XMPP user logins
> JICOFO_AUTH_USER=focus
>
> # sets the password to use for XMPP user logins
> #JICOFO_AUTH_PASSWORD=@FEX@kWW
> JICOFO_AUTH_PASSWORD=x
>
> # extra options to pass to the jicofo daemon
> #JICOFO_OPTS="-Dorg.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.systella.fr"
> JICOFO_OPTS=
>
> # adds java system props that are passed to jicofo (default are for home
> and logging config file)
> JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi
> -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=jicofo
> -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi
> -Djava.util.logging.config.file=/etc/jitsi/jicofo/logging.properties"
>
> dans /etc/jitsi/jicofo/config et
>
> VirtualHost "jitsi.systella.fr"
> -- enabled = false -- Remove this line to enable this host
> authentication = "internal_plain"
> -- authentication = "anonymous"
> -- Properties below are modified by jitsi-meet-tokens package config
> -- and authentication above is switched to "token"
> --app_id="example_app_id"
> --app_secret="example_app_secret"
> -- Assign this host a certificate for TLS, otherwise it would
> use the one
> -- set in the global section (if any).
> -- Note that old-style SSL on port 5223 only supports one
> certificate, and will always
> -- use the global one.
> ssl = {
> key = "/etc/prosody/certs/jitsi.systella.fr.key";
> certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
> }
> -- we need bosh
> modules_enabled = {
> "bosh";
> "pubsub";
> "ping"; -- Enable mod_ping
> }
>
> c2s_require_encryption = false
>
> Component "conference.jitsi.systella.fr" "muc"
> storage = "memory"
> --modules_enabled = { "token_verification" }
>
> admins = { "fo...@auth.jitsi.systella.fr" }
>
> Component "jitsi-videobridge.jitsi.systella.fr"
> component_secret = ""
>
> VirtualHost "auth.jitsi.systella.fr"
> ssl = {
> key = "/etc/prosody/certs/auth.jitsi.systella.fr.key";
> certificate = "/etc/prosody/certs/auth.jitsi.systella.fr.crt";
> }
> authentication = "internal_plain"
> -- authentication = "anonymous"
>
> Component "focus.jitsi.systella.fr"
> component_secret = "c"
>
> Et je sèche. Les logs ne m'apprennent rien.
>
> Bien cordialement,
>
> JKB
[à moitié résolu] Re: Jitsi sur serveur debian/testing
Bonjour à tous,
J'ai bien progressé et j'ai trouvé le responsable du problème (enfin,
_les_ responsables).
J'ai viré l'authentification dans prosody :
VirtualHost "jitsi.systella.fr"
-- enabled = false -- Remove this line to enable this host
-- authentication = "internal_plain"
authentication = "anonymous"
...
Et ça fonctionne avec les ports 443/80 (pour apache, sans rediriger).
Il suffit d'ouvrir le 4443/TCP sur le firewall et le 1/UDP. Jitsi
fonctionne maintenant sur le LAN (au travers de VPN) et depuis le WAN
(au travers de NAT). C'est un peu laborieux depuis mon portable de test
qui est un core2duo de 13 ans parce que ça consomme beaucoup de
ressources, mais malgré la vieillesse de la chose et une connexion au
travers d'un modem 3G, ça fonctionne encore.
Problème : comment mettre en place cette authentification ? Pour
l'instant, j'ai utilisé :
# Jitsi Conference Focus settings
# sets the host name of the XMPP server
JICOFO_HOST=localhost
# sets the XMPP domain (default: none)
JICOFO_HOSTNAME=jitsi.systella.fr
# sets the secret used to authenticate as an XMPP component
JICOFO_SECRET=
# sets the port to use for the XMPP component connection
JICOFO_PORT=5347
# sets the XMPP domain name to use for XMPP user logins
JICOFO_AUTH_DOMAIN=auth.jitsi.systella.fr
# sets the username to use for XMPP user logins
JICOFO_AUTH_USER=focus
# sets the password to use for XMPP user logins
#JICOFO_AUTH_PASSWORD=@FEX@kWW
JICOFO_AUTH_PASSWORD=x
# extra options to pass to the jicofo daemon
#JICOFO_OPTS="-Dorg.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.systella.fr"
JICOFO_OPTS=
# adds java system props that are passed to jicofo (default are for home
and logging config file)
JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi
-Dnet.java.sip.communicator.SC_HOME_DIR_NAME=jicofo
-Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi
-Djava.util.logging.config.file=/etc/jitsi/jicofo/logging.properties"
dans /etc/jitsi/jicofo/config et
VirtualHost "jitsi.systella.fr"
-- enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
-- authentication = "anonymous"
-- Properties below are modified by jitsi-meet-tokens package config
-- and authentication above is switched to "token"
--app_id="example_app_id"
--app_secret="example_app_secret"
-- Assign this host a certificate for TLS, otherwise it would
use the one
-- set in the global section (if any).
-- Note that old-style SSL on port 5223 only supports one
certificate, and will always
-- use the global one.
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false
Component "conference.jitsi.systella.fr" "muc"
storage = "memory"
--modules_enabled = { "token_verification" }
admins = { "fo...@auth.jitsi.systella.fr" }
Component "jitsi-videobridge.jitsi.systella.fr"
component_secret = ""
VirtualHost "auth.jitsi.systella.fr"
ssl = {
key = "/etc/prosody/certs/auth.jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/auth.jitsi.systella.fr.crt";
}
authentication = "internal_plain"
-- authentication = "anonymous"
Component "focus.jitsi.systella.fr"
component_secret = "c"
Et je sèche. Les logs ne m'apprennent rien.
Bien cordialement,
JKB
Re: Jitsi sur serveur debian/testing
Le 13/04/2020 à 18:03, BERTRAND Joël a écrit : NoSpam a écrit : Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass vers le pour jitsi qui utilise également le 80, le 443 pour *son* proxy_pass et le 4445 pour turn Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent également le 443, celle ci est en front. Je pense qu'il y a quelque chose que je ne saisis pas bien dans le fonctionnement de jitsi. Je viens de lire et relire la doc et ce n'est pas franchement plus clair. À quoi sert le proxy et de quels flux s'occupe-t-il (et sur quels ports) ? De ce que j'ai compris : - le 80 externe est redirigé sur le 443 - le 443 répond en https (jitsi-meet) - le proxy qui s'occupe du videobridge. La question qui se pose est donc la suivante : en supposant qu'on ne puisse pas rediriger le port 443 externe sur autre chose, comment organiser l'ensemble des ports pour que ça fonctionne ? Ce que je ferai: une règle PREROUTING qui redirige le 443 sur un port X sur lequel écoute ton apache en plus des ports nécessaires pour jitsi. Ensuite tu rediriges ton traffic via apache en proxy_pass vers jitsi port , Extrait de la config jitsi nginx: # this is jitsi-meet nginx module configuration # this forward all http traffic to the nginx virtual host port # and the rest to the turn server Donc le port 443 jitsi renvoi sur 127.0.0.1: (web) et 127.0.0.1:4445 (turn) Ma config court-circuite le 443 de jitsi en écoutant sur 6443 et renvoi directement sur n'ayant pas besoin du serveur turn (pas de LAN derrière) -- Daniel
Re: Jitsi sur serveur debian/testing
NoSpam a écrit : > Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache > écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont > le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass > vers le pour jitsi qui utilise également le 80, le 443 pour *son* > proxy_pass et le 4445 pour turn > > Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent > également le 443, celle ci est en front. Je pense qu'il y a quelque chose que je ne saisis pas bien dans le fonctionnement de jitsi. Je viens de lire et relire la doc et ce n'est pas franchement plus clair. À quoi sert le proxy et de quels flux s'occupe-t-il (et sur quels ports) ? De ce que j'ai compris : - le 80 externe est redirigé sur le 443 - le 443 répond en https (jitsi-meet) - le proxy qui s'occupe du videobridge. La question qui se pose est donc la suivante : en supposant qu'on ne puisse pas rediriger le port 443 externe sur autre chose, comment organiser l'ensemble des ports pour que ça fonctionne ? JKB
Re: Jitsi sur serveur debian/testing
NoSpam a écrit : > Sur la partie apache je ne peux t'aider. Ton apache ne devrait pas > écouter le 443, le 6443 comme dans mon exemple puis faire un proxy_pas > sur jitsi.systelia.fr: en fonction du hostname appelé. À partir de > là cela devrait être fonctionnel. Oui, sauf que ça, c'est impossible. J'ai des utilisateurs qui n'ont d'accessibles que les ports 80 et 443. Donc je fais avec ça. Mon apache écoute sur les ports 80 et 443. jitsi-videobridge écoute sur le 4443. Ça devrait donc fonctionner. J'ai pourtant l'impression qu'il y a un souci côté videobridge puisque : Root rayleigh:[~] > wget https://192.168.254.1:4443 --2020-04-13 15:33:23-- https://192.168.254.1:4443/ Connexion à 192.168.254.1:4443… connecté. GnuTLS: The TLS connection was non-properly terminated. Incapable d’établir une connexion SSL. Root rayleigh:[~] > wget http://192.168.254.1:4443 --2020-04-13 15:36:26-- http://192.168.254.1:4443/ Connexion à 192.168.254.1:4443… connecté. requête HTTP transmise, en attente de la réponse… Aucune donnée reçue. Nouvel essai. --2020-04-13 15:36:42-- (essai : 2) http://192.168.254.1:4443/ Connexion à 192.168.254.1:4443… connecté. requête HTTP transmise, en attente de la réponse… ^C Root rayleigh:[~] > À tout hasard, que donnent ces commandes chez toi ? En remplaçant naturellement le 4443 par 443. JKB
Re: Jitsi sur serveur debian/testing
Sur la partie apache je ne peux t'aider. Ton apache ne devrait pas
écouter le 443, le 6443 comme dans mon exemple puis faire un proxy_pas
sur jitsi.systelia.fr: en fonction du hostname appelé. À partir de
là cela devrait être fonctionnel.
Ma conf nginx:
server {
# SSL configuration
#
listen 6443 http2 ssl;
listen [::]:443 http2 ssl;
server_name webconf.tootai.net;
location / {
# jitsi-meet le port 443 est utilisé par le serveur turn bbb
ecoute dans ce cas le
# si le serveur turn est désinstallé le port 443 peut à nouveau
être utilisé par nginx
#
proxy_pass https://webconf.tootai.net:;
include include.d/proxy.conf;
}
include include.d/ssl_meetings.conf;
}
Le 13/04/2020 à 15:06, BERTRAND Joël a écrit :
NoSpam a écrit :
Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache
écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont
le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass
vers le pour jitsi qui utilise également le 80, le 443 pour *son*
proxy_pass et le 4445 pour turn
Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent
également le 443, celle ci est en front.
Effectivement, lorsque je regarde ce qu'il se passe par défaut sur les
ports utilisés pas jitsi, j'obtiens des processus qui écoutent sur :443
et :4443.
J'ai donc rajouté dans sip-communicator.properties :
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
Le videobridge écoute donc maintenant sur 4443 (et plus sur 443). Ma
configuration de mod_proxy d'apache est la suivante :
# If you want to use apache2 as a forward proxy, uncomment the
# 'ProxyRequests On' line and the block below.
# WARNING: Be careful to restrict access inside the block.
# Open proxy servers are dangerous both to your network and to the
# Internet at large.
#
# If you only want to use apache2 as a reverse proxy/gateway in
# front of some web application server, you DON'T need
# 'ProxyRequests On'.
#ProxyRequests On
#
# AddDefaultCharset off
# Require all denied
# #Require local
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing
Via: headers)
# Set to one of: Off | On | Full | Block
#ProxyVia Off
Je ne vois pas comment le proxy fait le lien entre le port 443 d'apache
et le 4443 de jitsi. J'ai l'impression qu'il manque quelque chose.
J'ajoute donc dans le fichier de conf de jitsi.systella.fr :
ProxyPass / http://localhost:4443/
ProxyPassReverse / http://localhost:4443/
Et ça ne fonctionne toujours pas mieux (mais j'ai une autre erreur) :
[Mon Apr 13 14:59:26.187471 2020] [proxy:error] [pid 1781414]
(111)Connection refused: AH00957: HTTP: attempt to connect to
127.0.0.1:4443 (localhost) failed
[Mon Apr 13 14:59:26.187493 2020] [proxy_http:error] [pid 1781414]
[client 192.168.10.103:58684] AH01114: HTTP: failed to make connection
to backend: localhost, referer: https://jitsi.systella.fr/
Effectivement, dans le fichier de conf du videobridge, j'ai écrit :
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.254.1
Je modifie donc la conf d'apache :
ProxyPass / http://192.168.254.1:4443/
ProxyPassReverse / http://192.168.254.1:4443/
Nouvelle erreur, mais j'ai l'impression que je progresse :
[Mon Apr 13 15:04:48.096005 2020] [proxy_http:error] [pid 1787092]
(20014)Internal error (specific information not available): [client
192.168.10.103:59084] AH01102: error reading status line from remote
server 192.168.254.1:4443
[Mon Apr 13 15:04:48.096045 2020] [proxy:error] [pid 1787092] [client
192.168.10.103:59084] AH00898: Error reading from remote server returned
by /
Je continue à creuser.
JKB
Re: Jitsi sur serveur debian/testing
NoSpam a écrit :
> Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache
> écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont
> le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass
> vers le pour jitsi qui utilise également le 80, le 443 pour *son*
> proxy_pass et le 4445 pour turn
>
> Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent
> également le 443, celle ci est en front.
Effectivement, lorsque je regarde ce qu'il se passe par défaut sur les
ports utilisés pas jitsi, j'obtiens des processus qui écoutent sur :443
et :4443.
J'ai donc rajouté dans sip-communicator.properties :
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
Le videobridge écoute donc maintenant sur 4443 (et plus sur 443). Ma
configuration de mod_proxy d'apache est la suivante :
# If you want to use apache2 as a forward proxy, uncomment the
# 'ProxyRequests On' line and the block below.
# WARNING: Be careful to restrict access inside the block.
# Open proxy servers are dangerous both to your network and to the
# Internet at large.
#
# If you only want to use apache2 as a reverse proxy/gateway in
# front of some web application server, you DON'T need
# 'ProxyRequests On'.
#ProxyRequests On
#
# AddDefaultCharset off
# Require all denied
# #Require local
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing
Via: headers)
# Set to one of: Off | On | Full | Block
#ProxyVia Off
Je ne vois pas comment le proxy fait le lien entre le port 443 d'apache
et le 4443 de jitsi. J'ai l'impression qu'il manque quelque chose.
J'ajoute donc dans le fichier de conf de jitsi.systella.fr :
ProxyPass / http://localhost:4443/
ProxyPassReverse / http://localhost:4443/
Et ça ne fonctionne toujours pas mieux (mais j'ai une autre erreur) :
[Mon Apr 13 14:59:26.187471 2020] [proxy:error] [pid 1781414]
(111)Connection refused: AH00957: HTTP: attempt to connect to
127.0.0.1:4443 (localhost) failed
[Mon Apr 13 14:59:26.187493 2020] [proxy_http:error] [pid 1781414]
[client 192.168.10.103:58684] AH01114: HTTP: failed to make connection
to backend: localhost, referer: https://jitsi.systella.fr/
Effectivement, dans le fichier de conf du videobridge, j'ai écrit :
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.254.1
Je modifie donc la conf d'apache :
ProxyPass / http://192.168.254.1:4443/
ProxyPassReverse / http://192.168.254.1:4443/
Nouvelle erreur, mais j'ai l'impression que je progresse :
[Mon Apr 13 15:04:48.096005 2020] [proxy_http:error] [pid 1787092]
(20014)Internal error (specific information not available): [client
192.168.10.103:59084] AH01102: error reading status line from remote
server 192.168.254.1:4443
[Mon Apr 13 15:04:48.096045 2020] [proxy:error] [pid 1787092] [client
192.168.10.103:59084] AH00898: Error reading from remote server returned
by /
Je continue à creuser.
JKB
Re: Jitsi sur serveur debian/testing
Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass vers le pour jitsi qui utilise également le 80, le 443 pour *son* proxy_pass et le 4445 pour turn Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent également le 443, celle ci est en front. Le 13/04/2020 à 14:01, BERTRAND Joël a écrit : BERTRAND Joël a écrit : NoSpam a écrit : Une idée: tu pourrais faire l'authentification avec apache .htaccess sans toucher à Jitsi. J'y ai pensé ce matin, mais ça ne me donne pas la souplesse attendue. Sinon, pas d'erreur grossière ? À propos d'erreur, en voici une qui pourrait expliquer des choses (mais je ne vois pas comment l'analyser). Lorsque je tente une création d'une conférence "famille", je me prends ceci dans les logs : [Mon Apr 13 13:49:34.933594 2020] [proxy_http:error] [pid 1602538] (20014)Internal error (specific information not available): [client 192.168.10.103:48388] AH01102: error reading status line from remote server localhost:5280, referer: https://jitsi.systella.fr/famille Bien cordialement, JKB
Re: Jitsi sur serveur debian/testing
BERTRAND Joël a écrit : > NoSpam a écrit : >> Une idée: tu pourrais faire l'authentification avec apache .htaccess >> sans toucher à Jitsi. > > J'y ai pensé ce matin, mais ça ne me donne pas la souplesse attendue. > Sinon, pas d'erreur grossière ? > À propos d'erreur, en voici une qui pourrait expliquer des choses (mais je ne vois pas comment l'analyser). Lorsque je tente une création d'une conférence "famille", je me prends ceci dans les logs : [Mon Apr 13 13:49:34.933594 2020] [proxy_http:error] [pid 1602538] (20014)Internal error (specific information not available): [client 192.168.10.103:48388] AH01102: error reading status line from remote server localhost:5280, referer: https://jitsi.systella.fr/famille Bien cordialement, JKB
Re: Jitsi sur serveur debian/testing
NoSpam a écrit : > Une idée: tu pourrais faire l'authentification avec apache .htaccess > sans toucher à Jitsi. J'y ai pensé ce matin, mais ça ne me donne pas la souplesse attendue. Sinon, pas d'erreur grossière ?
Re: Jitsi sur serveur debian/testing
Une idée: tu pourrais faire l'authentification avec apache .htaccess
sans toucher à Jitsi.
J'ai fais différemment: je n'autorise que certaines salle prédéfinies
avec accès sans mot de passe.
Le 13/04/2020 à 11:23, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 11/04/2020 à 14:49, BERTRAND Joël a écrit :
Bonjour à tous,
J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai
besoin d'une authentification (je ne veux pas que n'importe qui puisse
faire n'importe quoi sur un serveur accessible sur internet).
J'ai donc installé les paquets suivants :
- jicofo
- jitsi-meet
- jitsi-meet-prosody
- jitsi-meet-web
- jitsi-meet-web-config
- jitsi-videobridge
et configuré apache en conséquence pour qu'il réponde sur
https://jitsi.systella.fr
Alors attention, le port 443 est réservé par jitsi (dans nginx,
paragraphe stream) pour proxy_pass, Jitsi écoute le
As tu suivi leur tuto ?
https://github.com/jitsi/jicofo/blob/master/README.md#secure-domain
La réponse est oui ;-)
Mais je vais reprendre point par point le howto en question.
J'ai donc créé un fichier /etc/prosody/conf.d/jitsi.systella.fr.cfg.lua
qui contient :
VirtualHost "jitsi.systella.fr"
-- enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false
Component "conference.jitsi.systella.fr" "muc"
storage = "memory"
--modules_enabled = { "token_verification" }
admins = { "fo...@auth.jitsi.systella.fr" }
Component "jitsi-videobridge.jitsi.systella.fr"
component_secret = "xxx"
VirtualHost "auth.jitsi.systella.fr"
ssl = {
key = "/etc/prosody/certs/auth.jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/auth.jitsi.systella.fr.crt";
}
authentication = "internal_plain"
Component "focus.jitsi.systella.fr"
component_secret = ""
L'utilisateur fo...@auth.jitsi.systella.fr existe (avec le bon mot de
passe, j'ai vérifié) puisque je trouve son mot de passe dans le fichier
/var/lib/prosody/auth%2ejitsi%2esystella%2efr/accounts/focus.dat
Dans /etc/apache2/sites-enabled, j'ai un fichier jitsi.systella.fr.conf
de configuration d'apache2:
ServerName jitsi.systella.fr
Redirect permanent / https://jitsi.systella.fr/
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
ServerName jitsi.systella.fr
SSLProtocol TLSv1 TLSv1.1 TLSv1.2
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/systella.fr/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/systella.fr/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/systella.fr/chain.pem
SSLCipherSuite
"EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED"
SSLHonorCipherOrder on
Header set Strict-Transport-Security "max-age=31536000"
DocumentRoot "/usr/share/jitsi-meet"
Options Indexes MultiViews Includes FollowSymLinks
AddOutputFilter Includes html
AllowOverride All
Order allow,deny
Allow from all
ErrorDocument 404 /static/404.html
Alias "/config.js" "/etc/jitsi/meet/jitsi.systella.fr-config.js"
Require all granted
Alias "/external_api.js" "/usr/share/jitsi-meet/libs/external_api.min.js"
Require all granted
ProxyPreserveHost on
ProxyPass /http-bind http://localhost:5280/http-bind/
ProxyPassReverse /http-bind http://localhost:5280/http-bind/
RewriteEngine on
RewriteRule ^/([a-zA-Z0-9]+)$ /index.html
Le fichier de configuration
(/etc/jitsi/meet/jitsi.systella.fr-config.js) contient quant à lui :
var config = {
hosts: {
domain: 'jitsi.systella.fr',
muc: 'conference.jitsi.systella.fr'
},
bosh: '//jitsi.systella.fr/http-bind',
clientNode: 'http://jitsi.org/jitsimeet',
testing: {
enableFirefoxSimulcast: false,
p2pTestMode: false
},
desktopSharingChromeExtId: null,
desktopSharingChromeSources: [ 'screen', 'window', 'tab' ],
desktopSharingChromeMinExtVersion: '0.1',
channelLastN: -1,
enableWelcomePage: true,
enableUserRolesBasedOnToken: false,
p2p: {
enabled: true,
stunServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'stun:stun1.l.google.com:19302' },
{ urls:
Re: Jitsi sur serveur debian/testing
NoSpam a écrit :
>
> Le 11/04/2020 à 14:49, BERTRAND Joël a écrit :
>> Bonjour à tous,
>>
>> J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai
>> besoin d'une authentification (je ne veux pas que n'importe qui puisse
>> faire n'importe quoi sur un serveur accessible sur internet).
>>
>> J'ai donc installé les paquets suivants :
>>
>> - jicofo
>> - jitsi-meet
>> - jitsi-meet-prosody
>> - jitsi-meet-web
>> - jitsi-meet-web-config
>> - jitsi-videobridge
>>
>> et configuré apache en conséquence pour qu'il réponde sur
>> https://jitsi.systella.fr
>
> Alors attention, le port 443 est réservé par jitsi (dans nginx,
> paragraphe stream) pour proxy_pass, Jitsi écoute le
>
> As tu suivi leur tuto ?
>
> https://github.com/jitsi/jicofo/blob/master/README.md#secure-domain
La réponse est oui ;-)
Mais je vais reprendre point par point le howto en question.
J'ai donc créé un fichier /etc/prosody/conf.d/jitsi.systella.fr.cfg.lua
qui contient :
VirtualHost "jitsi.systella.fr"
-- enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false
Component "conference.jitsi.systella.fr" "muc"
storage = "memory"
--modules_enabled = { "token_verification" }
admins = { "fo...@auth.jitsi.systella.fr" }
Component "jitsi-videobridge.jitsi.systella.fr"
component_secret = "xxx"
VirtualHost "auth.jitsi.systella.fr"
ssl = {
key = "/etc/prosody/certs/auth.jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/auth.jitsi.systella.fr.crt";
}
authentication = "internal_plain"
Component "focus.jitsi.systella.fr"
component_secret = ""
L'utilisateur fo...@auth.jitsi.systella.fr existe (avec le bon mot de
passe, j'ai vérifié) puisque je trouve son mot de passe dans le fichier
/var/lib/prosody/auth%2ejitsi%2esystella%2efr/accounts/focus.dat
Dans /etc/apache2/sites-enabled, j'ai un fichier jitsi.systella.fr.conf
de configuration d'apache2:
ServerName jitsi.systella.fr
Redirect permanent / https://jitsi.systella.fr/
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
ServerName jitsi.systella.fr
SSLProtocol TLSv1 TLSv1.1 TLSv1.2
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/systella.fr/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/systella.fr/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/systella.fr/chain.pem
SSLCipherSuite
"EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED"
SSLHonorCipherOrder on
Header set Strict-Transport-Security "max-age=31536000"
DocumentRoot "/usr/share/jitsi-meet"
Options Indexes MultiViews Includes FollowSymLinks
AddOutputFilter Includes html
AllowOverride All
Order allow,deny
Allow from all
ErrorDocument 404 /static/404.html
Alias "/config.js" "/etc/jitsi/meet/jitsi.systella.fr-config.js"
Require all granted
Alias "/external_api.js" "/usr/share/jitsi-meet/libs/external_api.min.js"
Require all granted
ProxyPreserveHost on
ProxyPass /http-bind http://localhost:5280/http-bind/
ProxyPassReverse /http-bind http://localhost:5280/http-bind/
RewriteEngine on
RewriteRule ^/([a-zA-Z0-9]+)$ /index.html
Le fichier de configuration
(/etc/jitsi/meet/jitsi.systella.fr-config.js) contient quant à lui :
var config = {
hosts: {
domain: 'jitsi.systella.fr',
muc: 'conference.jitsi.systella.fr'
},
bosh: '//jitsi.systella.fr/http-bind',
clientNode: 'http://jitsi.org/jitsimeet',
testing: {
enableFirefoxSimulcast: false,
p2pTestMode: false
},
desktopSharingChromeExtId: null,
desktopSharingChromeSources: [ 'screen', 'window', 'tab' ],
desktopSharingChromeMinExtVersion: '0.1',
channelLastN: -1,
enableWelcomePage: true,
enableUserRolesBasedOnToken: false,
p2p: {
enabled: true,
stunServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'stun:stun1.l.google.com:19302' },
{ urls: 'stun:stun2.l.google.com:19302' }
],
preferH264: true
},
analytics: {
},
deploymentInfo: {
}
};
Jicofo tourne :
/usr/lib/jvm/java-8-openjdk-amd64/bin/java ... org.jitsi.jicofo.Main
--host=localhost --domain=jitsi.systella.fr --port=5347
Re: Jitsi sur serveur debian/testing
NoSpam a écrit : > > Le 11/04/2020 à 14:49, BERTRAND Joël a écrit : >> Bonjour à tous, >> >> J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai >> besoin d'une authentification (je ne veux pas que n'importe qui puisse >> faire n'importe quoi sur un serveur accessible sur internet). >> >> J'ai donc installé les paquets suivants : >> >> - jicofo >> - jitsi-meet >> - jitsi-meet-prosody >> - jitsi-meet-web >> - jitsi-meet-web-config >> - jitsi-videobridge >> >> et configuré apache en conséquence pour qu'il réponde sur >> https://jitsi.systella.fr > > Alors attention, le port 443 est réservé par jitsi (dans nginx, > paragraphe stream) pour proxy_pass, Jitsi écoute le > > As tu suivi leur tuto ? > > https://github.com/jitsi/jicofo/blob/master/README.md#secure-domain De mémoire, c'est ce que j'avais suivi à l'époque. Je vais reprendre du début.
Re: Jitsi sur serveur debian/testing
NoSpam writes: > Alors attention, le port 443 est réservé par jitsi (dans nginx, > paragraphe stream) pour proxy_pass, Jitsi écoute le Pour ma part, je n’ai pas mis le SSL dans le nginx de Jitsi mais dans un autre accessible depuis l’extérieur et j’ai ajouté dans /etc/jitsi/videobridge/sip-communicator.properties: org.jitsi.videobridge.TCP_HARVESTER_PORT=4443 Tout fonctionne avec la version 1.0.4101-1 de jitsi-meet Je suis bloqué pour le moment avec la version suivante. -- Raphaël www.leclavierquibave.fr
Re: Jitsi sur serveur debian/testing
Le 11/04/2020 à 14:49, BERTRAND Joël a écrit : Bonjour à tous, J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai besoin d'une authentification (je ne veux pas que n'importe qui puisse faire n'importe quoi sur un serveur accessible sur internet). J'ai donc installé les paquets suivants : - jicofo - jitsi-meet - jitsi-meet-prosody - jitsi-meet-web - jitsi-meet-web-config - jitsi-videobridge et configuré apache en conséquence pour qu'il réponde sur https://jitsi.systella.fr Alors attention, le port 443 est réservé par jitsi (dans nginx, paragraphe stream) pour proxy_pass, Jitsi écoute le As tu suivi leur tuto ? https://github.com/jitsi/jicofo/blob/master/README.md#secure-domain Lorsque j'entre le nom d'une conférence, il me propose d'entrer un login et un mot de passe, ce que je fais (login et mot de passe configuré dans /etc/jitsi/jicofo/config). Le couple login/mot de passe est le bon, parce que si j'en essaie un autre, je me prends directement une erreur d'authentification. Le problème est qu'avec le bon login/mot de passe, ça reste bloqué à l'étape "connecting"... Et je ne sais pas comment débuguer la chose. Dans le fichier /var/log/jitsi/jvb.log, j'ai un certain nombre de lignes qui se répètent, mais je ne sais pas si c'est relié à mon problème : JVB 2020-04-11 14:46:44.857 PRÉCIS: [308] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId IJ696-532242): JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId wrGd7-1419318): http://jabber.org/protocol/disco#info"/> JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component 'JitsiVideobridge') Processing IQ request (packetId wrGd7-1419318). JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Responding to IQ (packetId wrGd7-1419318) with: http://jabber.org/protocol/disco#info;>http://jabber.org/protocol/disco#info"/>http://jitsi.org/protocol/colibri"/>http://jitsi.org/protocol/healthcheck"/> JVB 2020-04-11 14:46:49.330 INFOS: [26] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=ddae609a65851434 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0 JVB 2020-04-11 14:46:49.363 INFOS: [26] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 33ms. Sticky failure: false JVB 2020-04-11 14:46:54.858 PRÉCIS: [543] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId IJ696-532244): JVB 2020-04-11 14:46:59.363 INFOS: [26] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=311f6df3b210cfb8 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0 JVB 2020-04-11 14:46:59.397 INFOS: [26] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 34ms. Sticky failure: false Ce que je cherche à faire : - que seul un utilisateur ayant un certain login/mot de passe puisse créer une conférence ; - que les autres utilisateurs ne peuvent l'utiliser qu'en étant authentifiés eux aussi. Toute idée sera la bienvenue. Bien cordialement, JKB
Re: Jitsi sur serveur debian/testing
Le 11/04/2020 à 14:49, BERTRAND Joël a écrit : > Bonjour à tous, > > J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai > besoin d'une authentification (je ne veux pas que n'importe qui puisse > faire n'importe quoi sur un serveur accessible sur internet). > > [...] Bonjour, De mon coté, j'ai opté simplement pour l'intégration faite dans Nextcloud. Certes, ce n'est pas du paquet Debian, mais c'est intégré, simple et fonctionnel. Comme j'avais déjà Nextcloud (installé via Docker), ça n'a pas été bien dur. Pour ceux qui n'ont pas NExtcloud, ça vaut peut-être le coup de tester, pour toutes les autres possibilités que ça offre : - synchro de fichier (aussi sur mobile) - partage, dont par lien (sans compte) - carnet d'adresse et agenda partagé (CalDAV, CardDAV) - un "app store" avec plein d'autres possibilités, dont Talk = Jistsi Meet
Re: Jitsi sur serveur debian/testing
Raphaël POITEVIN a écrit : > BERTRAND Joël writes: >> Lorsque j'entre le nom d'une conférence, il me propose d'entrer un login >> et un mot de passe, ce que je fais (login et mot de passe configuré dans >> /etc/jitsi/jicofo/config). Le couple login/mot de passe est le bon, >> parce que si j'en essaie un autre, je me prends directement une erreur >> d'authentification. Le problème est qu'avec le bon login/mot de passe, >> ça reste bloqué à l'étape "connecting"... Et je ne sais pas comment >> débuguer la chose. > > Est-ce que déjà dans un premier temps ça foncionne sans le système > d’authentification ? > Oui, j'avais testé lorsque j'ai commencé cette installation il y a maintenant très longtemps...
Re: Jitsi sur serveur debian/testing
BERTRAND Joël writes: > Lorsque j'entre le nom d'une conférence, il me propose d'entrer un login > et un mot de passe, ce que je fais (login et mot de passe configuré dans > /etc/jitsi/jicofo/config). Le couple login/mot de passe est le bon, > parce que si j'en essaie un autre, je me prends directement une erreur > d'authentification. Le problème est qu'avec le bon login/mot de passe, > ça reste bloqué à l'étape "connecting"... Et je ne sais pas comment > débuguer la chose. Est-ce que déjà dans un premier temps ça foncionne sans le système d’authentification ? -- Raphaël www.leclavierquibave.fr
Jitsi sur serveur debian/testing
Bonjour à tous, J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai besoin d'une authentification (je ne veux pas que n'importe qui puisse faire n'importe quoi sur un serveur accessible sur internet). J'ai donc installé les paquets suivants : - jicofo - jitsi-meet - jitsi-meet-prosody - jitsi-meet-web - jitsi-meet-web-config - jitsi-videobridge et configuré apache en conséquence pour qu'il réponde sur https://jitsi.systella.fr Lorsque j'entre le nom d'une conférence, il me propose d'entrer un login et un mot de passe, ce que je fais (login et mot de passe configuré dans /etc/jitsi/jicofo/config). Le couple login/mot de passe est le bon, parce que si j'en essaie un autre, je me prends directement une erreur d'authentification. Le problème est qu'avec le bon login/mot de passe, ça reste bloqué à l'étape "connecting"... Et je ne sais pas comment débuguer la chose. Dans le fichier /var/log/jitsi/jvb.log, j'ai un certain nombre de lignes qui se répètent, mais je ne sais pas si c'est relié à mon problème : JVB 2020-04-11 14:46:44.857 PRÉCIS: [308] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId IJ696-532242): JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId wrGd7-1419318): http://jabber.org/protocol/disco#info"/> JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQRequest() (serving component 'JitsiVideobridge') Processing IQ request (packetId wrGd7-1419318). JVB 2020-04-11 14:46:48.388 PRÉCIS: [539] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Responding to IQ (packetId wrGd7-1419318) with: http://jabber.org/protocol/disco#info;>http://jabber.org/protocol/disco#info"/>http://jitsi.org/protocol/colibri"/>http://jitsi.org/protocol/healthcheck"/> JVB 2020-04-11 14:46:49.330 INFOS: [26] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=ddae609a65851434 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0 JVB 2020-04-11 14:46:49.363 INFOS: [26] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 33ms. Sticky failure: false JVB 2020-04-11 14:46:54.858 PRÉCIS: [543] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId IJ696-532244): JVB 2020-04-11 14:46:59.363 INFOS: [26] org.jitsi.videobridge.Videobridge.log() CAT=stat create_conf,conf_id=311f6df3b210cfb8 conf_name=null,logging=false,conf_count=1,ch_count=0,v_streams=0 JVB 2020-04-11 14:46:59.397 INFOS: [26] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 34ms. Sticky failure: false Ce que je cherche à faire : - que seul un utilisateur ayant un certain login/mot de passe puisse créer une conférence ; - que les autres utilisateurs ne peuvent l'utiliser qu'en étant authentifiés eux aussi. Toute idée sera la bienvenue. Bien cordialement, JKB
