travier / fedora-coreos-matrix

Butane config to host a Matrix homeserver on Fedora CoreOS (nginx + Let's Encrypt + Synapse + PostgreSQL + element-web)

Butane config to host a Matrix homeserver on Fedora CoreOS

Example Butane config to host a Matrix homeserver on Fedora CoreOS. This will setup:

• nginx with Let's Encrypt for HTTPS support
• Synapse with PostgreSQL and elements-web

For this setup, you need a domain name and two sub-domains:

• example.tld
• matrix.example.tld
• chat.example.tld

For Let's Encrypt support, those domains must be configured beforehand to resolve to the IP address that will be assigned to your server. If you do not know what IP address will be assigned to your server in advance, you might want to use another ACME challenge method to get Let's Encrypt certificates (see DNS Plugins).

If you already have certificates from Let's Encrypt or another provider, see the in progress PR for an alternative with existing certificates.

How to use

To generate the Ignition configs, you need make and Butane:

Then, you need to provide values for each variable in the secrets file:

$ cp secrets.example secrets
$ ${EDITOR} secrets
# Fill in values not marked as generated by Synapse

Configuring Synapse

The Synapse configuration requires to setup a few secrets, you can generate these secret using the following command :

$ source secrets
$ mkdir generated
$ podman run -it --rm -v $PWD/generated:/data:z \
      -e SYNAPSE_SERVER_NAME="${DOMAIN_NAME}" \
      -e SYNAPSE_REPORT_STATS=yes \
      docker.io/matrixdotorg/synapse:latest \
      generate

This command will generate 3 files

• generated/homeserver.yaml
• generated/my.matrix.host.log.config
• generated/my.matrix.host.signing.key

Configuration

A template version of the generated homeserver.yaml is included in template/synapse/homeserver.yaml.

First we want to replace the secrets with values that were generated for you by Synapse. Note that the generated secrets may contain characters which are currently not handled well by the Makefile. Problematic characters include & and # and possibly others. Always manually verify that the final config files contain the correct secrets. See isssue #14 for details.

In the secrets file, edit the following variables:

• SYNAPSE_REGISTRATION_SHARED_SECRET, with the content of registration_shared_secret in homeserver.yaml
• SYNAPSE_MACAROON_SECRET_KEY, with the content of macaroon_secret_key in homeserver.yaml
• SYNAPSE_FORM_SECRET, with the content of form_secret in homeserver.yaml
• SYNAPSE_SIGNING_KEY, with the content of my.matrix.host.signing.key
• SYNAPSE_REGISTRATION, whether or not to enable open registration

SSH_PUBKEY="ssh-rsa AAAA..."
POSTGRES_PASSWORD=a_passpharse_for_my_database
DOMAIN_NAME=my.matrix.domain
[email protected]
SYNAPSE_REGISTRATION_SHARED_SECRET=a_very_long_string_generated_by_synapse
SYNAPSE_MACAROON_SECRET_KEY=a_very_long_string_generated_by_synapse
SYNAPSE_FORM_SECRET=a_very_long_string_generated_by_synapse
SYNAPSE_SIGNING_KEY=a_key_generated_by_synapse
SYNAPSE_REGISTRATION=false

If you wish to change other Synapse settings you can edit directly template/synapse/homeserver.yaml and template/synapse/synapse.log.config to change the logging configuration.

System and container updates

By default, Fedora CoreOS systems are updated automatically to the latest released update. This makes sure that the system is always on top of security issues (and updated with the latest features) wthout any user interaction needed. The containers, as defined in the systemd units in the config, are updated on each service startup. They will thus be updated at least once after each system update as this will trigger a reboot approximately every two week.

To maximise availability, you can set an update strategy in Zincati's configuration to only allow reboots for updates during certain periods of time. For example, one might want to only allow reboots on week days, between 2 AM and 4 AM UTC, which is a timeframe where reboots should have the least user impact on the service. Make sure to pick the correct time for your timezone as Fedora CoreOS uses the UTC timezone by default.

See this example config that you can append to config.bu:

[updates]
strategy = "periodic"

[[updates.periodic.window]]
days = [ "Mon", "Tue", "Wed", "Thu", "Fri" ]
start_time = "02:00"
length_minutes = 120

Generate the ignition configuration

Finally, you can generate the final Ignition config with:

$ make

You are now ready to deploy your Fedora CoreOS Matrix home server.

Deploying

See the Fedora CoreOS docs for instructions on how to use this Ignition config to deploy a Fedora CoreOS instance on your prefered platform.

Registering new users

Registration is disabled by default for security and to avoid mistakes. If you want to create an instance with open registration, you can set the SYNAPSE_REGISTRATION value to true in your secrets file.

Otherwise, you can still add accounts to an instance by running the following command directly on the server:

$ sudo podman run --rm --tty --interactive \
      --pod=matrix \
      -v /var/srv/matrix/synapse:/data:z,ro \
      --entrypoint register_new_matrix_user \
      docker.io/matrixdotorg/synapse:latest \
      -c /data/homeserver.yaml http://127.0.0.1:8008

PostgreSQL major version updates

Major PostgreSQL version updates require manual intervention to dump the database with the current version and then import it in the new version. We thus can not use the latest tag for this container image and manual intervention will be required approximately once a year to update the PostreSQL container version.

See this example to dump the current database and import it when moving from version 13 to 14:

# Stop Synapse server to ensure no-one is writing to the database
$ systemctl stop synapse

# Dump the database
$ mkdir /var/srv/matrix/postgres.dump
$ cat /etc/postgresql_synapse
$ podman run --read-only --pod=matrix --rm --tty --interactive \
      -v /var/srv/matrix/postgres.dump:/var/data:z \
      docker.io/library/postgres:13 \
      pg_dump --file=/var/data/dump.sql --format=c --username=synapse \
      --password --host=localhost synapse

# Stop the PostgreSQL container
$ systemctl stop postgres

# Keep existing database as backup
$ mv /var/srv/matrix/postgres /var/srv/matrix/postgres.bak
$ mkdir /var/srv/matrix/postgres

# Edit the PostgreSQL unit to update the container version
$ vi /etc/systemd/system/postgres.service

# Start the new PostgreSQL container
$ systemctl start postgres

# Import the database. Make sure to use the new PostgreSQL container image
$ podman run --read-only --pod=matrix --rm --tty --interactive \
      -v /var/srv/matrix/postgres.dump:/var/data:ro,z \
      docker.io/library/postgres:14 \
      pg_restore --username=synapse --password --host=localhost \
      --dbname=synapse /var/data/dump.sql

# Start Synapse again
$ systemctl start synapse

# Cleanup once everything is confirmed working
$ rm -rf /var/srv/matrix/postgres.dump /var/srv/matrix/postgres.bak

License

See LICENSE or CC0.

fedora-coreos-matrix's Issues

Update all podman systemd service units to the proper format

Our container services units are not up-to-date regarding latest podman recommendations and needs updating: http://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html

This is essentially running podman generate systemd xyz for all containers and formatting / merging the output back into the config.

/var/srv is kept as 0755 even if set as 0700 in the FCC

See coreos/ignition#1156. This needs an additional workaround:

• create a subfolder with the correct mode
• mask/fix the /var/srv tempfiles from ostree

RFE: Convert to or add OpenTofu (Terraform) support

• Manually setting up Butane config does not scale well with secret management.
• Adding OpenTofu (Terraform) would also enable us to perform the DNS changes at the same time during the deployment.

Add note for manual major Postgresql version updates

Major Postgresql version updates will require manual intervention to dump the database with the current version and then import it in the new version. We should add a note with some basic steps in the README.

Generated secrets do not work well with sed

I followed your instructions and synapse generated a secret which would not work well with sed in the makefile.
Namely, I got a synapse_macaroon_secret_key like abc&def. Seems like sed does not like the & in there.
Unfortunately I do not know enough about sed to fix this.

Anyways, I could still run everything by simply generating new secrets which did not contain any &.
Thanks for the great project!