Matrix/matrix-docker-ansible-deploy
1
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-11-14 10:04:46 +08:00
Code Issues Packages Projects Releases Wiki Activity
19ed8d1d17
matrix-docker-ansible-deploy/examples/vars.yml

36 lines
1.6 KiB
YAML
Raw Normal View History

Rename some variables
2019-02-28 17:51:09 +08:00
# The bare domain name which represents your Matrix identity.
# Matrix user ids for your server will be of the form (`@user:<matrix-domain>`).
Initial commit
2017-08-01 04:07:30 +08:00
#
Rename some variables
2019-02-28 17:51:09 +08:00
# Note: this playbook does not touch the server referenced here.
# Installation happens on another server ("matrix.<matrix-domain>").
Initial commit
2017-08-01 04:07:30 +08:00
#
Reorganize Postgres access (breaking change) In short, this makes Synapse a 2nd class citizen, preparing for a future where it's just one-of-many homeserver software options. We also no longer have a default Postgres superuser password, which improves security. The changelog explains more as to why this was done and how to proceed from here.
2021-01-22 18:23:00 +08:00
# If you've deployed using the wrong domain, you'll have to run the Uninstalling step,
Fix typo and wording
2020-09-13 14:51:04 +08:00
# because you can't change the Domain after deployment.
Comment in host-cars
2020-09-12 17:04:16 +08:00
#
Rename some variables
2019-02-28 17:51:09 +08:00
# Example value: example.com
matrix_domain: YOUR_BARE_DOMAIN_NAME_HERE
Initial commit
2017-08-01 04:07:30 +08:00
Rename some variables
2019-02-28 17:51:09 +08:00
# This is something which is provided to Let's Encrypt when retrieving SSL certificates for domains.
Initial commit
2017-08-01 04:07:30 +08:00
#
Rename some variables
2019-02-28 17:51:09 +08:00
# In case SSL renewal fails at some point, you'll also get an email notification there.
Initial commit
2017-08-01 04:07:30 +08:00
#
Rename some variables
2019-02-28 17:51:09 +08:00
# If you decide to use another method for managing SSL certifites (different than the default Let's Encrypt),
# you won't be required to define this variable (see `docs/configuring-playbook-ssl-certificates.md`).
Initial commit
2017-08-01 04:07:30 +08:00
#
Rename some variables
2019-02-28 17:51:09 +08:00
# Example value: someone@example.com
Reorganize Postgres access (breaking change) In short, this makes Synapse a 2nd class citizen, preparing for a future where it's just one-of-many homeserver software options. We also no longer have a default Postgres superuser password, which improves security. The changelog explains more as to why this was done and how to proceed from here.
2021-01-22 18:23:00 +08:00
matrix_ssl_lets_encrypt_support_email: ''
Switch Docker image to official one Switching from from avhost/docker-matrix (silviof/docker-matrix) to matrixdotorg/synapse. The avhost/docker-matrix (silviof/docker-matrix) image used to bundle in the coturn STUN/TURN server, so as part of the move, we're separating this to a separately-ran service (matrix-coturn.service, powered by instrumentisto/coturn-docker-image)
2018-05-26 02:58:53 +08:00
Make roles more independent of one another With this change, the following roles are now only dependent on the minimal `matrix-base` role: - `matrix-corporal` - `matrix-coturn` - `matrix-mailer` - `matrix-mxisd` - `matrix-postgres` - `matrix-riot-web` - `matrix-synapse` The `matrix-nginx-proxy` role still does too much and remains dependent on the others. Wiring up the various (now-independent) roles happens via a glue variables file (`group_vars/matrix-servers`). It's triggered for all hosts in the `matrix-servers` group. According to Ansible's rules of priority, we have the following chain of inclusion/overriding now: - role defaults (mostly empty or good for independent usage) - playbook glue variables (`group_vars/matrix-servers`) - inventory host variables (`inventory/host_vars/matrix.<your-domain>`) All roles default to enabling their main component (e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`). Reasoning: if a role is included in a playbook (especially separately, in another playbook), it should "work" by default. Our playbook disables some of those if they are not generally useful (e.g. `matrix_corporal_enabled: false`).
2019-01-17 00:05:48 +08:00
# A shared secret (between Coturn and Synapse) used for authentication.
Switch Docker image to official one Switching from from avhost/docker-matrix (silviof/docker-matrix) to matrixdotorg/synapse. The avhost/docker-matrix (silviof/docker-matrix) image used to bundle in the coturn STUN/TURN server, so as part of the move, we're separating this to a separately-ran service (matrix-coturn.service, powered by instrumentisto/coturn-docker-image)
2018-05-26 02:58:53 +08:00
# You can put any string here, but generating a strong one is preferred (e.g. `pwgen -s 64 1`).
Reorganize Postgres access (breaking change) In short, this makes Synapse a 2nd class citizen, preparing for a future where it's just one-of-many homeserver software options. We also no longer have a default Postgres superuser password, which improves security. The changelog explains more as to why this was done and how to proceed from here.
2021-01-22 18:23:00 +08:00
matrix_coturn_turn_static_auth_secret: ''
Set up Synapse configuration using a template (not line/regexp replacements) Until now, we were starting from a fresh configuration, as generated by Synapse and manipulating it with regex and line replacements, until we made it work. This is more fragile and less predictable, so we're moving to a static configuration file generated from a Jinja template. The upside is that configuration will be stable and predictable. The downside of this new approach is that any manual configuration changes after the playbook is done, will be thrown away on future playbook invocations. There are 2 ways to work around the need for manual configuration changes though: - making them part of this playbook and its default template configuration files (which benefits everyone) - going your own way for a given host and overriding the template files that gets used (that is, the `matrix_synapse_template_synapse_homeserver` or `matrix_synapse_template_synapse_log` variables)
2018-06-27 02:05:59 +08:00
# A secret used to protect access keys issued by the server.
# You can put any string here, but generating a strong one is preferred (e.g. `pwgen -s 64 1`).
Reorganize Postgres access (breaking change) In short, this makes Synapse a 2nd class citizen, preparing for a future where it's just one-of-many homeserver software options. We also no longer have a default Postgres superuser password, which improves security. The changelog explains more as to why this was done and how to proceed from here.
2021-01-22 18:23:00 +08:00
matrix_synapse_macaroon_secret_key: ''
Fix typo
2021-01-22 20:13:56 +08:00
# A Postgres password to use for the superuser Postgres user (called `matrix` by default).
Reorganize Postgres access (breaking change) In short, this makes Synapse a 2nd class citizen, preparing for a future where it's just one-of-many homeserver software options. We also no longer have a default Postgres superuser password, which improves security. The changelog explains more as to why this was done and how to proceed from here.
2021-01-22 18:23:00 +08:00
#
# The playbook creates additional Postgres users and databases (one for each enabled service)
# using this superuser account.
matrix_postgres_connection_password: ''
Reference in New Issue Copy Permalink