Installation¶
The Quick start takes one machine to a playing channel. This page is about what installation actually does and how to deploy Catena in production: what the delivery consists of, where the secrets live, how to attach an external PostgreSQL, and which ports open.
The packages¶
Catena installs from two packages — one per machine role:
- catena — the central machine: the console UI, the
catena.serviceunit, the/etc/catenadirectory and a configuration with thecentral:section — the very thing that turns the box into a central installation. Pulls in the streaming server of exactly its version, and PostgreSQL. - catena-streamer — a joined streamer: the same product in the cluster-machine role, without the console and without the
central:section. Joining the cluster is three lines in/etc/catena/streamer.env.
The encoding plugins arrive as a recommended dependency: the server runs without them, but has nothing to encode with.
The catena package's post-install provisions the box: creates the catena role and database in PostgreSQL, generates the database and administrator passwords, and writes them into /etc/catena/secrets.env (root-owned, mode 0600):
DATABASE_URL=postgres://catena:...@127.0.0.1:5432/catena
EDIT_AUTH_PASSWORD=...
The unit attaches this file as an EnvironmentFile. Package upgrades do not rotate the secrets — once written, they survive any upgrade.
The installer asks for the license key itself and writes it into /etc/catena/license.txt (root-owned, mode 0600). Leaving the question empty still installs the package, but the service will not start — put the key into that same file (or pass the LICENSE_KEY variable) and run systemctl start catena. For rollouts the answer is preseeded with debconf-set-selections — see Unattended rollout.
The product package owns the whole surface of the installation: the catena.service unit, the /etc/catena configuration directory and the /var/lib/catena state directory. The base sapsan.service is taken off such a machine — exactly one process must run.
An external PostgreSQL¶
PostgreSQL is central's only state carrier, and in production it belongs on a managed cluster with backups, not on the same machine. It is enough to change DATABASE_URL in /etc/catena/secrets.env to the external database and restart the service: central applies the schema itself on start, there are no separate migration steps.
The ports¶
The package installs no configuration with a port. Out of the box, port 80 comes up (set in the INITIAL_HTTP_PORT variable) — and that is exactly an initial value: it acts only while no HTTP listeners are set by anything else. From then on the ports are owned by the streamer's config — edited from the console like on any cluster machine. The HTTP=<port> variable is the opposite — a permanent override on top of everything.
What opens and why:
| Port | Set by | Purpose |
|---|---|---|
| HTTP (initially 80) | INITIAL_HTTP_PORT, then the streamer's config |
The console, the API, the viewer front /streaming, streamer sync |
| RTSP, RTMP (TCP), WebRTC (UDP) | Listeners in the streamer settings | Ingest and serving over these protocols |
| SRT (UDP) | A listener per channel: the port from SRT play | Serving a channel over SRT |
| UDP inputs | The port of each multicast source | MPEG-TS ingest |
Between cluster machines: all control traffic is initiated by the streamer — it needs HTTP(S) access to central; the way back, central only calls the streamer's api_url (media proxying and statistics). Viewers need HTTP(S) to central and, with redirects, to the streamers' public addresses.
Check¶
systemctl status catena
journalctl -u catena -n 50
Then — logging into the console and the first channel. The typical no-start causes — the license and an unreachable PostgreSQL — are covered in the Quick start troubleshooting.