diff --git a/matrix/checklist.md b/matrix/checklist.md index e2093ea..da10d48 100644 --- a/matrix/checklist.md +++ b/matrix/checklist.md @@ -32,7 +32,10 @@ should probably follow the [worker-based setup](synapse/workers), because changing the architecture from monolithic to worker-based once the server is already in use, is a tricky task. -Here's a ballpark figure. Remember, your mileage will probably vary. +Here's a ballpark figure. Remember, your mileage will probably vary. And +remember, just adding RAM and CPU doesn't automatically scale: you'll need to +tune [PostgreSQL](postgresql/README.md#tuning) and your workers as well so +that your hardware is optimally used. | Scenario | Architecture | CPU | RAM | Diskspace (GB) | | :------------------------------------ | :-----------------------------: | :----: | :----: | :------------: | @@ -84,11 +87,11 @@ can be a CNAME again. Element Call uses [LiveKit](element-call#livekit) for the actual processing of audio and video, and that needs its own DNS entry and certificate too. We'll use `livekit.example.com`. -| FQDN | Use | Comment | -| :-------------------- | :--------------------- | :-------------------------------- | -| `example.com` | Hosting `.well-known` | | -| `matrix.example.com` | Synapse server | Can't be `CNAME` | -| `element.example.com` | Webclient | | -| `turn.example.com` | TURN / Element Call | Highly recommended | -| `call.example.com` | Element Call | Optional | -| `livekit.example.com` | LiveKit SFU | Optional, needed for Element Call | +| FQDN | Use | Comment | +| :-------------------- | :--------------------- | :--------------------------------------- | +| `example.com` | Hosting `.well-known` | This is the `server_name` | +| `matrix.example.com` | Synapse server | This is the `base_url`, can't be `CNAME` | +| `element.example.com` | Webclient | | +| `turn.example.com` | TURN / Element Call | Highly recommended | +| `call.example.com` | Element Call | Optional | +| `livekit.example.com` | LiveKit SFU | Optional, needed for Element Call | diff --git a/matrix/coturn/README.md b/matrix/coturn/README.md index bedb882..b6e7a2f 100644 --- a/matrix/coturn/README.md +++ b/matrix/coturn/README.md @@ -72,8 +72,8 @@ certbot certonly --nginx -d turn.example.com This assumes you've already setup and started nginx (see [nginx](../nginx)). -The certificate files reside under `/etc/letsencrypt/live`, but coturn doesn't -run as root, and can't read them. Therefore we create the directory +{#fixssl}The certificate files reside under `/etc/letsencrypt/live`, but coturn +doesn't run as root, and can't read them. Therefore we create the directory `/etc/coturn/ssl` where we copy the files to. This script should be run after each certificate renewal: diff --git a/matrix/element-call/README.md b/matrix/element-call/README.md index 0dbd793..9e81659 100644 --- a/matrix/element-call/README.md +++ b/matrix/element-call/README.md @@ -19,6 +19,129 @@ This bit is for later, but here's a nice bit of documentation to start: https://sspaeth.de/2024/11/sfu/ +# Overview + +Element Call consists of a few parts, you don't have to host all of them +yourself. In this document, we're going to host everything ourselves, so +here's what you need. + +* lk-jwt. This authenticates Synapse users to LiveKit. +* LiveKit. This is the "SFU", which actually handles the audio and video, and does TURN. +* Element Call widget. This is basically the webapplication, the part you see. + + +# LiveKit {#livekit} + +The actual SFU, Selective Forwarding Unit, is LiveKit; this is the part that +handles the audio and video feeds and also does TURN (this TURN-functionality +does not support the legacy calls, you'll need [coturn](coturn) for that). + +Downloading and installing is easy: download the [binary from +Github](https://github.com/livekit/livekit/releases/download/v1.8.0/livekit_1.8.0_linux_amd64.tar.gz) + to /usr/local/bin, chown it to root:root and you're done. + +The quickest way to do precisely that, is to run the script: + +``` +curl -sSL https://get.livekit.io | bash +``` + +You can do this as a normal user, it will use sudo to do its job. + +Configuring this thing is [documented +here](https://docs.livekit.io/home/self-hosting/deployment/). We're going to +run LiveKit under authorization of user `turnserver`, the same users we use +for [coturn](coturn). This user is created when installing coturn, so if you +haven't installed that, you should create the user yourself: + +``` +adduser --system turnserver +``` + +{#keysecret}Create a key and secret: + +``` +livekit-server generate-keys +``` + +This key and secret have to be fed to lk-jwt-service too, [see here](#jwtconfig). +Create a configuration file for livekit, `/etc/livekit/livekit.yaml`: + +``` +port: 7880 +bind_addresses: + - ::1 +rtc: + tcp_port: 7881 + port_range_start: 50000 + port_range_end: 60000 + use_external_ip: true + enable_loopback_candidate: false +turn: + enabled: true + domain: livekit.example.com + cert_file: /etc/coturn/ssl/fullchain.pem + key_file: /etc/coturn/ssl/privkey.pem + tls_port: 5349 + udp_port: 3478 + external_tls: true +keys: + # KEY: SECRET were autogenerated by livekit/generate + # in the lk-jwt-service environment variables + : +``` + +The certificate files are not in the usual place under +`/etc/letsencrypt/live`, see [DNS and +certificate (coturn)](../coturn/README.md#dnscert) why that is. + +As stated before, we use the same user as for coturn. Because this user does +not have the permission to read private keys under `/etc/letsencrypt`, we copy +those files to a place where it can read them. For coturn we copy them to +`/etc/coturn/ssl`, and if you use coturn and have this directory, LiveKit can +read them there too. + +If you don't have coturn installed, you should create a directory under +`/etc/livekit` and copy the files to there. Modify the `livekit.yaml` file and +the [script to copy the files](../coturn/README.md#fixssl) to use that +directory. + +The LiveKit API listens on localhost, IPv6, port 7880. Traffic to this port is +forwarded from port 443 by nginx, which handles TLS, so it shouldn't be reachable +from the outside world. + +See [LiveKit's config documentation](https://github.com/livekit/livekit/blob/master/config-sample.yaml) +for more options. + +Now define a systemd servicefile, like this: + +``` +[Unit] +Description=LiveKit Server +After=network.target +Documentation=https://docs.livekit.io + +[Service] +User=turnserver +Group=turnserver +LimitNOFILE=500000 +Restart=on-failure +WorkingDirectory=/etc/livekit +ExecStart=/usr/local/bin/livekit-server --config /etc/livekit/livekit.yaml + +[Install] +WantedBy=multi-user.target +``` + +Enable and start it. + +IMPORTANT! + +LiveKit is configured to use its built-in TURN server, using the same ports as +[coturn](../coturn). Obviously, LiveKit and coturn are mutually exclusive in +this setup. Shutdown and disable coturn if you use LiveKit's TURN server. + + # Install prerequisites Define an entry in DNS for Livekit and Call, e.g. `livekit.example.com` @@ -127,9 +250,9 @@ chgrp -R www-data /etc/lk-jwt-service chmod -R o-rwx /etc/lk-jwt-service ``` -The contents of `/etc/lk-jwt-service/config` are not fully known yet (see -further, installation of the actual LiveKit, the SFU), but for now it's enough -to fill it with this: +{#jwtconfig}This is what you should put into that config file, +`/etc/lk-jwt-service/config`. The `LIVEKIT_SECRET` and `LIVEKIT_KEY` are the +ones you created while [configuring LiveKit](#keysecret). ``` LIVEKIT_URL=wss://livekit.example.com @@ -144,99 +267,6 @@ Now enable and start this thing: systemctl enable --now lk-jwt-service ``` -# LiveKit {#livekit} - -The actual SFU, Selective Forwarding Unit, is LiveKit. Downloading and -installing is easy: download the [binary from Github](https://github.com/livekit/livekit/releases/download/v1.8.0/livekit_1.8.0_linux_amd64.tar.gz) - to /usr/local/bin, chown -it to root:root and you're done. - -The quickest way to do precisely that, is to run the script: - -``` -curl -sSL https://get.livekit.io | bash -``` - -You can do this as a normal user, it will use sudo to do its job. - -Configuring this thing is [documented -here](https://docs.livekit.io/home/self-hosting/deployment/). - -Create a key and secret: - -``` -livekit-server generate-keys -``` - -This key/secret has to be fed to lk-jwt-service, of course. Create a -configuration file for livekit, `/etc/livekit/livekit.yaml`: - -``` -port: 7880 -bind_addresses: - - ::1 -rtc: - tcp_port: 7881 - port_range_start: 50000 - port_range_end: 60000 - use_external_ip: true - enable_loopback_candidate: false -turn: - enabled: true - domain: livekit.example.com - cert_file: /etc/coturn/ssl/fullchain.pem - key_file: /etc/coturn/ssl/privkey.pem - tls_port: 5349 - udp_port: 3478 - external_tls: true -keys: - # KEY: secret were autogenerated by livekit/generate - # in the lk-jwt-service environment variables - xxxxxxxxxxxxxxx: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -``` - -The LiveKit API listens on localhost, IPv6, port 7880. Traffic to this port is -forwarded from port 443by nginx, which handles TLS, so it shouldn't be reachable -from the outside world. - -The certificate files are not in the usual place under -`/etc/letsencrypt/live`, see [DNS and -certificate (coturn)](../coturn/README.md#dnscert) why that is. - -The `xxx: xxxx` is the key and secret as generated before. - -See [LiveKit's config documentation](https://github.com/livekit/livekit/blob/master/config-sample.yaml) -for more options. - -Now define a systemd servicefile, like this: - -``` -[Unit] -Description=LiveKit Server -After=network.target -Documentation=https://docs.livekit.io - -[Service] -User=turnserver -Group=turnserver -LimitNOFILE=500000 -Restart=on-failure -WorkingDirectory=/etc/livekit -ExecStart=/usr/local/bin/livekit-server --config /etc/livekit/livekit.yaml - -[Install] -WantedBy=multi-user.target -``` - -Enable and start it. - -IMPORTANT! - -LiveKit is configured to use its built-in TURN server, using the same ports as -[coturn](../coturn). Obviously, LiveKit and coturn are mutually exclusive in -this setup. Shutdown and disable coturn if you use LiveKit's TURN server. - - # Element Call widget {#widget} This is a Node.js thingy, so start by installing yarn. Unfortunately both npm diff --git a/matrix/postgresql/README.md b/matrix/postgresql/README.md index d47203c..a542102 100644 --- a/matrix/postgresql/README.md +++ b/matrix/postgresql/README.md @@ -75,7 +75,7 @@ Make sure you add these lines under the one that gives access to the postgres superuser, the first line. -# Tuning +# Tuning {#tuning} This is for later, check [Tuning your PostgreSQL Server](https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server) on the PostgreSQL wiki.