Diferencia entre revisiones de «Omnisuite videoCan»

De VIVAitwiki
Ir a la navegaciónIr a la búsqueda
(Página creada con «Maquina generica - Debian 13 - nginx - certbot - prosody - No hay Mariadb/Mysql - Para montar el meet habrá un procedimiento que nos dará Antonio Diferencias con u…»)
 
Línea 1: Línea 1:
Maquina generica
+
== Maquina genérica ==
- Debian 13
+
* '''Debian 13'''
- nginx
+
* '''nginx'''
- certbot
+
* '''certbot'''
- prosody
+
* '''prosody'''
- No hay Mariadb/Mysql
+
* No hay Mariadb/Mysql
- Para montar el meet habrá un procedimiento que nos dará Antonio
+
* Para montar el meet habrá un procedimiento que nos dará Antonio
  
Diferencias con un VIVAit Meet "standard"
+
== Diferencias con un VIVAit Meet "standard" ==
- VIVAit Meet autentica con credenciales con LDAP o BBDD VIVAit; aqui no hay LDAP ni usuarios; en la URL que llega del chat la URL de videocan llega un Token; con esa URL cuando se conecta el agente se autentica usando JWT y ya entra autenticado como moderador
+
* '''Autenticación:''' VIVAit Meet autentica con credenciales con LDAP o BBDD VIVAit; aquí no hay LDAP ni usuarios. En la URL que llega del chat de la URL de videocan llega un Token. Con esa URL, cuando se conecta el agente, se autentica usando JWT y ya entra autenticado como moderador.
- Carteles;
+
* '''Carteles'''
  
Consideraciones de arquitectura
+
== Consideraciones de arquitectura ==
- No vamos a dar maquina virtual, siempre instalaremos; por ejemplo el nombre de host está en una cantidad de sitios tan grande que es inmanejable
+
* '''No se entrega máquina virtual, siempre se instalará:''' Por ejemplo, el nombre de host está en una cantidad de sitios tan grande que es inmanejable de otra forma.
- Siempre instalado en un nodo entero; no es compatible con asterisk (ambos usan puertos 10000)
+
* '''Nodo dedicado:''' Siempre instalado en un nodo entero; no es compatible con Asterisk (ambos usan el puerto 10000).
- Requiere una IP Publica entera (puede ser Nateada)
+
* '''Red:''' Requiere una IP Pública entera (puede ser Nateada).
- No compatible con "otro meet" que hubiera en el cliente
+
* '''Exclusividad:''' No es compatible con "otro meet" que pudiera haber en el cliente.
  
 +
== Desarrollos ==
 +
* '''Módulo mod en prosody'''
 +
* '''Videocan (Demonio):''' Proporciona APIs:
 +
** API de conexión de cliente
 +
** API de conexión de Agente
 +
** API contra prosody (control de canales)
 +
* '''Aplicación para firmar (videoCanFirmar):''' Usa la clave privada habitual.
 +
** Se le pasa un fichero <code>videoCan.conf</code> y devuelve otro modificado (no lo machaca).
 +
** Puede generar firma, <code>jwt_secret</code> (para prosody) y tokens (para la conexión desde el lado cliente a URL de videoCan para el servicio).
 +
* '''Plantilla:''' Cuando se invoca a una URL de videocan, la página que se le devuelve es una plantilla. Personalizan aspectos "del meet", reciben parámetros, etc.
 +
* Cuando invocamos a <code>openchannel</code> desde videocan también existe una plantilla para "lo que le entra al agente".
 +
* '''Plantillas:''' Tienen Javascript.
  
Desarrollos:
+
== Proceso de instalación ==
- Modulo mod en prosody
+
* Pendiente del detalle.
 +
* Configurar prosody (seguramente solo cambiar nombre de host).
 +
* Modificar el JWT.
 +
* Reconfigurar varias veces NGINX y meet.
 +
* Puntos intermedios de prueba en los que se puede probar vídeo (sin autenticación).
 +
* '''Importante:''' Ir viendo logs en todo el proceso.
  
- Videocan: Demonio
+
== Seguridad ==
Proporciona API's
+
=== Medidas de protección ===
- API de conexión de cliente
+
* '''Nftables'''
- API de conexión de Agente
+
* '''Fail2ban:''' Manejamos el nginx y el mcan.
- API contra prosody (control de canales)
+
* '''Firmas de control:''' Firmamos una cadena que contiene los valores que nos interesa proteger para poder tener distribución y que, por ejemplo, no nos amplíen el número de canales. Protegemos:
- Aplicación para firmar (videoCanFirmar) --> Usa la clave privada habitual
+
** Número de servicios
- Se le pasa un fichero videoCan.conf y devuelve otro (no machaca) modificado
+
** Número de canales
- Puede generar firma, jwt_secret (para prosody) y tokens (para la conexion desde el lado cliente a URL de videoCan para el servicio)
+
** Host
- Plantilla --> Cuando se invoca a una URL de videocan, la pagina que se le devuelve es una plantilla; personalizan aspectos "del meet" , reciben parámetros,..
+
* '''Actualizaciones (por seguridad):''' <code>update</code>/<code>upgrade</code>, y cuando saquemos actualizaciones de meet o videocan.
- Cuando invocamos a openchannel desde videocan también existe una plantilla para "lo que le entra al agente"
 
  
- Plantillas, tienen Javascript
+
== Configuraciones ==
 +
