En esta serie de artículos veremos como instalar Jitsi Meet en un VPS y como optimizar la configuración para mejorar la seguridad, configurar la grabación de las videoconferencias y integrar el sistema con Moodle.

Creo que muchos de ustedes ya conocen Jitsi Meet. Es uno de los sistemas de videoconferencias Open Source más utilizados. Si no estoy equivocado Sangoma Meet se basa en él como la parte audio y video de Element, el cliente de videochat basado en Matrix.

En este primer articulo veremos como instalar Jitsi Meet en Debian 9 y como afinar la configuración de la pantalla de inicio. Antes de empezar abordamos el tema de su arquitectura:

Los clientes se conectan a la pagina Web del sistema, que se basa es un servidor Nginx y de ahí interactúan con Jitsi-Meet que es la aplicación Web, escrita en Javacript, que permite interactuar con los usuarios. Luego está el servidor XMMP Prosody que es la pieza que se encarga de manejar toda la comunicación interna de las distintas aplicaciones y, al mismo tiempo, si así se ha configurado, la autenticación de los usuarios para que puedan utilizar el servicio.

La configuración del sistema termina con Jicofo que es el servidor de señalización que permite la comunicación entre los usuarios y el componente VideoBridge que es la ultima pieza de una instalación estándar de Jitsi Meet. VideoBridge se encarga de distribuir el flujo media entre todos los participantes actuando como un SFU (Selective Forwarding Unit): un SFU es un servidor que recibe el flujo video de todos los participantes y decide que flujo reenviar y a cual participante. El servidor no mezcla los flujos videos y no aplica efectos antes de reenviarlos; se limita a recibir y reenviar los paquetes. Cualquier tipo de trabajo sobre los distintos flujos se realiza a nivel de dispositivo. Es un sistema bastante costoso en términos de CPU y de banda de los dispositivos pero no del servidor.

Otro dato importante: si los participantes a la videoconferencias son solamente dos, el sistema no activa VideoBridge sino crea una comunicación punto-a-punto directamente con WebRTC. Desde el tercer participante en adelante se activa el componente VideoBridge; por este motivo es importante probar siempre la configuración final con más de dos participantes para asegurarse que todo el sistema funcione correctamente. Se crea el VPS, personalmente he utilizado VPSDime que con 7 dólares/mes permite tener un servidor de 4 vCPU, 6GB de RAM y 30 GB de disco.

A este VPS he asociado el subdominio meet.voztovoice.org Su IP publica es: 209.151.149.74

Se accede vía SSH y se actualiza el sistema:

apt update

apt upgrade

Se reinicia el sistema:

reboot

Volvemos a acceder al servidor y instalamos el servidor Web Nginx y algunos paquetes requeridos:

apt install gnupg2 nginx-full apt-transport-https curl -y

luego la versión 8 de Java IMPORTANTE: Jitsi Meet no funciona, todavía, con otras versiones:

apt install openjdk-8-jdk -y

Se configura el hostname meet.voztovoice.org:

hostnamectl set-hostname meet.voztovoice.org

Se modifica la configuración del archivo:

nano /etc/hosts

añadiendo la siguiente linea:

209.151.149.74 meet.voztovoice.org meet

Se guardan los cambios y se envía un ping al subdominio para ver si todo está bien:

ping meet.voztovoice.org

Se pasa a la configuración del cortafuegos abriendo todos los puertos que se van a necesitar. Se utilizará ufw que hay que instalar:

apt install ufw -y

luego

ufw allow 22/tcp

ufw allow 80/tcp

ufw allow 443/tcp

ufw allow 3478/udp

ufw allow 5349/tcp

ufw allow 10000/udp

Se activa:

ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y

Firewall is active and enabled on system startup

Jistsi Meet puede trabajar con un Certificado auto firmado pero no es lo recomendado ya que desde las aplicaciones móviles no será posible utilizar la aplicación ya que requieren un certificado de una autoridad de certificación reconocida. Es por eso que se instala un certificado de Let’s Encrypt:

apt install snapd -y

snap install core

snap refresh core

snap install --classic certbot

ln -s /snap/bin/certbot /usr/bin/certbot

Se para Nginx que debería estar corriendo:

systemctl stop nginx

Se crea el certificado con el siguiente comando:

certbot certonly
 

Se selecciona la opción 2:

se indica un correo electrónico:

se aceptan los términos de la licencia de uso:

No se da, o si quieren dan, el consenso para compartir el correo indicado con la Elctronic Frontier Foundation:

se indica el nombre del subdomibio por el cual se está creando el certificado:

Después de unos segundos aparecerá este bloque indicando que el certificado se ha creado con éxito. Ya se puede reiniciar nginx:

systemctl start nginx

Se instala la llave y los repositorios de Jitsi Meet:

curl https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'

echo 'deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list

IMPORTANTE: antes de instalar Jitsi Meet asegurarse que nginx no está configurado para escuchar sobre el puerto 443. Si así fuera se crearía un conflicto con el servidor TURN y su configuración no sería procesada creando problemas a la hora de utilizar el sistema:

Ya se puede instalar Jitsi Meet:

sudo apt update

apt install jitsi-meet -y

El sistema nos solicitará el nombre del dominio/subdominio asociado al servidor:

y que tipo de certificados queremos utilizar (los nuestros creados con Let’s Encrypt):

Nos solicitará la localización de la clave secreta:

y del certificado:

Terminada la instalación, reiniciamos nuevamente Nginx para que coja la nueva configuración creada a lo largo de la instalación de Jitsi Meet:

systemctl restart nginx

si aparece este error:

Job for nginx.service failed because the control process exited with error code.

See "systemctl status nginx.service" and "journalctl -xe" for details.

Eso se debe a que la versión de Nginx presente en Debian 9 no soporta TLS versión 1.3 Eso no afecta mínimamente el funcionamiento de Jitsi Meet. Se corrige con:

nano /etc/nginx/sites-enabled/meet.voztovoice.org.conf

modificando esta linea:

ssl_protocols TLSv1.2 TLSv1.3;

para que quede:

ssl_protocols TLSv1.2;

Se guardan los cambios y se inicia nuevamente nginx:

systemctl start nginx

Si todo sale bien ya se debería poder acceder a nuestro servidor de Jitsi:

https://meet.voztovoice.org

Con esta configuración cualquiera puede acceder a nuestro servidor y crear conferencias ya que no se ha configurado todavía ningún tipo de autenticación. Eso será tema del próximo articulo. Mientras afinamos la configuración utilizando un logo personalizado y un favicon también personalizado. Con un programa tipo WinSCP cargamos en la carpeta /etc/jitsi/meet/ el logo.png y el favicon.ico. Sacamos una copia del CSS del sitio web y lo copiamos en la misma carpeta con un nombre diferente:

cp /usr/share/jitsi-meet/css/all.css /etc/jitsi/meet/meetvoztovoice.css

Modificamos nuevamente la configuración de Nginx:

nano /etc/nginx/sites-enabled/meet.voztovoice.org.conf

después de este bloque:

gzip on;

gzip_types text/plain text/css application/javascript application/json image/x-icon application/octet-stream application/wasm;

gzip_vary on;

gzip_proxied no-cache no-store private expired auth;

gzip_min_length 512;

añadimos:

location = /css/all.css {

alias /etc/jitsi/meet/meetvoztovoice.css;

}

location = /images/favicon.ico {

alias /etc/jitsi/meet/favicon.ico;

}

location = /images/watermark.png {

alias /etc/jitsi/meet/logo.png;

}

Guardamos los cambios y reiniciamos Nginx:

systemctl restart nginx

Ahora que hemos modificado el logo hay que asociar a ese logo un enlace que no sea https://jitsi.org. Este cambio se realiza modificando este archivo (linea 116):

nano /usr/share/jitsi-meet/interface_config.js

cambiando:

JITSI_WATERMARK_LINK: 'https://jitsi.org',

con

JITSI_WATERMARK_LINK: 'https://www.voztovoice.org',

Se guardan los cambios y se accede nuevamente a la pagina de nuestro JitsiMeet:

Ya aparece el icono y el logo de la empresa. Si miran el estado del servidor prosody:

systemctl status prosody

aparecerán dos errores:

Unable to load module 'storage_memory': /usr/lib/prosody/modules/mod_storage_memory.lua: No such file or directory

y:

certmanager: SSL/TLS: Error initialising for localhost: invalid protocol (tlsv1_2+)

que se corrigen con:

cd /usr/lib/prosody/modules/

wget https://hg.prosody.im/prosody-modules/raw-file/tip/mod_storage_memory/mo...

y:

nano /etc/prosody/conf.avail/meet.voztovoice.org.cfg.lua

modificando la linea 20:

protocol = "tlsv1_2+";

para que quede:

protocol = "tlsv1_2";

Se guardan los cambios y se reinicia prosody:

systemctl restart prosody

Por hoy es todo.