Archivo por meses: abril 2020

Instalar un servidor de videoconferencia libre, Jitsi Meet (II, Configuración de Prosody)

Una vez conocidos los componentes, veremos ahora la configuración de los mismos. Mi objetivo no es tanto dar unas instrucciones paso a paso, sino explicar que partes de la configuración sirven para qué propósito y qué opciones tenemos en función de las características que deseemos en nuestra instalación.

Prosody (autenticación de usuarios y componentes Jitsi)

Los paquetes Debian que proporciona el proyecto Jitsi crean un fichero de configuración con todo lo relacionado con Jitsi. Esto permite evitar cambios en el fichero principal y aislar la configuración propia de Jitsi de otra configuración que ya pudiéramos tener en Prosody. Entiendo, por tanto, que tendremos un fichero /etc/prosody/conf.avail/EXAMPLE.NET.cfg.lua y que habrá un enlace simbólico a este fichero desde /etc/prosody/conf.d/EXAMPLE.NET.cfg.lua. Donde EXAMPLE.NET será el dominio de nuestra instalación (p.e. meet.inittab.org).

La (falta de) autenticación de usuarios

Como ya hemos comentado, Prosody es el encargado de la autenticación de usuarios. Ésta se configura en un VirtualHost que llevará por nombre el mismo que nuestro dominio. El siguiente ejemplo permite la entrada de cualquier usuario en nuestro Jitsi Meet, es decir no realiza autenticación de usuarios:

VirtualHost "EXAMPLE.NET"
  authentication = "anonymous"
  ssl = {
    key = "/etc/prosody/certs/EXAMPLE.NET.key";
    certificate = "/etc/prosody/certs/EXAMPLE.NET.crt";
  }
  speakerstats_component = "speakerstats.EXAMPLE.NET"
  conference_duration_component = "conferenceduration.EXAMPLE.NET"
  modules_enabled = {
    "bosh";
    "pubsub";
    "ping";
    "speakerstats";
    "turncredentials";
    "conference_duration";
  }
  c2s_require_encryption = false

Antes de ver las opciones de autenticación, quería hacer dos puntualizaciones sobre la configuración creada por el paquete «jitsi-meet-prosody«. Éste genera una clave y certificado autofirmado (los que están en /etc/prosody/certs) y deshabilita la obligación de usar TLS en las conexiones de clientes (c2s_require_encryption = false). Aunque pueda parecer inseguro, la realidad es que nuestras credenciales ya viajan seguras por la conexión HTTPS con el servidor web. Si quisiéramos cubrir el tramo entre nuestro servidor web y Prosody, podríamos configurar un certificado válido, por ejemplo de Let’s Encrypt y activar (true) la opción c2s_require_encryption:

  ssl = {
    key = "/etc/letsencrypt/live/EXAMPLE.NET/fullchain.pem";
    certificate = "/etc/letsencrypt/live/EXAMPLE.NET/privkey.pem";
  }
  c2s_require_encryption = true

En posteriores artículos veremos como limitar el acceso a nuestra instancia de Jitsi Meet autenticando usuarios.

El siguiente bloque define un componente en Prosody para la creación de las salas/conferencias (muc: Multi User Conference) que usará Jitsi Meet:

Component "conference.EXAMPLE.NET" "muc"
  storage = "memory"
  modules_enabled = {
    "muc_meeting_id";
    "muc_domain_mapper";
  }
  admins = { "focus@auth.EXAMPLE.NET" }
  muc_room_locking = false
  muc_room_default_public_jids = true

En él vemos que focus@auth.EXAMPLE.NET, el usuario que usa Jicofo, será el administrador de las salas. Este bloque será modificado cuando usemos autenticación con «tokens» para gestionar los moderadores y participantes en las salas.

Otro bloque similar es el que usan los diferentes componentes de Jitsi Meet para comunicarse entre ellos (informar de que videobridges y jibris están disponibles y cual es su carga para que Jicofo decida en qué videobridge crear nuevas salas o qué Jibri se encargará de una petición nueva de grabación):

Component "internal.auth.EXAMPLE.NET" "muc"
  storage = "memory"
  modules_enabled = {
    "ping";
  }
  admins = { "focus@auth.EXAMPLE.NET" }
  muc_room_locking = false
  muc_room_default_public_jids = true

También vemos que el usuario de Jicofo es el administrador de este muc.
Los usuarios de los componentes de Jitsi Meet no se autentican en el dominio principal (EXAMPLE.NET) sino en uno propio (auth.EXAMPLE.NET). Esto permite que podamos cambiar la configuración de autenticación para los asistentes, en el dominio principal, sin afectar a la autenticación de los componentes, que se hace en el dominio auth.EXAMPLE.NET:

