Re: Stabilité de jitsi (débit utile)

2020-04-14 Par sujet Raphaël POITEVIN 
Pour ma part, ça tourne sur un dual core 2.7gHz, 2go de ram, buster +
LXC derrière une connexion ADSL et je suis plutôt satisfait. Quelques
bugs, mais ce sont les mêmes rencontrés lorsqu’on utilise framatalk par
exemple. Ça nous arrive d’être trois.

Raphaël

BERTRAND Joël  writes:

>   Bonsoir à tous,
>
>   Toujours dans mes problèmes d'installation de jitsi, j'observe des
> déconnexions répétées et des taux de paquets perdus assez importants,
> même dans la résolution la plus basse.
>
>   Configuration :
> - serveur (i7, 16 Go de mémoire), debian testing ;
> - une connexion VDSL2 (6Mbps en sortie) ;
> - deux utilisateurs max côté WAN.
>
>   Les logs du videobridge sont pleins de choses comme cela :
>
> JVB 2020-04-14 17:56:55.187 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32188,now=1586879815187,lsr=1537488650,dlsr=182428
> JVB 2020-04-14 17:56:55.280 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32192,now=1586879815280,lsr=1537488650,dlsr=188252
> JVB 2020-04-14 17:56:55.342 INFOS: [773]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=775852513 remainingRetries=5
> JVB 2020-04-14 17:56:55.355 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32201,now=1586879815355,lsr=1537488650,dlsr=192573
> JVB 2020-04-14 17:56:55.381 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32203,now=1586879815381,lsr=1537488650,dlsr=194172
> JVB 2020-04-14 17:56:55.642 INFOS: [773]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=775852513 remainingRetries=4
> JVB 2020-04-14 17:56:55.653 INFOS: [201]
> org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair:
> 192.168.254.1:1/udp/host -> 192.168.10.103:40804/udp/host
> (stream.RTP), failing.
> JVB 2020-04-14 17:56:55.780 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32220,now=1586879815780,lsr=1537488650,dlsr=219163
> JVB 2020-04-14 17:56:55.942 INFOS: [773]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=775852513 remainingRetries=3
> JVB 2020-04-14 17:56:55.960 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=32218,now=1586879815960,lsr=1537488650,dlsr=231134
> JVB 2020-04-14 17:56:56.053 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=34499,now=1586879816053,lsr=1537571356,dlsr=5006
> JVB 2020-04-14 17:56:56.187 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=34505,now=1586879816187,lsr=1537571356,dlsr=13414
> JVB 2020-04-14 17:56:56.242 INFOS: [773]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=775852513 remainingRetries=2
> JVB 2020-04-14 17:56:56.311 AVERTISSEMENT: [760]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=793021973
> ssrc=2297576325,rtt=34502,now=1586879816311,lsr=1537571356,dlsr=21724
> JVB 2020-04-14 17:56:56.311 INFOS: [760]
> org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
> Sending a FIR to ssrc=2297576325 remainingRetries=9
> JVB 2020-04-14 17:56:56.352 AVERTISSEMENT: [781]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=1070417375
> ssrc=775852513,rtt=32139,now=1586879816352,lsr=1537681391,dlsr=69219
> JVB 2020-04-14 17:56:56.528 AVERTISSEMENT: [781]
> org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
> invalid_rtt,stream=1070417375
> ssrc=775852513,rtt=32145,now=1586879816528,lsr=1537681391,dlsr=80374
>
>   J'ai dû rajouter une option de conf non documentée :
>
> org.ice4j.ice.harvest.ALLOWED_ADDRESSES=192.168.254.1
>
> en plus de
>
> org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.254.1
>
> pour forcer l'écoute sur cette seule adresse (sinon, avec toutes les
> interfaces réseau du serveur, c'était la fête !). Il paraît qu'on peut
> aussi écrire "ip1;ip2;ip3", mais je n'ai pas réussi à le faire
> fonctionner comme ça. Il existe l'option inverse, pour bloquer des
> interfaces spécifiques.
>
>   Constatations :
> - je ne sature _jamais_ la liaison VDSL (le débit max du à jitsi est de
> l'ordre de 320 à 350 kbps avec deux connexions côté WAN) ;
> - le traffic sur les ports UDP/1 ne sont que rarement supérieurs à
> 150kbps ;
> - le routage est correct ;
> - le serveur fait les pieds au mur (charge inférieure à 1 au moment des
> tests) ;
> - même le son est totalement moisi (en raison des pertes de paquets).
>
>

Re: Lancer une appli graphique en ssh

2020-04-14 Par sujet Pierre Malard 
À mon sens, mais je dis peut-être un connerie X11 (Xfree) doit être
présent sur les 2 postes pour que ça fonctionne.
Avec une autorisation de transfert (xhost + ou xauth) bien entendu.

> Le 14 avr. 2020 à 16:47, ajh-valmer  a écrit :
> 
> Bonjour,
> 
> Faut-il que Xfree (X11) soit lancé sur le serveur ?
> pour lancer une appli graphique via ssh ?
> 
> Ça peut venir de là...
> 
> Bonne journée.
> 

--
πr

  « On ne peut pas pousser à fond l'éducation politique et l'éducation
tout court de masses sans l'accompagner d'un développement
économique, culturel et social parallèle. »
   Romain Gary - "Les racines 
du ciel"
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Stabilité de jitsi (débit utile)

2020-04-14 Par sujet BERTRAND Joël 
Bonsoir à tous,

Toujours dans mes problèmes d'installation de jitsi, j'observe des
déconnexions répétées et des taux de paquets perdus assez importants,
même dans la résolution la plus basse.

Configuration :
- serveur (i7, 16 Go de mémoire), debian testing ;
- une connexion VDSL2 (6Mbps en sortie) ;
- deux utilisateurs max côté WAN.

Les logs du videobridge sont pleins de choses comme cela :

JVB 2020-04-14 17:56:55.187 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=32188,now=1586879815187,lsr=1537488650,dlsr=182428
JVB 2020-04-14 17:56:55.280 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=32192,now=1586879815280,lsr=1537488650,dlsr=188252
JVB 2020-04-14 17:56:55.342 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrc=775852513 remainingRetries=5
JVB 2020-04-14 17:56:55.355 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=32201,now=1586879815355,lsr=1537488650,dlsr=192573
JVB 2020-04-14 17:56:55.381 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=32203,now=1586879815381,lsr=1537488650,dlsr=194172
JVB 2020-04-14 17:56:55.642 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrc=775852513 remainingRetries=4
JVB 2020-04-14 17:56:55.653 INFOS: [201]
org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair:
192.168.254.1:1/udp/host -> 192.168.10.103:40804/udp/host
(stream.RTP), failing.
JVB 2020-04-14 17:56:55.780 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=32220,now=1586879815780,lsr=1537488650,dlsr=219163
JVB 2020-04-14 17:56:55.942 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrc=775852513 remainingRetries=3
JVB 2020-04-14 17:56:55.960 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=32218,now=1586879815960,lsr=1537488650,dlsr=231134
JVB 2020-04-14 17:56:56.053 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=34499,now=1586879816053,lsr=1537571356,dlsr=5006
JVB 2020-04-14 17:56:56.187 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=34505,now=1586879816187,lsr=1537571356,dlsr=13414
JVB 2020-04-14 17:56:56.242 INFOS: [773]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrc=775852513 remainingRetries=2
JVB 2020-04-14 17:56:56.311 AVERTISSEMENT: [760]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=793021973
ssrc=2297576325,rtt=34502,now=1586879816311,lsr=1537571356,dlsr=21724
JVB 2020-04-14 17:56:56.311 INFOS: [760]
org.jitsi.impl.neomedia.rtp.translator.RTCPFeedbackMessageSender.log()
Sending a FIR to ssrc=2297576325 remainingRetries=9
JVB 2020-04-14 17:56:56.352 AVERTISSEMENT: [781]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=1070417375
ssrc=775852513,rtt=32139,now=1586879816352,lsr=1537681391,dlsr=69219
JVB 2020-04-14 17:56:56.528 AVERTISSEMENT: [781]
org.jitsi.impl.neomedia.MediaStreamStatsImpl.log()
invalid_rtt,stream=1070417375
ssrc=775852513,rtt=32145,now=1586879816528,lsr=1537681391,dlsr=80374

J'ai dû rajouter une option de conf non documentée :

org.ice4j.ice.harvest.ALLOWED_ADDRESSES=192.168.254.1

en plus de

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.254.1

pour forcer l'écoute sur cette seule adresse (sinon, avec toutes les
interfaces réseau du serveur, c'était la fête !). Il paraît qu'on peut
aussi écrire "ip1;ip2;ip3", mais je n'ai pas réussi à le faire
fonctionner comme ça. Il existe l'option inverse, pour bloquer des
interfaces spécifiques.

Constatations :
- je ne sature _jamais_ la liaison VDSL (le débit max du à jitsi est de
l'ordre de 320 à 350 kbps avec deux connexions côté WAN) ;
- le traffic sur les ports UDP/1 ne sont que rarement supérieurs à
150kbps ;
- le routage est correct ;
- le serveur fait les pieds au mur (charge inférieure à 1 au moment des
tests) ;
- même le son est totalement moisi (en raison des pertes de paquets).

D'où ma question : pourquoi autant de perte de paquets ? Et pourquoi le
débit n'est pas plus haut ? J'avoue ne plus savoir où chercher.

Pour information, le premier client accède au serveur au travers d'un
VPN (en fait deux VPN/TAP sur UDP, bridgés avec du spanning tree). Ce
VPN fait passer de la VoIP sans aucun problème. Le second client tente
de se connecter directement côté WAN avec une connexion 3G. J'ai aussi
tenté deux clients sur le VPN.

Re: Installer manuellement pastebinit sur Debian

2020-04-14 Par sujet G2PC 
Je relance, des fois que quelqu'un saurait m'aider à installer
pastebinit via ce dépôt sur une debian stable ?

Le 31/03/2020 à 20:16, G2PC a écrit :
> L'un de vous saurait t'il installer ce dépôt manuellement, sur une
> Buster Stable ?*
> Je n'ai même pas tenté, car, je ne suis pas sur de bien savoir si il y a
> une procédure particulière.
> Je n'ai même pas vraiment consulter le contenu du dépôt.
> https://salsa.debian.org/debian/pastebinit
>
> Faut t'il utiliser un make, ou, y'a t'il une procédure propre aux
> programmes déposés sur Salsa ?
> La personne qui gère le dépôt Github m'a renvoyé sur le lien précédent,
> sans plus d'explication.
>
> Ce serait pour ajouter cette méthode à la page suivante, que j'ai créée
> suite au bogue que j'ai rencontré sur pastebinit.
> https://wiki.visionduweb.fr/index.php?title=Exporter_un_fichier_texte_vers_un_service_en_ligne_de_type_pastebin

Re: App Linŭx de cryptage

2020-04-14 Par sujet ajh-valmer 
On Monday 13 April 2020 21:41:04 Yves Rutschle wrote:
> On Wed, Apr 08, 2020 at 09:15:52AM +0200, Gabriel Moreau wrote:
> > > En faisant un tour sur OpenPGP on trouve cette page qui recense 
> > > quelques clients mail de cryptage : 
> > https://chiffrer.info/
>  
> On notera que le commentaire sur "chiffrage" est faux, ref
> l'académie française:
> https://www.dictionnaire-academie.fr/article/A9C2007
> J'aime à l'employer dans son sens cryptographique pour semer
> le trouble chez les managers.

On ne doit pas dire "cryptage" (mot anglais) mais chiffrage.

Par contre, "décryptage" est admis.

Ce sont les bizarreries de notre académie française,
censée défendre la francophonie,
qui a admis "mail" et non pas "courriel" (courrier électronique), 
expression bien française créée par les québécois.

Re: Lancer une appli graphique en ssh

2020-04-14 Par sujet ajh-valmer 
Bonjour,

Faut-il que Xfree (X11) soit lancé sur le serveur ?
pour lancer une appli graphique via ssh ?

Ça peut venir de là...

Bonne journée.

Re: [à moitié résolu] Re: Jitsi sur serveur debian/testing

2020-04-14 Par sujet Raphaël POITEVIN 
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

2020-04-14 Par sujet BERTRAND Joël 
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

2020-04-14 Par sujet Raphaël POITEVIN 
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

2020-04-14 Par sujet BERTRAND Joël 
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