matrix-docker-ansible-deploy/examples/vars.yml

# The bare domain name which represents your Matrix identity.
# Matrix user ids for your server will be of the form (`@user:<matrix-domain>`).
#
# Note: this playbook does not touch the server referenced here.
# Installation happens on another server ("matrix.<matrix-domain>").
#
# If you've deployed using the wrong domain, you'll have to run the Uninstalling step,
# because you can't change the Domain after deployment.
#
# Example value: example.com
matrix_domain: YOUR_BARE_DOMAIN_NAME_HERE

# The Matrix homeserver software to install.
# See `roles/matrix-base/defaults/main.yml` for valid options.
matrix_homeserver_implementation: synapse

# A secret used as a base, for generating various other secrets.
# You can put any string here, but generating a strong one is preferred (e.g. `pwgen -s 64 1`).
matrix_homeserver_generic_secret_key: ''

# This is something which is provided to Let's Encrypt when retrieving SSL certificates for domains.
#
# In case SSL renewal fails at some point, you'll also get an email notification there.
#
# If you decide to use another method for managing SSL certificates (different than the default Let's Encrypt),
# you won't be required to define this variable (see `docs/configuring-playbook-ssl-certificates.md`).
#
# Example value: someone@example.com
matrix_ssl_lets_encrypt_support_email: ''

# A shared secret (between Coturn and Synapse) used for authentication.
# You can put any string here, but generating a strong one is preferred (e.g. `pwgen -s 64 1`).
matrix_coturn_turn_static_auth_secret: ''

# A Postgres password to use for the superuser Postgres user (called `matrix` by default).
#
# The playbook creates additional Postgres users and databases (one for each enabled service)
# using this superuser account.
matrix_postgres_connection_password: ''
Rename some variables 6 years ago			`# 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 7 years ago			`#`
Rename some variables 6 years ago			`# Note: this playbook does not touch the server referenced here.`
			`# Installation happens on another server ("matrix.<matrix-domain>").`
Initial commit 7 years ago			`#`
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. 4 years ago			`# If you've deployed using the wrong domain, you'll have to run the Uninstalling step,`
Fix typo and wording 4 years ago			`# because you can't change the Domain after deployment.`
Comment in host-cars 4 years ago			`#`
Rename some variables 6 years ago			`# Example value: example.com`
			`matrix_domain: YOUR_BARE_DOMAIN_NAME_HERE`
Initial commit 7 years ago
Make matrix_homeserver_implementation influence matrix_IMPLEMENTATION_enabled, not the other way around Doing this seems more reasonable and simpler. 3 years ago			`# The Matrix homeserver software to install.`
			# See `roles/matrix-base/defaults/main.yml` for valid options.
			`matrix_homeserver_implementation: synapse`

Derive secrets from matrix_homeserver_generic_secret_key, not matrix_synapse_macaroon_secret_key We're trying to move away from implementation-specific variables, hoping for a clean (implementation-neutral) examples/vars.yml file. 3 years ago			`# A secret used as a base, for generating various other secrets.`
			# You can put any string here, but generating a strong one is preferred (e.g. `pwgen -s 64 1`).
			`matrix_homeserver_generic_secret_key: ''`

Rename some variables 6 years ago			`# This is something which is provided to Let's Encrypt when retrieving SSL certificates for domains.`
Initial commit 7 years ago			`#`
Rename some variables 6 years ago			`# In case SSL renewal fails at some point, you'll also get an email notification there.`
Initial commit 7 years ago			`#`
Fix typo 3 years ago			`# If you decide to use another method for managing SSL certificates (different than the default Let's Encrypt),`
Rename some variables 6 years ago			# you won't be required to define this variable (see `docs/configuring-playbook-ssl-certificates.md`).
Initial commit 7 years ago			`#`
Rename some variables 6 years ago			`# 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. 4 years ago			`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) 7 years ago
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`). 6 years ago			`# 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) 7 years ago			# 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. 4 years ago			`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) 7 years ago
Fix typo 4 years ago			# 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. 4 years ago			`#`
			`# The playbook creates additional Postgres users and databases (one for each enabled service)`
			`# using this superuser account.`
			`matrix_postgres_connection_password: ''`