VirtualHost "auth.EXAMPLE.NET"
  ssl = {
    key = "/etc/prosody/certs/auth.EXAMPLE.NET.key";
    certificate = "/etc/prosody/certs/auth.EXAMPLE.NET.crt";
  }
  authentication = "internal_plain"

Una vez más vemos que los certificados usados para este VirtualHost son autofirmados y creados por la instalación del paquete «jitsi-meet-prosody«.
Si bien este dominio no tiene por qué existir en el DNS, y por tanto no disponer de un certificado válido, si será necesaria la propagación del certificado (en los directorios /usr/local/share/ca-certificates) a los servidores adicionales a éste que ejecuten videobridges, jibris o jigasi si queremos que verifiquen la identidad del servidor Prosody cuando se autentiquen en él. De otra manera tendremos que usar una opción en ellos para deshabilitar la comprobación de este certificado (TODO: aquí vendrá el enlace a esa opción cuando esté su artículo).

La autenticación en este VirtualHost, authentication = "internal_plain", se realiza de forma local por Prosody. Por este motivo los usuarios de los componentes deben ser dados de alta con la herramienta prosodyctl. Para los componentes instalados en el mismo servidor que Prosody, esto se hace automáticamente por la paquetería de Debian.
Pero si instalamos componentes en otros servidores deberemos hacerlo nosotros manualmente. Veamos como.

Prosody mantiene un directorio por cada VirtualHost que tiene autenticación "internal_plain", en nuestro caso (auth.EXAMPLE.NET) podemos verlo así:

# ls -s /var/lib/prosody/auth%2eEXAMPLE%2eNET/accounts/ -l
total 16
-rw-r----- 1 prosody prosody 40 Apr 27 18:37 focus.dat
-rw-r----- 1 prosody prosody 34 Apr 27 18:37 jvb.dat
-rw-r----- 1 prosody prosody 40 Apr 27 18:38 prometheus.dat

En el nombre del directorio (y en los ficheros que contenga) se codifican, en código porciento, los caracteres especiales como puntos o guiones. Por eso el nombre «feo» del directorio. Dentro de él vemos un fichero con cada usuario registrado en este VirtualHost. Para dar de alta un usuario, para un componente nuevo, usaremos el siguiente comando:

# prosodyctl register USUARIO auth.EXAMPLE.NET CLAVE

Queda alguna configuración más que comentar, para usuarios invitados cuando usemos autenticación de participantes, o para la autenticación especial de Jibris, pero la veremos más adelante.

Con este artículo espero que se entienda, más o menos, el papel de Prosody uniendo el resto de piezas y las posibilidades de «fortificarlo» más de querer ser extrictos con la seguridad. En el próximos artículos veremos la autenticación de usuarios mediante LDAP.

Aprovecho para recordaros que en el Playbook de Ansible de la UDIMA para Jitsi Meet todas las tareas de instalación y configuración están automatizadas y casi podríais ahorraros leer estos peñazos que escribo 🙂
$ exit

Instalar un servidor de videoconferencia libre, Jitsi Meet (I, la teoría)

Últimamente parece que las videoconferencias se han puesto de moda, como el papel higiénico. Y si bien hay muchas alternativas, la inmensa mayoría podrían no respetar tu privacidad y algunas tienen un historial de problemas de seguridad que asusta.

Por suerte hay una alternativa plenamente funcional y libre: Jitsi Meet.

No necesitas nada para usar Jitsi Meet*

* Salvo un navegador actual o su aplicación móvil/de escritorio

