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 :
<VirtualHost *:80>
ServerName jitsi.systella.fr
Redirect permanent / https://jitsi.systella.fr/
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
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"
<Directory "/usr/share/jitsi-meet">
Options Indexes MultiViews Includes FollowSymLinks
AddOutputFilter Includes html
AllowOverride All
Order allow,deny
Allow from all
</Directory>
ErrorDocument 404 /static/404.html
Alias "/config.js" "/etc/jitsi/meet/jitsi.systella.fr-config.js"
<Location /config.js>
Require all granted
</Location>
Alias "/external_api.js" "/usr/share/jitsi-meet/libs/external_api.min.js"
<Location /external_api.js>
Require all granted
</Location>
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
</VirtualHost>
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
invite@jitsi.systella.fr, pas de guest devant !)
Component "conference.jitsi.systella.fr" "muc"
storage = "memory"
admins = { "focus@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"
component_secret = "sldkjflsdkjf"
On relance prosody. On regarde dans les logs qu'il n'y a pas d'erreur
(du type erreur SSL ou autre). Puis on attaque jicofo. Ça se passe ici :
/etc/jitsi/jicofo. Deux fichiers de configuration.
Le premier s'appelle bêtement config. Il lui faut les informations
suivantes :
JICOFO_HOST=localhost
JICOFO_HOSTNAME=jitsi.systella.fr
JICOFO_SECRET=dlfkgjldfkjglj
#(celui qui est défini dans le fichier de prosody à la suite de
#Component "focus.jitsi.systella.fr")
JICOFO_PORT=5347
JICOFO_AUTH_DOMAIN=auth.jitsi.systella.fr
# la doc de jisti est fautive, il _faut_ le auth devant le domaine.
JICOFO_AUTH_USER=focus
JICOFO_AUTH_PASSWORD=lksdjfljf
# password de l'utilisateur focus@auth.jitsi.systella.fr
JICOFO_OPTS=
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"
Le second fichier est sip-communicator.properties. Il faut qu'il
contienne :
org.jitsi.jicofo.auth.URL=XMPP:auth.jitsi.systella.fr
org.jitsi.jicofo.ALWAYS_TRUST_MODE_ENABLED=true
La première ligne concerne le domaine d'authentification (à ne pas
mettre dans JICOFO_OPTS= de l'autre fichier, ça ne fonctionne pas chez
moi pour une raison mystérieuse), la seconde éviter à java de hurler sur
les certificats letsencrypt.
On redémarre jicofo. On regarde dans les logs. Si tout se passe
normalement, on crée les utilisateurs dans prosody (avec prosodyctl
register, voir la page man de l'outil).
On va maintenant configurer ce qui se trouve dans /etc/jitsi/meet. Un
seul fichier, dans mon cas jitsi.systella.fr-config.js. Ce fichier doit
contenir :
var config = {
hosts: {
domain: 'jitsi.systella.fr',
anonymousdomain: 'guest.jitsi.systella.fr',
authdomain: 'auth.jitsi.systella.fr',
muc: 'conference.jitsi.systella.fr'
},
bosh: '//jitsi.systella.fr/http-bind',
clientNode: 'http://jitsi.org/jitsimeet',
testing: {
enableFirefoxSimulcast: false,
p2pTestMode: false
},
resolution: 720,
constraints: {
video: {
aspectRatio: 16 / 9,
height: {
ideal: 480,
max: 720,
min: 240
}
}
},
desktopSharingChromeSources: [ 'screen', 'window', 'tab' ],
desktopSharingChromeMinExtVersion: '0.1',
channelLastN: -1,
enableTcc: true,
enableRemb: false,
useIPv6: true,
requireDisplayName: true,
enableWelcomePage: true,
defaultLanguage: 'fr',
enableUserRolesBasedOnToken: false,
// J'ai invalidé le p2p, mais ça fonctionne aussi avec cela
p2p: {
enabled: false,
stunServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'stun:stun1.l.google.com:19302' },
{ urls: 'stun:stun2.l.google.com:19302' }
],
},
analytics: {
},
}
};
On est presque à la fin, reste ce qui se trouve dans
/etc/jitsi/videobridge. Là, deux fichiers : config et
sip-communicator.properties.
Config contient dans mon cas :
JVB_HOSTNAME=jitsi.systella.fr
JVB_HOST=
JVB_PORT=5347
JVB_SECRET= (voir Component "jitsi-videobridge.jitsi.systella.fr" dans
la conf de prosody)
JVB_OPTS="--apis=xmpp,rest"
JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi
-Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge
-Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi
-Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties"
Et le dernier pour la route : sip-communicator.properties. Ce truc
s'occupe entre autre du NAT.
org.jitsi.videobridge.AUTHORIZED_SOURCE_REGEXP=focus@auth.jitsi.systella.fr/.*
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.254.1
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=(ip publique)
org.ice4j.ice.harvest.ALLOWED_ADDRESSES=192.168.254.1
Attention. Pour que cela fonctionne, j'ai dû ouvrir dans le firewall
les ports suivants (eth1 est l'interface WAN)
# jitsi
[0:0] -A INPUT -i eth1 -p udp -m udp --dport 10000 -j ACCEPT
[0:0] -A INPUT -i eth1 -p tcp -m tcp --dport 4443 -j ACCEPT
[0:0] -A OUTPUT -o eth1 -p udp -m udp --sport 10000 -j ACCEPT
Mais cela ne suffit pas à avoir de la video fluide. Il faut encore
bricoler avec la QoS. Pour cela, il faut utiliser la table mangle
d'iptables.
[0:0] -A OUTPUT -p udp --sport 10000 -j TOS --set-tos Minimize-Delay
[0:0] -A OUTPUT -p udp --sport 10000 -j DSCP --set-dscp-class AF41
Et naturellement, il convient de réserver de la bande dans les
différents modems pour cette classe AF41. On pourrait être plus violent
et lui coller une classe EF.
JKB
Reply to: