1
0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-12-12 08:43:55 +02:00
matrix-docker-ansible-deploy/docs/prerequisites.md
Slavi Pantaleev e1690722f7 Replace cronjobs with systemd timers
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/756

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/737

I feel like timers are somewhat more complicated and dirty (compared to
cronjobs), but they come with these benefits:

- log output goes to journald
- on newer systemd distros, you can see when the timer fired, when it
will fire, etc.
- we don't need to rely on cron (reducing our dependencies to just
systemd + Docker)

Cronjobs work well, but it's one more dependency that needs to be
installed. We were even asking people to install it manually
(in `docs/prerequisites.md`), which could have gone unnoticed.

Once in a while someone says "my SSL certificates didn't renew"
and it's likely because they forgot to install a cron daemon.

Switching to systemd timers means that installation is simpler
and more unified.
2021-01-14 23:35:50 +02:00

3.7 KiB

Prerequisites

We only strive to support released stable versions of distributions, not betas or pre-releases. This playbook can take over your whole server or co-exist with other services that you have there.

This playbook somewhat supports running on non-amd64 architectures like ARM. See Alternative Architectures.

If your distro runs within an LXC container, you may hit this issue. It can be worked around, if absolutely necessary, but we suggest that you avoid running from within an LXC container.

  • root access to your server (or a user capable of elevating to root via sudo).

  • Python being installed on the server. Most distributions install Python by default, but some don't (e.g. Ubuntu 18.04) and require manual installation (something like apt-get install python3). On some distros, Ansible may incorrectly detect the Python version (2 vs 3) and you may need to explicitly specify the interpreter path in inventory/hosts during installation (e.g. ansible_python_interpreter=/usr/bin/python3)

  • The Ansible program being installed on your own computer. It's used to run this playbook and configures your server for you. Take a look at our guide about Ansible for more information, as well as version requirements and alternative ways to run Ansible.

  • Either the dig tool or python-dns installed on your own computer. Used later on, by the playbook's services check feature.

  • An HTTPS-capable web server at the base domain name (<your-domain>) which is capable of serving static files. Unless you decide to Serve the base domain from the Matrix server or alternatively, to use DNS SRV records for Server Delegation.

  • Properly configured DNS records for <your-domain> (details in Configuring DNS).

  • Some TCP/UDP ports open. This playbook configures the server's internal firewall for you. In most cases, you don't need to do anything special. But if your server is running behind another firewall, you'd need to open these ports:

    • 80/tcp: HTTP webserver
    • 443/tcp: HTTPS webserver
    • 3478/tcp: TURN over TCP (used by Coturn)
    • 3478/udp: TURN over UDP (used by Coturn)
    • 5349/tcp: TURN over TCP (used by Coturn)
    • 5349/udp: TURN over UDP (used by Coturn)
    • 8448/tcp: Matrix Federation API HTTPS webserver. In some cases, this may necessary even with federation disabled. Integration Servers (like Dimension) and Identity Servers (like ma1sd) may need to access openid APIs on the federation port.
    • the range 49152-49172/udp: TURN over UDP
    • 4443/tcp: Jitsi Harvester fallback
    • 10000/udp: Jitsi video RTP. Depending on your firewall/NAT setup, incoming RTP packets on port 10000 may have the external IP of your firewall as destination address, due to the usage of STUN in JVB (see matrix_jitsi_jvb_stun_servers).

When ready to proceed, continue with Configuring DNS.