Si no tienes medios (servidor, ancho de banda, ganas de complicarte la vida), puedes usar su servicio público que funciona estupendamente. Es muy sencillo, simplemente dale un nombre a tu conferencia y pasa la URL resultante (por ejemplo: https://meet.jit.si/UnPingüino) a todos los participantes que quieras invitar.

Evita, eso sí, nombres fáciles o comunes («pepe», «prueba», «test») para la conferencia o puede que entre más gente de la que esperas, ya que las conferencias en el servidor público no limitan quien entra en ellas.

Pero si lo que quieres es no depender de terceros, controlar quien puede entrar en tus conferencias, o proteger tu privacidad, puedes instalar Jitsi Meet en un servidor propio. Y a eso es a lo que hemos venido.

Las piezas del puzzle

Nada es perfecto, y si en algo peca(ba) Jitsi Meet es en su documentación. Tal era la situación que salió un proyecto paralelo sólo para documentarlo: EasyJitsi
Os recomiendo echarle un ojo para tener más información.

Lo primero que debemos hacer antes de montar Jitsi Meet es entender que piezas lo componen y para que sirven cada una de ellas.

Prosody

Aunque no es parte del proyecto Jitsi, Prosody es una de las piezas más importantes de esta arquitectura. Se trata de un servidor XMPP. O en términos más claros; un servidor de mensajería instantánea.
XMPP es un grupo de protocolos que definen y permiten todas las características esperables en un servicio de mensajería: autenticación de usuarios, conversaciones con varios participantes (rooms/canales), envío de ficheros, … Es el protocolo sobre el que se construye Google Talk / Hangouts / Chat, aunque Google decidiera no usar el estándar para interoperar con otras implementaciones XMPP. Pero tranquilos, con más de 1.500 millones de usuarios de Gmail pronto tampoco tendrá que intercambiar correo con nadie que no sean ellos y podrá inventarse las extensiones que lo mejoren y liberen de viejos estándares. ¡Hala!, ya me despaché. Sigamos…

Prosody será el encargado de autenticar al resto de componentes de Jitsi Meet y, en caso de quererlo, a los usuarios que se conecten a nuestro servicio de Meet. Además gestiona la comunicación entre componentes y usuarios. Por ejemplo permitiendo que Jicofo sepa de la existencia de videobridges y Jibris en servicio.

Jicofo (Jitsi Conferenre Focus)

Es el encargado de dirigir la orquesta. Lleva el control de los recursos, decide en que videobridge se hospeda una conferencia (en función de la carga de los disponibles) o que Jibri será el que transmitirá (a Youtube, por ejemplo) o grabará la sala que lo así solicite.

Videobride

Es el encargado de recibir y hacer llegar los flujos de audio y vídeo a los participantes de una conferencia. Aunque en una conferencia de dos personas es posible que los vídeos vayan de un a otro participante directamente, sin mediar el videobridge, en cuanto los participantes son tres o más, todos envían su señal de vídeo al videobridge, que la repite al resto de participantes.

Este funcionamiento es además característica fundamental de Jitsi Meet. Los videobridge no mezclan vídeo, según llega de un cliente sale al resto. Eso se traduce en menos latencia, al no perder tiempo procesando vídeo, a costa de un uso alto (con muchos participantes) de ancho de banda. Por ejemplo, y dependiendo de la calidad que usemos, si tenemos 10 participantes, con la cámara abierta, enviando vídeo a 3Mbps, además de estar recibiendo 30Mbps estaría sacando unos 300Mbps de tráfico.

Jibri (Jitsi BRoadcasting Infrastructure)

Permite grabar, en disco o nube, o retransmitir a Youtube (por ahora) una sesión. Está compuesto por varios componentes: el propio Jibri que se conecta con prosody para recibir las órdenes de grabación de Jicofo, un navegador Chrome que se conecta como un usuario más a la sesión que grabará, y ffmpeg que se encarga de codificar el vídeo final.

Una característica a tener en cuenta de Jibri es que una sola instancia es capaz de grabar una sola sesión. Así que si quieres grabar más de una simultáneamente necesitarás tener más de un servidor/docker con Jibri.

Un servidor web y Jitsi Meet

Jitsi Meet, propiamente dicho, sería la parte frontal de todo el invento. Es una aplicación en Javascript que estará alojada en un servidor web. En el momento que escribo esto, nginx el servidor mejor soportado por Jitsi Meet para hacer este trabajo.

Otros componentes

Opcionalmente, en las últimas versiones, se puede instalar/configurar un servidor TURN/STUN para facilitar las comunicaciones de clientes detrás de NAT. De no hacerlo se pueden usar servidores públicos, en principio sin grandes compromisos (a mi entender) salvo la dependencia en la disponibilidad del servicio.

Jigasi es la última pieza del puzzle. Este componente permite integrar Jitsi Meet con una centralita de Voz IP. Ya sea para realizar llamadas desde una conferencia en curso (Meet ordena a Jigasi llamar) o para que participantes puedan unirse a una conferencia a través de una llamada telefónica (la centralita de Voz IP dirige las llamadas a Jigasi que las hace llegar a Jitsi Meet).

En la próxima entrega entraré en más detalle sobre la configuración de cada uno de ellos. Si os corre prisa echarlo a andar podéis usar su instalación docker, pegaros con sus paquetes, o probar el «playbook» de Ansible que la Universidad a Distancia de Madrid (UDIMA) ha publicado en su Github. Y sí, puede que yo tenga algo que ver con esto último 😛