* Hay un fichero guía de instalación / cuestionario a cliente.
 +
* <code>videoCan.conf</code>
  
Proceso de instalación:
+
== Diagnósticos ==
- Pendiente del detalle
+
=== Videocan ===
- Configurar prosody (seguramente solo cambiar nombre de host)
+
* Comando de diagnóstico:
- Modificar el JWT
+
: <code>nc localhost 1132</code>
- reconfigurar varias veces NGINX y meet
+
* Rutas de logs principales:
- Puntos intermedios de prueba en los que se puede probar video (sin autenticación)
+
: <code>/var/log/videoCan/videoCan.log</code>
- Importante ir viendo logs en todo el proceso
+
: <code>/var/log/nginx</code> (Típicos de nginx)
 
+
: <code>/var/log/prosody</code>
 
+
: <code>/var/log/jitsi</code>
Seguridad
+
* Monitoreo: '''Zabbix''' (explotando el comando "nc").
- Medidas de protección
 
- Nftables
 
- Fail2ban: Manejamos el nginx y el mcan
 
- Firmamos una cadena que contiene los valores que nos interesa proteger (para poder tener distribución y qye por ejemplo no nos amplien el numero de canales). Protegemos
 
- Numero de servicios
 
- Número de canales
 
- Host
 
- Actualizaciones (por seguridad): update/upgrade, y cuando saquemos actualizaciones de meet o videocan
 
 
 
 
 
Configuraciones
 
- Hay un fichero guia de instalación // cuestionario a cliente
 
- VideoCan.conf
 
 
Diagnosticos
 
Videocan
 
- nc localhost 1132
 
- /var/log/videoCan/videoCan.log
 
- Zabbix (explotando "nc")
 
- Típicos de nginx () /var/log/nginx
 
- Prosody /var/log/prosody
 
- Jitsi /var/log/jitsi
 

Revisión del 11:58 17 jun 2026

1 Maquina genérica

  • Debian 13
  • nginx
  • certbot
  • prosody
  • No hay Mariadb/Mysql
  • Para montar el meet habrá un procedimiento que nos dará Antonio

2 Diferencias con un VIVAit Meet "standard"

  • Autenticación: VIVAit Meet autentica con credenciales con LDAP o BBDD VIVAit; aquí no hay LDAP ni usuarios. En la URL que llega del chat de la URL de videocan llega un Token. Con esa URL, cuando se conecta el agente, se autentica usando JWT y ya entra autenticado como moderador.
  • Carteles

3 Consideraciones de arquitectura

  • No se entrega máquina virtual, siempre se instalará: Por ejemplo, el nombre de host está en una cantidad de sitios tan grande que es inmanejable de otra forma.
  • Nodo dedicado: Siempre instalado en un nodo entero; no es compatible con Asterisk (ambos usan el puerto 10000).
  • Red: Requiere una IP Pública entera (puede ser Nateada).
  • Exclusividad: No es compatible con "otro meet" que pudiera haber en el cliente.

4 Desarrollos

  • Módulo mod en prosody
  • Videocan (Demonio): Proporciona APIs:
    • API de conexión de cliente
    • API de conexión de Agente
    • API contra prosody (control de canales)
  • Aplicación para firmar (videoCanFirmar): Usa la clave privada habitual.
    • Se le pasa un fichero videoCan.conf y devuelve otro modificado (no lo machaca).
    • Puede generar firma, jwt_secret (para prosody) y tokens (para la conexión desde el lado cliente a URL de videoCan para el servicio).
  • Plantilla: Cuando se invoca a una URL de videocan, la página que se le devuelve es una plantilla. Personalizan aspectos "del meet", reciben parámetros, etc.
  • Cuando invocamos a openchannel desde videocan también existe una plantilla para "lo que le entra al agente".
  • Plantillas: Tienen Javascript.

5 Proceso de instalación

  • Pendiente del detalle.
  • Configurar prosody (seguramente solo cambiar nombre de host).
  • Modificar el JWT.
  • Reconfigurar varias veces NGINX y meet.
  • Puntos intermedios de prueba en los que se puede probar vídeo (sin autenticación).
  • Importante: Ir viendo logs en todo el proceso.

6 Seguridad

6.1 Medidas de protección

  • Nftables
  • Fail2ban: Manejamos el nginx y el mcan.
  • Firmas de control: Firmamos una cadena que contiene los valores que nos interesa proteger para poder tener distribución y que, por ejemplo, no nos amplíen el número de canales. Protegemos:
    • Número de servicios
    • Número de canales
    • Host
  • Actualizaciones (por seguridad): update/upgrade, y cuando saquemos actualizaciones de meet o videocan.

7 Configuraciones

  • Hay un fichero guía de instalación / cuestionario a cliente.
  • videoCan.conf

8 Diagnósticos

8.1 Videocan

  • Comando de diagnóstico:
nc localhost 1132
  • Rutas de logs principales:
/var/log/videoCan/videoCan.log
/var/log/nginx (Típicos de nginx)
/var/log/prosody
/var/log/jitsi
  • Monitoreo: Zabbix (explotando el comando "nc").