Instalación¶
El Inicio rápido lleva una máquina hasta un canal reproduciéndose. Esta página trata de lo que la instalación hace realmente y de cómo desplegar Catena en producción: de qué se compone la entrega, dónde viven los secretos, cómo conectar un PostgreSQL externo y qué puertos se abren.
Los paquetes¶
Catena se instala desde dos paquetes — uno por papel de la máquina:
- catena — la máquina central: la interfaz de la consola, la unidad
catena.service, el directorio/etc/catenay una configuración con la seccióncentral:— justo lo que convierte la caja en una instalación central. Instala automáticamente el servidor de streaming exactamente de su versión, y PostgreSQL. - catena-streamer — un streamer unido: el mismo producto en el papel de máquina del clúster, sin consola y sin sección
central:. Unirse al clúster son tres líneas en/etc/catena/streamer.env.
Los plugins de codificación llegan como dependencia recomendada: el servidor corre sin ellos, pero no tiene con qué codificar.
El post-install del paquete catena aprovisiona la caja: crea el rol y la base catena en PostgreSQL, genera las contraseñas de la base y del administrador y las escribe en /etc/catena/secrets.env (propiedad de root, modo 0600):
DATABASE_URL=postgres://catena:...@127.0.0.1:5432/catena
EDIT_AUTH_PASSWORD=...
La unidad conecta este archivo como EnvironmentFile. Las actualizaciones del paquete no rotan los secretos — una vez escritos, sobreviven cualquier upgrade.
La instalación pide la clave de licencia por su cuenta y la escribe en /etc/catena/license.txt (propiedad de root, modo 0600). Dejar la pregunta vacía instala el paquete igualmente, pero el servicio no arrancará — ponga la clave en ese mismo archivo (o pásela en la variable LICENSE_KEY) y ejecute systemctl start catena. Para despliegues la respuesta se precarga con debconf-set-selections — véase Despliegue desatendido.
El paquete de producto es dueño de toda la superficie de la instalación: la unidad catena.service, el directorio de configuración /etc/catena y el directorio de estado /var/lib/catena. El sapsan.service base queda retirado de esa máquina — debe correr exactamente un proceso.
Un PostgreSQL externo¶
PostgreSQL es el único portador de estado de central, y en producción su lugar es un clúster gestionado con backups, no la misma máquina. Basta cambiar DATABASE_URL en /etc/catena/secrets.env a la base externa y reiniciar el servicio: central aplica el esquema por sí mismo al arrancar, no hay pasos de migración aparte.
Los puertos¶
El paquete no instala configuración con puerto. De fábrica se levanta el puerto 80 (definido en la variable INITIAL_HTTP_PORT) — y es exactamente un valor inicial: actúa solo mientras ningún otro origen define listeners HTTP. Desde ahí los puertos pertenecen a la config del streamer — se editan desde la consola como en cualquier máquina del clúster. La variable HTTP=<puerto> es lo contrario — un solape permanente por encima de todo.
| Puerto | Quién lo define | Para qué |
|---|---|---|
| HTTP (inicialmente 80) | INITIAL_HTTP_PORT, luego la config del streamer |
La consola, el API, el frente de espectadores /streaming, el sync de streamers |
| RTSP, RTMP (TCP), WebRTC (UDP) | Listeners en la configuración del streamer | Captura y entrega por esos protocolos |
| SRT (UDP) | Un listener por canal: el puerto de la reproducción SRT | Servir un canal por SRT |
| Entradas UDP | El puerto de cada fuente multicast | Recepción MPEG-TS |
Entre máquinas del clúster: todo el tráfico de control lo inicia el streamer — necesita acceso HTTP(S) a central; de vuelta, central solo llama al api_url del streamer (proxeo de medios y estadísticas). Los espectadores necesitan HTTP(S) hasta central y, con redirects, hasta las direcciones públicas de los streamers.
Comprobación¶
systemctl status catena
journalctl -u catena -n 50
Después — entrar en la consola y el primer canal. Las causas típicas de no-arranque — la licencia y un PostgreSQL inaccesible — están en el troubleshooting del Inicio rápido.