Danielside

informática softwarelibre divagaciones música

Videoconferencias libres y seguras con Jitsi

Llevaba mucho tiempo detrás de realizar una instalación funcional de Jitsi en un servidor VPS y después de varias guias que no terminan de funcionar y de una documentación oficial pobre, por fin he encontrado un muy buena.

Como no soy mucho de enlazar cosas que encuentro, ni mucho de menos de copiar contenido original (aunque en este caso solo por traducirlo sí estaría bien) voy a redondear la excelente guía para instalar Matrix, Riot y Jitsi de Matrix.org con unos cuantos briconsejos, y finalmence ofrezco algunos datos experimentales de como han ido las pruebas con un servidor de 1GB de RAM y 1 CPU Intel Xeon 2.3Ghz.

La guía es esta: Running your own secure communication service with Matrix and Jitsi y puedes seguirla en vídeo o la puedes leer. Recomiendo el vídeo porque aclara algunas cosas. Está orientada a montar un servidor de chat (Matrix) con su cliente web (Riot) y Jitsi y además a conectar Matrix con Jitsi de manera que puedes iniciar salas de vídeo directamente desde Riot. Si optas por esta opción me gustaría aclarar dos cosas:

  • No esperes que funcionen las (video)llamadas uno a uno en Riot porque en este caso Matrix no usa Jitsi para iniciarlas sino que lo hace directamente usando una cosa llamada TURN. Hay que configurar Synapse (la implementación de referencia de Matrix) con TURN para que funcionen las llamadas 1:1, aunque esto no lo he intentando.
  • Para que Riot use Jitsi tienes que estar en una sala de más de dos miembros. Es entonces cuando se activa el widget. Pero sale en un trozo de pantalla muy pequeñito dentro de la sala. Yo realmente no le veo gran utilidad a esto pudiendo usar la interfaz de Jitsi directamente.

Las notas que quiero dar en esta entrada se refieren a la instalación de Jitsi concretamente. Me voy a orientar a las cosas que faltan. Evidentemente faltan en la guía no porque sean unos dejados, sino porque el autor va al grano y el resto de configuraciones depende de gustos e infraestructuras, yo me voy a centrar en Debian 10.

Configuración inicial del servidor

Para la configuración básica y medianamente segura tienes las excelentes guías de DigitalOcean.

PATH

Debe haber algún bug en Debian 10 que hace que no encuentre algunos comandos que están en /usr/sbin. En una instalación limpia el PATH no incluye esa ruta, de manera que tendrás que incluirla en /etc/profile. Esto será importante para la parte donde se configura Jitsi con Let’s Encrypt. Certbot y UFW también instalan sus binarios aquí, por lo que definitivamente esto es algo que alguien debería arreglar en Debian (yo intenté enviar un bug report y fue tan tedioso que abandoné).

Swap

Los VPS de DO vienen sin swap, pero esto sería un desastre si te quedas sin RAM, especialmente en un servicio hambriento como Jitsi. Así que al menos añade un fichero de swap de tamaño equivalente a la RAM.

DNS

Nunca se recalcará lo suficiente que es importante tener los dominios operativos y propagados ANTES de empezar la instalación. Para los dominios recomiendo Axarnet por si estáis bucando proveedor.

Firewall

En mi servidor tengo inhabilitadas por defecto todas las conexiones tanto entrantes como salientes, esto es opcional y depende del uso que le des. Hay gente que opta por abrir todas las salientes, pero las entrantes tienen que estar siempre cerradas y habilitar las que necesites. Vamos con las reglas.

  • Para permitir que Let’s Encrypt pueda validar tu dominio y entregarte los certificados SSL: ufw allow 'Nginx Full'
  • Para permitir Jitsi:
    • ufw allow 8443/tcp
    • ufw allow out 8443/tcp
    • ufw allow 10000/udp
  • Para permitir tráfico web:
    • ufw allow 'WWW Secure'
    • ufw allow out 'WWW Secure'
    • ufw allow 'WWW'
    • ufw allow out 'WWW'

Una última nota. El servicio SystemD de jitsi se llama concretamente jitsi-videobridge2. Útil a la hora de activarlo y reiniciarlo.

Autenticación al crear reuniones

Por defecto el servidor jitsi está en internet y cualquiera lo puede usar. Si ese es tu propósito, adelante, hay muchos nodos públicos. Pero si quieres tener un poco de control sobre quien tiene capacidad para iniciar reuniones, hay una guía bajo el apartado Secure Domain en esta dirección del componente Jicofo de la suite de Jitsi. Internamente Jitsi confía en mi viejo conocido Prosody, demostrando una vez más las grandezas del software libre y la filosofía Unix: haz un programa que haga una sola cosa y la haga bien y luego combínalo con otros programas (literalmente no es así pero ese es el espíritu).

Rendimiento

La verdad es que para las limitadas características del servidor, ha ido muy bien en una prueba con 6 personas. En todo lo que duró la reunión la carga fue baja, sin pasar de un 30% de CPU y sin consumir toda la memoria RAM. Además con swapiness bien ajustado hacemos que la aproveche bien y no comience a tirar de swap, que es muy lento.

Así estuvo toda la sesión de 6 participantes (htop)

Me han reportado que las cosas se han puesto feas con 11 participantes, con problemas de cortes de audio y vídeo. La verdad es que lo considero normal para este servidor, de manera que creo que esta capacidad puede dar para 6-7 participantes como mucho, no está mal.

Es muy importante que todo el mundo use Chrome, que es a día de hoy el navegador en que la gente de Jitsi se ha centrado. Con firefox el sistema me funciona, pero leí por ahí que no hace mucho (por problemas con un asunto llamado simulcast en la implementación WebRTC de firefox) no anda todavía fino, pero están trabajando en ello.

Si quieres probar mi instancia escríbeme y te creo un usuario y si necesitas ayuda para instalarla, dado el espíritu de colaboración y hermandad que reina en estos tiempos, no voy a ser menos. Si te pillas un servidor DigitalOcean (con este enlace) te ayudo a instalarlo.


Archivado en categoría(s) GNU/Linux, Internet, Jitsi, XMPP

Enlace permanente


  • alberto dice:

    Creo que lo del PATH no es ningún error, sino un ajuste de seguridad intencionado, como se puede ver en el último comentario de

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918754

    En otro orden de cosas, a mí reportar fallos nunca me ha sido demasiado difícil con el comando «reportbug»:

    reportbug

    se encarga de todo, incluso de enviar el formulario aunque no tengas SMTP configurado.

    1. Danielside dice:

      Muy interesante. Al principio me extrañó mucho que se les escapara algo así.
      Creo que lo que pasó con reportbug es que me preguntaba a qué paquete asignarle el fallo, no lo sabía, me lié con otra cosa y abandoné 😉

  • Aj dice:

    Muy buen trabajo, estoy aprendiendo bastante de todo lo que publicas, muchas gracias 😁👍

    1. Danielside dice:

      ¡Gracias por pasarte!


  • Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.