v1.50.0 was found to be buggy for people using a `webclient` listener.
This is fixed in v1.50.1.
We don't use such a listener, so we weren't affected anyway.
Also get rid of `--tags=update-user-password` in the
`matrix-dendrite` role, as what we had doesn't work.
We may be able to do it with some Ansible helper or something else.
For now, we'll omit this feature.
All the `matrix_s3_*` stuff happens in the `matrix-synapse` role.
If we are to have such S3 support for Dendrite, we should probably
extract it out of the `matrix-synapse` role (into a `matrix-s3` role or
`matrix-goofys`, etc.) and wire `matrix-dendrite` accordingly.
This may or may not be done in the future though. For now, I'm
cleaning things up in the `matrix-dendrite` role.
Seems like Dendrite encourages serving both the Client and Federation
API at the same port.
Coming from Synapse and how things are done there, we have separate
ports. Using separate ports probably makes matrix-corporal (etc.)
integration easier, so separating the APIs by default probably makes
sense.
The goal is to have a single variable which tells us which homeserver
software is in use. Much simpler than having if/elif/elif checks for
variables like (`matrix_synapse_enabled` and `matrix_dendrite_enabled`, etc.)
everywhere.
As of docker-jitsi-meet stable-6433 [1], `/config/interface_config.js`
is regenerated on every boot. The correct way to modify the interface
config is now via `/config/custom-interface_config.js`, which is
appended to a default copy of `interface_config.js` by
`/etc/cont-init.d/10-config` on every boot of the docker image.
Given that `interface_config.js` is considered deprecated by upstream
(all options will eventually be moved to `config.js`), we also deprecate
the `matrix_jitsi_web_interface_config_*` variables in favour of
`matrix_jitsi_web_custom_interface_config_extension`.
[1] https://github.com/jitsi/docker-jitsi-meet/blob/stable-6433/CHANGELOG.md#stable-6433
Enables optional access to Etherpad's web-UI. This is useful for
managing Etherpad plugins.
Among other things, plugins makes it easy to manage/delete pads if you
install the adminpads2 plugin.
This upgrade is technically not needed due to 1.49.1 and 1.49.2 being identical with a lone fix to Debian packaging being the only change.
Still some might want us to be on the absolutely latest version even tho these 2 are practically identical.
ARM64 has yet to be built so this has to wait for that before merge.
Related to https://github.com/matrix-org/synapse/issues/11604
Getting an upstream fix is preferable. In any case, it's probably nice
to have this defined explicitly in our configuration. This way, people
can more easily discover that they can override the URL preview
language.
Updates based off the variable names used in mautrix-facebook role.
Also update port number in defauts/main.yml, and disable presence
checking, because Twitter doesn't support that.
* Upgrade Mjolnir from 1.1.20 to version 1.2.1
https://hub.docker.com/r/matrixdotorg/mjolnir/tags
using the "latest" tag seems inefficient as it doesn't actually redirect to the latest release
In any case, the latest release is now 1.2.1
docker pull matrixdotorg/mjolnir:v1.2.1
* Fixup
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
The check was checking for an empty string in `matrix_jitsi_prosody_auth_internal_accounts`,
which is unlikely to happen. We should check for an empty list instead.
The check was not validating username/password values, so telling the user that they need a non-empty
username/password is misleading. It was merely checking if there's at least one entry in the list.
This patch adjusts the check and message accordingly.
Was renamed in 087dbe4ddc
It is unclear to me if there is anything you actually need to adjust with these variables. It looks like that is done automatically in `matrix_servers`.
This change forces ansible to decrypt the variable with ansible-vault if encrypted, to avoid the error '{"msg": "Unexpected templating type error occurred on ({{ matrix_synapse_macaroon_secret_key | password_hash('sha512') }}): secret must be unicode or bytes, not ansible.parsing.yaml.objects.AnsibleVaultEncryptedUnicode"}'
Every other variable in the playbook was found to have no problems with encryption.
The change has no negative impact on non-encrypted matrix_synapse_macaroon_secret_key.
We had to remove UID/GID environment variables that we used to pass
to the Synapse container, because it was causing a problem after
https://github.com/matrix-org/synapse/pull/11209
We were using both `--user` and UID/GID environment variables until now.
Until now, we were leaving services "enabled"
(symlinks in /etc/systemd/system/multi-user.target.wants/).
We clean these up now. Broken symlinks may still exist in older
installations that enabled/disabled services. We're not taking care
to fix these up. It's just a cosmetic defect anyway.
* fix for string concatenation on matrix_synapse_account_threepid_delegates_email and matrix_synapse_account_threepid_delegates_msisdn
* .editorconfig should not be ignored
* Restore .gitignore
Co-authored-by: b <b@b>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
We were applying the low-memory system patch to webpack.config.js
on systems with < 4GB memory.
From now on, we also let people force-enable patching by toggling the
`matrix_client_element_container_image_self_build_low_memory_system_patch_enabled`
variable.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1357
In short, the problem is that older Postgres versions store passwords
hashed as md5. When you dump such a database, the dump naturally also
contains md5-hashed passwords.
Restoring from that dump used to create users and updates their passwords
with these md5 hashes.
However, Postgres v14 prefers does not like md5-hashed passwords now (by default),
which breaks connectivity. Postgres v14 prefers `scram-sha-256` for
authentication.
Our solution is to just ignore setting passwords (`ALTER ROLE ..`
statements) when restoring dumps. We don't need to set passwords as
defined in the dump anyway, because the playbook creates users
and manages their passwords by itself.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1340
**TLDR**: We now have optional experimental [Dendrite](https://github.com/matrix-org/dendrite) homeserver support for new installations. **Existing (Synapse) installations need to be updated**, because some internals changed. See [Adapting the configuration for existing Synapse installations](#adapting-the-configuration-for-existing-synapse-installations).
[Jip J. Dekker](https://github.com/Dekker1) did the [initial work](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/818) of adding [Dendrite](https://github.com/matrix-org/dendrite) support to the playbook back in January 2021. Lots of work (and time) later, Dendrite support is finally ready for testing.
We believe that 2022 will be the year of the non-Synapse Matrix server!
The playbook was previously quite [Synapse](https://github.com/matrix-org/synapse)-centric, but can now accommodate multiple homeserver implementations. Only one homeserver implementation can be active (installed) at a given time.
**Synapse is still the default homeserver implementation** installed by the playbook. A new variable (`matrix_homeserver_implementation`) controls which server implementation is enabled (`synapse` or `dendrite` at the given moment).
### Adapting the configuration for existing Synapse installations
Because the playbook is not so Synapse-centric anymore, a small configuration change is necessary for existing installations to bring them up to date.
The `vars.yml` file for **existing installations will need to be updated** by adding this **additional configuration**:
```yaml
# All secrets keys are now derived from `matrix_homeserver_generic_secret_key`, not from `matrix_synapse_macaroon_secret_key`.
# To keep them all the same, define `matrix_homeserver_generic_secret_key` in terms of `matrix_synapse_macaroon_secret_key`.
# Using a new secret value for this configuration key is also possible and should not cause any problems.
#
# Fun fact: new installations (based on the new `examples/vars.yml` file) do this in reverse.
# That is, the Synapse macaroon secret is derived from `matrix_homeserver_generic_secret_key`.
Finally, **to try out Dendrite**, we recommend that you **use a new server** and the following addition to your `vars.yml` configuration:
```yaml
matrix_homeserver_implementation: dendrite
```
**The homeserver implementation of an existing server cannot be changed** (e.g. from Synapse to Dendrite) without data loss.
We're excited to gain support for other homeserver implementations, like [Conduit](https://conduit.rs/), etc!
## Honoroit bot support
Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook can now help you set up [Honoroit](https://gitlab.com/etke.cc/honoroit) - a helpdesk bot.
See our [Setting up Honoroit](docs/configuring-playbook-bot-honoroit.md) documentation to get started.
# 2022-01-06
## Cinny support
Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook now supports [Cinny](https://cinny.in/) - a new simple, elegant and secure Matrix client.
By default, we still install Element. Still, people who'd like to try Cinny out can now install it via the playbook.
Additional details are available in [Setting up Cinny](docs/configuring-playbook-client-cinny.md).
# 2021-12-22
## Twitter bridging support via mautrix-twitter
Thanks to [Matthew Cengia](https://github.com/mattcen) and [Shreyas Ajjarapu](https://github.com/shreyasajj), besides [mx-puppet-twitter](docs/configuring-playbook-bridge-mx-puppet-twitter.md), bridging to [Twitter](https://twitter.com/) can now also happen with [mautrix-twitter](docs/configuring-playbook-bridge-mautrix-twitter.md).
# 2021-12-14
## (Security) Users of the Signal bridge may wish to upgrade it to work around log4j vulnerability
Recently, a security vulnerability affecting the Java logging package `log4j` [has been discovered](https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java). Software that uses this Java package is potentially vulnerable.
One such piece of software that is part of the playbook is the [mautrix-signal bridge](./docs/configuring-playbook-bridge-mautrix-signal.md), which [has been patched already](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1452). If you're running this bridge, you may wish to [upgrade](./docs/maintenance-upgrading-services.md).
# 2021-11-11
## Dropped support for Postgres v9.6
Postgres v9.6 reached its end of life today, so the playbook will refuse to run for you if you're still on that version.
Synapse still supports v9.6 (for now), but we're retiring support for it early, to avoid having to maintain support for so many Postgres versions. Users that are still on Postgres v9.6 can easily [upgrade Postgres](docs/maintenance-postgres.md#upgrading-postgresql) via the playbook.
# 2021-10-23
## Hangouts bridge no longer updated, superseded by a Googlechat bridge
@ -244,6 +330,8 @@ The fact that we've renamed Synapse's database from `homeserver` to `synapse` (i
## (Breaking Change) The mautrix-facebook bridge now requires a Postgres database
**Update from 2021-11-15**: SQLite support has been re-added to the mautrix-facebook bridge in [v0.3.2](https://github.com/mautrix/facebook/releases/tag/v0.3.2). You can ignore this changelog entry.
A new version of the [mautrix-facebook](https://github.com/tulir/mautrix-facebook) bridge has been released. It's a full rewrite of its backend and the bridge now requires Postgres. New versions of the bridge can no longer run on SQLite.
**TLDR**: if you're NOT using an [external Postgres server](docs/configuring-playbook-external-postgres.md) and have NOT forcefully kept the bridge on SQLite during [The big move to all-on-Postgres (potentially dangerous)](#the-big-move-to-all-on-postgres-potentially-dangerous), you will be automatically upgraded without manual intervention. All you need to do is send a `login` message to the Facebook bridge bot again.
@ -19,6 +19,8 @@ Using this playbook, you can get the following services configured on your serve
- (optional, default) a [Synapse](https://github.com/matrix-org/synapse) homeserver - storing your data and managing your presence in the [Matrix](http://matrix.org/) network
- (optional) a [Dendrite](https://github.com/matrix-org/dendrite) homeserver - storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Dendrite is a second-generation Matrix homeserver written in Go, an alternative to Synapse.
- (optional) [Amazon S3](https://aws.amazon.com/s3/) storage for Synapse's content repository (`media_store`) files using [Goofys](https://github.com/kahing/goofys)
- (optional, default) [PostgreSQL](https://www.postgresql.org/) database for Synapse. [Using an external PostgreSQL server](docs/configuring-playbook-external-postgres.md) is also possible.
@ -51,6 +53,8 @@ Using this playbook, you can get the following services configured on your serve
- (optional) the [mautrix-facebook](https://github.com/mautrix/facebook) bridge for bridging your Matrix server to [Facebook](https://facebook.com/)
- (optional) the [mautrix-twitter](https://github.com/mautrix/twitter) bridge for bridging your Matrix server to [Twitter](https://twitter.com/)
- (optional) the [mautrix-hangouts](https://github.com/mautrix/hangouts) bridge for bridging your Matrix server to [Google Hangouts](https://en.wikipedia.org/wiki/Google_Hangouts)
- (optional) the [mautrix-googlechat](https://github.com/mautrix/googlechat) bridge for bridging your Matrix server to [Google Chat](https://en.wikipedia.org/wiki/Google_Chat)
@ -97,6 +101,8 @@ Using this playbook, you can get the following services configured on your serve
- (optional) [matrix-reminder-bot](https://github.com/anoadragon453/matrix-reminder-bot) for scheduling one-off & recurring reminders and alarms - see [docs/configuring-playbook-bot-matrix-reminder-bot.md](docs/configuring-playbook-bot-matrix-reminder-bot.md) for setup documentation
- (optional) [honoroit](https://gitlab.com/etke.cc/honoroit) helpdesk bot - see [docs/configuring-playbook-bot-honoroit.md](docs/configuring-playbook-bot-honoroit.md) for setup documentation
- (optional) [Go-NEB](https://github.com/matrix-org/go-neb) multi functional bot written in Go - see [docs/configuring-playbook-bot-go-neb.md](docs/configuring-playbook-bot-go-neb.md) for setup documentation
- (optional) [Mjolnir](https://github.com/matrix-org/mjolnir), a moderation tool for Matrix - see [docs/configuring-playbook-bot-mjolnir.md](docs/configuring-playbook-bot-mjolnir.md) for setup documentation
@ -111,6 +117,8 @@ Using this playbook, you can get the following services configured on your serve
- (optional) the [Hydrogen](https://github.com/vector-im/hydrogen-web) web client - see [docs/configuring-playbook-client-hydrogen.md](docs/configuring-playbook-client-hydrogen.md) for setup documentation
- (optional) the [Cinny](https://github.com/ajbura/cinny) web client - see [docs/configuring-playbook-client-cinny.md](docs/configuring-playbook-client-cinny.md) for setup documentation
Basically, this playbook aims to get you up-and-running with all the necessities around Matrix, without you having to do anything else.
**Note**: the list above is exhaustive. It includes optional or even some advanced components that you will most likely not need.
For `amd64`, prebuilt container images (see the [container images we use](container-images.md)) are used everywhere, because all images are available for this architecture.
For `amd64`, prebuilt container images (see the [container images we use](container-images.md)) are used for all components (except [Hydrogen](configuring-playbook-client-hydrogen.md), which goes through self-building).
For other architectures, components which have a prebuilt image make use of it. If the component is not available for the specific architecture, [self-building](self-building.md) will be used. Not all components support self-building though, so your mileage may vary.
@ -4,7 +4,7 @@ An AWX setup for managing multiple Matrix servers.
This section is used in an AWX system that can create and manage multiple [Matrix](http://matrix.org/) servers. You can issue members an AWX login to their own 'organisation', which they can use to manage/configure 1 to N servers.
Members can be assigned a server from Digitalocean, or they can connect their own on-premises server. This script is free to use in a commercial context with the 'MemberPress Plus' and 'WP Oauth Sever' addons. It can also be run in a non-commercial context.
Members can be assigned a server from Digitalocean, or they can connect their own on-premises server. These playbooks are free to use in a commercial context with the 'MemberPress Plus' plugin. They can also be run in a non-commercial context.
The AWX system is arranged into 'members' each with their own 'subscriptions'. After creating a subscription the user enters the 'provision stage' where they defined the URLs they will use, the servers location and whether or not there's already a website at the base domain. They then proceed onto the 'deploy stage' where they can configure their Matrix server.
@ -21,12 +21,7 @@ The following repositories allow you to copy and use this setup:
[Ansible Provision Server](https://gitlab.com/GoMatrixHosting/ansible-provision-server) - Used by AWX members to perform initial configuration of their DigitalOcean or On-Premises server.
[GMHosting External Tools](https://gitlab.com/GoMatrixHosting/gmhosting-external-tools) - Extra tools we run outside of AWX, some of which are experimental.
## Does I need an AWX setup to use this? How do I configure it?
@ -38,7 +33,6 @@ For simpler installation steps you can use to get started with this system, chec
## Does I need a front-end WordPress site? And a DigitalOcean account?
You do not need a front-end WordPress site or any of the mentioned WordPress plugins to use this setup. It can be run on it's own in a non-commercial context.
You also don't need a DigitalOcean account, but this will limit you to only being able to connect 'On-Premises' servers.
You do not need a front-end WordPress site or the MemberPress plugin to use this setup. It can be run on it's own in a non-commercial context.
You also don't need a DigitalOcean account, although this will limit you to only being able to connect 'On-Premises' servers.
@ -57,6 +58,7 @@ The `sygnal.<your-domain>` subdomain may be necessary, because this playbook cou
The `hydrogen.<your-domain>` subdomain may be necessary, because this playbook could install the [Hydrogen](https://github.com/vector-im/hydrogen-web) web client. The installation of Hydrogen is disabled by default, it is not a core required component. To learn how to install it, see our [configuring Hydrogen guide](configuring-playbook-client-hydrogen.md). If you do not wish to set up Hydrogen, feel free to skip the `hydrogen.<your-domain>` DNS record.
The `cinny.<your-domain>` subdomain may be necessary, because this playbook could install the [Cinny](https://github.com/ajbura/cinny) web client. The installation of cinny is disabled by default, it is not a core required component. To learn how to install it, see our [configuring cinny guide](configuring-playbook-client-cinny.md). If you do not wish to set up cinny, feel free to skip the `cinny.<your-domain>` DNS record.
The playbook can install and configure [Honoroit](https://gitlab.com/etke.cc/honoroit) for you.
It's a bot you can use to setup **your own helpdesk on matrix**
See the project's [documentation](https://gitlab.com/etke.cc/honoroit#how-it-looks-like) to learn what it does with screenshots and why it might be useful to you.
## Registering the bot user
By default, the playbook will set up the bot with a username like this: `@honoroit:DOMAIN`.
(to use a different username, adjust the `matrix_bot_honoroit_login` variable).
You **need to register the bot user manually** before setting up the bot. You can use the playbook to [register a new user](registering-users.md):
To use the bot, invite the `@honoroit:DOMAIN` to the room you specified in config, after that any matrix user can send a message to the `@honoroit:DOMAIN` to start a new thread in that room.
Send `!ho help` to the room to see the bot's help menu for additional commands.
You can also refer to the upstream [documentation](https://gitlab.com/etke.cc/honoroit#features).
**Note**: bridging to [Twitter](https://twitter.com/) can also happen via the [mx-puppet-twitter](configuring-playbook-bridge-mx-puppet-twitter.md) bridge supported by the playbook.
The playbook can install and configure [mautrix-twitter](https://github.com/mautrix/twitter) for you.
See the project's [documentation](https://github.com/mautrix/twitter) to learn what it does and why it might be useful to you.
```yaml
matrix_mautrix_twitter_enabled: true
```
## Set up Double Puppeting
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
### Method 1: automatically, by enabling Shared Secret Auth
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
### Method 2: manually, by asking each user to provide a working access token
This method is currently not available for the Mautrix-Twitter bridge, but is on the [roadmap](https://github.com/mautrix/twitter/blob/master/ROADMAP.md) under Misc/Manual login with `login-matrix`
## Usage
1. You then need to start a chat with `@twitterbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
2. Send login-cookie to start the login. The bot should respond with instructions on how to proceed.
You can learn more here about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/twitter/authentication.html).
After successfully enabling bridging, you may wish to [set up Double Puppeting](#set-up-double-puppeting), if you haven't already done so.
**Note**: bridging to [Twitter](https://twitter.com/) can also happen via the [mautrix-twitter](configuring-playbook-bridge-mautrix-twitter.md) bridge supported by the playbook.
The playbook can install and configure
[mx-puppet-twitter](https://github.com/Sorunome/mx-puppet-twitter) for you.
Etherpad comes with a admin web-UI which is disabled by default. You can enable it by setting a username and password in your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
```yaml
matrix_etherpad_admin_username: admin
matrix_etherpad_admin_password: some-password
```
The admin web-UI should then be available on: `https://dimension.<your-domain>/etherpad/admin`
### Managing / Deleting old pads
If you want to manage and remove old unused pads from Etherpad, you will first need to able Admin access as described above.
Then from the plugin manager page (`https://dimension.<your-domain>/etherpad/admin/plugins`), install the `adminpads2` plugin. Once installed, you should have a "Manage pads" section in the Admin web-UI.
## Known issues
If your Etherpad widget fails to load, this might be due to Dimension generating a Pad name so long, the Etherpad app rejects it.
@ -41,13 +41,23 @@ If you're fine with such an open Jitsi instance, please skip to [Apply changes](
If you would like to control who is allowed to open meetings on your new Jitsi instance, then please follow this step to enable Jitsi's authentication and guests mode. With authentication enabled, all meeting rooms have to be opened by a registered user, after which guests are free to join. If a registered host is not yet present, guests are put on hold in individual waiting rooms.
Add these two lines to your `inventory/host_vars/matrix.DOMAIN/vars.yml` configuration:
Add these lines to your `inventory/host_vars/matrix.DOMAIN/vars.yml` configuration:
```yaml
matrix_jitsi_enable_auth: true
matrix_jitsi_enable_guests: true
matrix_jitsi_prosody_auth_internal_accounts:
- username: "jitsi-moderator"
password: "secret-password"
- username: "another-user"
password: "another-password"
```
**Caution:** Accounts added here and subsquently removed will not be automatically removed from the Prosody server until user account cleaning is integrated into the playbook.
**If you get an error** like this: "Error: Account creation/modification not supported.", it's likely that you had previously installed Jitsi without auth/guest support. In such a case, you should look into [Rebuilding your Jitsi installation](#rebuilding-your-jitsi-installation).
### (Optional) LDAP authentication
The default authentication mode of Jitsi is `internal`, however LDAP is also supported. An example LDAP configuration could be:
@ -122,19 +132,6 @@ You may want to **limit the maximum video resolution**, to save up resources on
Then re-run the playbook: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`
## Required if configuring Jitsi with internal authentication: register new users
Until this gets integrated into the playbook, we need to register new users / meeting hosts for Jitsi manually.
Please SSH into your matrix host machine and execute the following command targeting the `matrix-jitsi-prosody` container:
Run this command for each user you would like to create, replacing `<USERNAME>` and `<PASSWORD>` accordingly. After you've finished, please exit the host.
**If you get an error** like this: "Error: Account creation/modification not supported.", it's likely that you had previously installed Jitsi without auth/guest support. In such a case, you should look into [Rebuilding your Jitsi installation](#rebuilding-your-jitsi-installation).
# See below for an example of how to use a locally-stored static policy
matrix_corporal_policy_provider_config: |
{
"Type": "http",
@ -74,10 +75,48 @@ Matrix Corporal operates with a specific Matrix user on your server.
By default, it's `matrix-corporal` (controllable by the `matrix_corporal_reconciliation_user_id_local_part` setting, see above).
No matter what Matrix user id you configure to run it with, make sure that:
- the Matrix Corporal user is created by [registering it](registering-users.md). Use a password you remember, as you'll need to log in from time to time to create or join rooms
- the Matrix Corporal user is created by [registering it](registering-users.md)**with administrator privileges**. Use a password you remember, as you'll need to log in from time to time to create or join rooms
- the Matrix Corporal user is joined and has Admin/Moderator-level access to any rooms you want it to manage
### Using a locally-stored static policy
If you'd like to use a [static policy file](https://github.com/devture/matrix-corporal/blob/master/docs/policy-providers.md#static-file-pull-style-policy-provider), you can use a configuration like this:
To learn more about what the policy configuration, see the matrix-corporal documentation on [policy](https://github.com/devture/matrix-corporal/blob/master/docs/policy.md).
Each time you update the policy in your `vars.yml` file, you'd need to re-run the playbook and restart matrix-corporal (`--tags=setup-all,start` or `--tags=setup-aux-files,setup-corporal,start`).
@ -64,14 +64,14 @@ Once you've followed the [Preparation](#preparation) guide above, you can take a
### Using your own external caddy webserver
After following the [Preparation](#preparation) guide above, you can take a look at the [examples/caddy](../examples/caddy) directory for a sample configuration.
After following the [Preparation](#preparation) guide above, you can take a look at the [examples/caddy](../examples/caddy) directory and [examples/caddy2](../examples/caddy2) directory for a sample configuration for Caddy v1 and v2, respectively.
### Using your own HAproxy reverse proxy
After following the [Preparation](#preparation) guide above, you can take a look at the [examples/haproxy](../examples/haproxy) directory for a sample configuration. In this case HAproxy is used as a reverse proxy and a simple Nginx container is used to serve statically `.well-known` files.
### Using another external webserver
Feel free to look at the [examples/apache](../examples/apache) directory, or the [template files in the matrix-nginx-proxy role](../roles/matrix-nginx-proxy/templates/conf.d/).
Feel free to look at the [examples/apache](../examples/apache) directory, or the [template files in the matrix-nginx-proxy role](../roles/matrix-nginx-proxy/templates/nginx/conf.d/).
## Method 2: Fronting the integrated nginx reverse-proxy webserver with another reverse-proxy
@ -111,6 +111,9 @@ matrix_coturn_enabled: false
# Trust the reverse proxy to send the correct `X-Forwarded-Proto` header as it is handling the SSL connection.
matrix_nginx_proxy_trust_forwarded_proto: true
# Trust and use the other reverse proxy's `X-Forwarded-For` header.
`matrix_synapse_metrics_enabled`|Set this to `true` to make Synapse expose metrics (locally, on the container network)
`matrix_nginx_proxy_proxy_synapse_metrics`|Set this to `true` to make matrix-nginx-proxy expose the Synapse metrics at `https://matrix.DOMAIN/_synapse/metrics`
`matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_enabled`|Set this to `true` to password-protect (using HTTP Basic Auth) `https://matrix.DOMAIN/_synapse/metrics` (the username is always `prometheus`, the password is defined in `matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_key`)
`matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_key`|Set this to a password to use for HTTP Basic Auth for protecting `https://matrix.DOMAIN/_synapse/metrics` (the username is always `prometheus` - it's not configurable)
`matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_key`|Set this to a password to use for HTTP Basic Auth for protecting `https://matrix.DOMAIN/_synapse/metrics` (the username is always `prometheus` - it's not configurable). Do not write the password in plain text. See `man 1 htpasswd` or use `htpasswd -c mypass.htpasswd prometheus` to generate the expected hash for nginx.
`matrix_server_fqn_grafana`|Use this variable to override the domain at which the Grafana web user-interface is at (defaults to `stats.DOMAIN`)
### Collecting worker metrics to an external Prometheus server
If you are using workers (`matrix_synapse_workers_enabled`) and have enabled `matrix_nginx_proxy_proxy_synapse_metrics` as described above, the playbook will also automatically proxy the all worker threads's metrics to `https://matrix.DOMAIN/_synapse-worker-TYPE-ID/metrics`, where `TYPE` corresponds to the type and `ID` to the instanceId of a worker as exemplified in `matrix_synapse_workers_enabled_list`.
The playbook also generates an exemplary prometheus.yml config file (`matrix_base_data_path/external_prometheus.yml.template`) with all the correct paths which you can copy to your Prometheus server and adapt to your needs, especially edit the specified `password_file` path and contents and path to your `synapse-v2.rules`.
### Collecting system and Postgres metrics to an external Prometheus server (advanced)
When you normally enable the Prometheus and Grafana via the playbook, it will also show general system (via node-exporter) and Postgres (via postgres-exporter) stats. If you are instead collecting your metrics to an external Prometheus server, you can follow this advanced configuration example to also export these stats.
@ -30,6 +30,8 @@ These services are enabled and used by default, but you can turn them off, if yo
These services are not part of our default installation, but can be enabled by [configuring the playbook](configuring-playbook.md) (either before the initial installation or any time later):
- [matrixdotorg/dendrite-monolith](https://hub.docker.com/r/matrixdotorg/dendrite-monolith/) - the official [Dendrite](https://github.com/matrix-org/dendrite) Matrix homeserver (optional)
- [ewoutp/goofys](https://hub.docker.com/r/ewoutp/goofys/) - the [Goofys](https://github.com/kahing/goofys) Amazon [S3](https://aws.amazon.com/s3/) file-system-mounting program (optional)
- [etherpad/etherpad](https://hub.docker.com/r/etherpad/etherpad/) - the [Etherpad](https://etherpad.org) realtime collaborative text editor that can be used in a Jitsi audio/video call or integrated as a widget into Matrix chat rooms via the Dimension integration manager (optional)
@ -46,6 +48,8 @@ These services are not part of our default installation, but can be enabled by [
- [mautrix/facebook](https://mau.dev/mautrix/facebook/container_registry) - the [mautrix-facebook](https://github.com/mautrix/facebook) bridge to [Facebook](https://facebook.com/) (optional)
- [mautrix/twitter](https://mau.dev/mautrix/twitter/container_registry) - the [mautrix-twitter](https://github.com/mautrix/twitter) bridge to [Twitter](https://twitter.com/) (optional)
- [mautrix/hangouts](https://mau.dev/mautrix/hangouts/container_registry) - the [mautrix-hangouts](https://github.com/mautrix/hangouts) bridge to [Google Hangouts](https://en.wikipedia.org/wiki/Google_Hangouts) (optional)
- [mautrix/googlechat](https://mau.dev/mautrix/googlechat/container_registry) - the [mautrix-googlechat](https://github.com/mautrix/googlechat) bridge to [Google Chat](https://en.wikipedia.org/wiki/Google_Chat) (optional)
@ -90,6 +94,8 @@ These services are not part of our default installation, but can be enabled by [
- [anoa/matrix-reminder-bot](https://hub.docker.com/r/anoa/matrix-reminder-bot) - the [matrix-reminder-bot](https://github.com/anoadragon453/matrix-reminder-bot) bot for one-off & recurring reminders and alarms (optional)
- [etke.cc/honoroit](https://gitlab.com/etke.cc/honoroit/container_registry) - the [honoroit](https://gitlab.com/etke.cc/honoroit) helpdesk bot (optional)
- [matrixdotorg/go-neb](https://hub.docker.com/r/matrixdotorg/go-neb) - the [Go-NEB](https://github.com/matrix-org/go-neb) bot (optional)
- [matrixdotorg/mjolnir](https://hub.docker.com/r/matrixdotorg/mjolnir) - the [mjolnir](https://github.com/matrix-org/mjolnir) moderation bot (optional)
@ -12,7 +12,8 @@ If your database name differs, be sure to change `matrix_synapse_database_databa
The playbook supports importing Postgres dump files in **text** (e.g. `pg_dump > dump.sql`) or **gzipped** formats (e.g. `pg_dump | gzip -c > dump.sql.gz`).
Importing multiple databases (as dumped by `pg_dumpall`) is also supported.
Importing multiple databases (as dumped by `pg_dumpall`) is also supported.
But the migration might be a good moment, to "reset" a not properly working bridge. Be aware, that it might affect all users (new link to bridge, new roomes, ...)
Before doing the actual import, **you need to upload your Postgres dump file to the server** (any path is okay).
A table ownership issue can occur if you are importing from a Synapse installation which was both:
- migrated from SQLite to Postgres, and
@ -48,7 +50,7 @@ where `synapse_user` is the database username from the previous Synapse installa
This can be verified by examining the dump for ALTER TABLE statements which set OWNER TO that username:
```Shell
$ grep "ALTER TABLE" homeserver.sql"
$ grep "ALTER TABLE" homeserver.sql
ALTER TABLE public.access_tokens OWNER TO synapse_user;
ALTER TABLE public.account_data OWNER TO synapse_user;
ALTER TABLE public.account_data_max_stream_id OWNER TO synapse_user;
@ -60,10 +62,10 @@ ALTER TABLE public.application_services_state OWNER TO synapse_user;
It can be worked around by changing the username to `synapse`, for example by using `sed`:
```Shell
$ sed -i "s/synapse_user/synapse/g" homeserver.sql
$ sed -i "s/OWNER TO synapse_user;/OWNER TO synapse;/g" homeserver.sql
```
This uses sed to perform an 'in-place' (`-i`) replacement globally (`/g`), searching for `synapseuser` and replacing with `synapse` (`s/synapse_user/synapse`). If your database username was different, change `synapse_user` to that username instead.
This uses sed to perform an 'in-place' (`-i`) replacement globally (`/g`), searching for `synapse_user` and replacing with `synapse` (`s/synapse_user/synapse`). If your database username was different, change `synapse_user` to that username instead. Expand search/replace statement as shown in example above, in case of old user name like `matrix` - replacing `matrix` only would... well - you can imagine.
Note that if the previous import failed with an error it may have made changes which are incompatible with re-running the import task right away; if you do so it may fail with an error such as:
@ -71,6 +73,8 @@ Note that if the previous import failed with an error it may have made changes w
ERROR: relation \"access_tokens\" already exists
```
### Repeat import
In this case you can use the command suggested in the import task to clear the database before retrying the import:
```Shell
@ -79,4 +83,20 @@ In this case you can use the command suggested in the import task to clear the d
# systemctl start matrix-postgres
```
Once the database is clear and the ownership of the tables has been fixed in the SQL file, the import task should succeed.
Now on your local machine run `ansible-playbook -i inventory/hosts setup.yml --tags=setup-postgres` to prepare the database roles etc.
If not, you probably get this error. `synapse` is the correct table owner, but the role is missing in database.
```
"ERROR: role synapse does not exist"
```
Once the database is clear and the ownership of the tables has been fixed in the SQL file, the import task should succeed.
Check, if `--dbname` is set to `synapse` (not `matrix`) and replace paths (or even better, copy this line from your terminal)
If you've [configured your DNS](configuring-dns.md) and have [configured the playbook](configuring-playbook.md), you can start the installation procedure.
**Note**: if you don't use SSH keys for authentication, but rather a regular password, you may need to add `--ask-pass` to the above (and all other) Ansible commands.
**Note**: if you **do** use SSH keys for authentication, **and** use a non-root user to *become* root (sudo), you may need to add `-K` (`--ask-become-pass`) to the above (and all other) Ansible commands.
The above command **doesn't start any services just yet** (another step does this later - below). Feel free to **re-run this setup command any time** you think something is off with the server configuration.
The above command **doesn't start any services just yet** (another step does this later - below).
**Notes**:
- if you **don't** use SSH keys for authentication, but rather a regular password, you may need to add `--ask-pass` to the above (and all other) Ansible commands.
- if you **do** use SSH keys for authentication, **and** use a non-root user to *become* root (sudo), you may need to add `-K` (`--ask-become-pass`) to the above (and all other) Ansible commands.
Feel free to **re-run this setup command any time** you think something is off with the server configuration.
## 2. Things you might want to do after installing
## Things you might want to do after installing
After installing, but before starting the services, you may want to do additional things like:
**Before starting the services**, you may want to do additional things like:
- [Importing an existing SQLite database (from another Synapse installation)](importing-synapse-sqlite.md) (optional)
@ -28,20 +28,22 @@ After installing, but before starting the services, you may want to do additiona
- [Importing `media_store` data files from an existing Synapse installation](importing-synapse-media-store.md) (optional)
## Starting the services
## 3. Starting the services
When you're ready to start the Matrix services (and set them up to auto-start in the future):
When you're ready to start the Matrix services (and set them up to auto-start in the future), run this command:
Now that services are running, you need to **finalize the installation process** (required for federation to work!) by [Configuring Service Discovery via .well-known](configuring-well-known.md)
## 4. Finalize the installation
Now that services are running, you need to **finalize the installation process** (required for federation to work!) by [Configuring Service Discovery via .well-known](configuring-well-known.md).
## Things to do next
## 5. Things to do next
If you have started services and **finalized the installation process** (required for federation to work!) by [Configuring Service Discovery via .well-known](configuring-well-known.md), you can:
After you have started the services and **finalized the installation process** (required for federation to work!) by [Configuring Service Discovery via .well-known](configuring-well-known.md), you can:
- [check if services work](maintenance-checking-services.md)
- or [create your first Matrix user account](registering-users.md)
"question_description": "The OAuth2 'CLIENT ID' which can be found in the 'OAuth2' tab of your new discord application: https://discord.com/developers/applications",
"required": true,
"min": 0,
"max": 128,
"default": "{{ matrix_appservice_discord_client_id | trim }}",
"question_description": "The Bot 'TOKEN' which can be found in the 'Bot' tab of your new discord application: https://discord.com/developers/applications",
"required": true,
"min": 0,
"max": 256,
"default": "{{ matrix_appservice_discord_bot_token | trim }}",
"question_description": "The username you would like to be automatically joined and promoted to administrator (PL100) in bridged rooms. Exclude the '@' and server name postfix. So to create @stevo:example.org just enter 'stevo'.",
"required": false,
"min": 0,
"max": 1024,
"default": "",
"choices": "",
"new_question": true,
"variable": "awx_appservice_discord_admin_user",
"type": "text"
},
{
"question_name": "Auto-Admin Rooms",
"question_description": "A list of rooms you want the user to be automatically joined and promoted to administrator (PL100) in. These should be the internal IDs (for example '!axfBUsKhfAjSMBdjKX:example.org') separated by newlines.",
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
register:awx_synapse_container_ip
- name:Collect access token for janitor user
- name:Collect access token for @admin-janitor user
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
- name:Count number of rooms with no local users
delegate_to:127.0.0.1
shell:|
@ -84,7 +84,7 @@
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1) or (awx_purge_mode.find("Skip purging rooms [faster]") != -1)
- name:Revert 'Deploy/Update a Server' job template
when:(awx_purge_mode.find("Perform final shrink") != -1)
- name:Revert 'Deploy/Update a Server' job template
@ -272,7 +272,7 @@
when:(awx_purge_mode.find("Perform final shrink") != -1)
no_log:True
- name:Print total number of rooms processed
- name:Print total number of rooms processed
debug:
msg:'{{ awx_rooms_total.stdout }}'
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
matrix_ntpd_package:"{{ 'systemd-timesyncd' if (ansible_distribution == 'CentOS' and ansible_distribution_major_version > '7') or (ansible_distribution == 'Ubuntu' and ansible_distribution_major_version > '18') else 'ntp' }}"
matrix_ntpd_service:"{{ 'systemd-timesyncd' if (ansible_distribution == 'CentOS' and ansible_distribution_major_version > '7') or (ansible_distribution == 'Ubuntu' and ansible_distribution_major_version > '18') or ansible_distribution == 'Archlinux' else ('ntpd' if ansible_os_family == 'RedHat' else 'ntp') }}"
matrix_ntpd_package:"{{ 'systemd-timesyncd' if (ansible_distribution == 'CentOS' and ansible_distribution_major_version > '7') or (ansible_distribution == 'Ubuntu' and ansible_distribution_major_version > '18') else ( 'systemd' if ansible_os_family == 'Suse' else 'ntp' ) }}"
matrix_ntpd_service:"{{ 'systemd-timesyncd' if (ansible_distribution == 'CentOS' and ansible_distribution_major_version > '7') or (ansible_distribution == 'Ubuntu' and ansible_distribution_major_version > '18') or ansible_distribution == 'Archlinux' or ansible_os_family == 'Suse' else ('ntpd' if ansible_os_family == 'RedHat' else 'ntp') }}"
matrix_well_known_matrix_client_configuration_extension:"{{ matrix_well_known_matrix_client_configuration_extension_json|from_json if matrix_well_known_matrix_client_configuration_extension_json|from_json is mapping else {} }}"
# Holds the final `/.well-known/matrix/client` configuration (a combination of the default and its extension).
# You most likely don't need to touch this variable. Instead, see `matrix_well_known_matrix_client_configuration_default` and `matrix_well_known_matrix_client_configuration_extension_json`.
matrix_well_known_matrix_server_configuration_extension:"{{ matrix_well_known_matrix_server_configuration_extension_json|from_json if matrix_well_known_matrix_server_configuration_extension_json|from_json is mapping else {} }}"
# Holds the final `/.well-known/matrix/server` configuration (a combination of the default and its extension).
# You most likely don't need to touch this variable. Instead, see `matrix_well_known_matrix_server_configuration_default` and `matrix_well_known_matrix_server_configuration_extension_json`.
- name:Fail if trying to self-build on Ansible < 2.8
fail:
msg:"To self-build the Element image, you should use Ansible 2.8 or higher. See docs/ansible.md"
when:"ansible_version.major == 2 and ansible_version.minor < 8 and matrix_appservice_slack_container_self_build and matrix_appservice_slack_enabled"
when:"ansible_version.major == 2 and ansible_version.minor < 8 and matrix_appservice_slack_container_image_self_build and matrix_appservice_slack_enabled"
# If the matrix-synapse role is not used, `matrix_synapse_role_executed` won't exist.
# We don't want to fail in such cases.
@ -44,7 +44,7 @@
msg:>-
Trying to append Slack Appservice's reverse-proxying configuration to matrix-nginx-proxy,
but it's pointless since the matrix-nginx-proxy role had already executed.
To fix this, please change the order of roles in your plabook,
To fix this, please change the order of roles in your playbook,
so that the matrix-nginx-proxy role would run after the matrix-bridge-appservice-slack role.