self-hosted/matrix-docker-ansible-deploy
1
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-12-12 08:43:55 +02:00
Code Issues Releases Activity
087dbe4ddc
matrix-docker-ansible-deploy/roles/matrix-bridge-mautrix-facebook/defaults/main.yml

106 lines
5.5 KiB
YAML
Raw Normal View History

Move mautrix-facebook into a separate role
2019-05-15 02:34:31 +02:00
# mautrix-facebook is a Matrix <-> Facebook bridge
# See: https://github.com/tulir/mautrix-facebook
matrix_mautrix_facebook_enabled: true
Wire matrix_container_images_self_build to self_build variables via group_vars/matrix_servers This keeps the roles cleaner and more independent of matrix-base, which may be important for people building their own playbook out of the individual roles and not using the matrix-base role.
2020-03-15 10:10:41 +02:00
Rename some variables for consistency
2020-03-15 10:15:27 +02:00
matrix_mautrix_facebook_container_image_self_build: false
Move self-building git repository URLs to variables (stop hardcoding)
2020-11-28 21:34:14 +02:00
matrix_mautrix_facebook_container_image_self_build_repo: "https://github.com/tulir/mautrix-facebook.git"
Move mautrix-facebook into a separate role
2019-05-15 02:34:31 +02:00
Use mautrix-facebook Docker image from new official registry
2019-07-28 17:40:55 +02:00
# See: https://mau.dev/tulir/mautrix-facebook/container_registry
Improve self-building experience (avoid conflict with pullable images) Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/716 This patch makes us use more fully-qualified container image names (either prefixed with docker.io/ or with localhost/). The latter happens when self-building is enabled. We've recently had issues where if an image was removed manually and the service was restarted (making `docker run` fetch it from Docker Hub, etc.), we'd end up with a pulled image, even though we're aiming for a self-built one. Re-running the playbook would then not do a rebuild, because: - the image with that name already exists (even though it's something else) - we sometimes had conditional logic where we'd build only if the git repo changed By explicitly changing the name of the images (prefixing with localhost/), we avoid such confusion and the possibility that we'd automatically pul something which is not what we expect. Also, I've removed that condition where building would happen on git changes only. We now always build (unless an image with that name already exists). We just force-build when the git repo changes.
2020-11-14 22:47:14 +02:00
matrix_mautrix_facebook_docker_image: "{{ matrix_mautrix_facebook_docker_image_name_prefix }}tulir/mautrix-facebook:latest"
matrix_mautrix_facebook_docker_image_name_prefix: "{{ 'localhost/' if matrix_mautrix_facebook_container_image_self_build else 'dock.mau.dev/' }}"
Automatically force-pull :latest images We do use some `:latest` images by default for the following services: - matrix-dimension - Goofys (in the matrix-synapse role) - matrix-bridge-appservice-irc - matrix-bridge-appservice-discord - matrix-bridge-mautrix-facebook - matrix-bridge-mautrix-whatsapp It's terribly unfortunate that those software projects don't release anything other than `:latest`, but that's how it is for now. Updating that software requires that users manually do `docker pull` on the server. The playbook didn't force-repull images that it already had. With this patch, it starts doing so. Any image tagged `:latest` will be force re-pulled by the playbook every time it's executed. It should be noted that even though we ask the `docker_image` module to force-pull, it only reports "changed" when it actually pulls something new. This is nice, because it lets people know exactly when something gets updated, as opposed to giving the indication that it's always updating the images (even though it isn't).
2019-06-10 13:23:51 +02:00
matrix_mautrix_facebook_docker_image_force_pull: "{{ matrix_mautrix_facebook_docker_image.endswith(':latest') }}"
Move mautrix-facebook into a separate role
2019-05-15 02:34:31 +02:00
matrix_mautrix_facebook_base_path: "{{ matrix_base_data_path }}/mautrix-facebook"
Separate Facebook bridge configuration and data Using a separate directory allows easier backups (only need to back up the Ansible playbook configuration and the bridge's `./data` directory). The playbook takes care of migrating an existing database file from the base directory into the `./data` directory. In the future, we can also mount the configuration read-only, to ensure the bridge won't touch it. For now, mautrix-facebook is keen on rebuilding the `config.yaml` file on startup though, so this will have to wait.
2019-06-07 13:50:55 +02:00
matrix_mautrix_facebook_config_path: "{{ matrix_mautrix_facebook_base_path }}/config"
matrix_mautrix_facebook_data_path: "{{ matrix_mautrix_facebook_base_path }}/data"
refactor variable names
2020-03-08 01:28:14 +02:00
matrix_mautrix_facebook_docker_src_files_path: "{{ matrix_mautrix_facebook_base_path }}/docker-src"
Move mautrix-facebook into a separate role
2019-05-15 02:34:31 +02:00
Make Facebook bridge configuration playbook-managed Related to #193, but for the Facebook bridge. (other bridges can be changed to do the same later). This patch makes the bridge configuration entirely managed by the Ansible playbook. The bridge's `config.yaml` and `registration.yaml` configuration files are regenerated every time the playbook runs. This allows us to apply updates to those files and to avoid people having to manage the configuration files manually on the server. ------------------------------------------------------------- A deficiency of the current approach to dumping YAML configuration in `config.yaml` is that we strip all comments from it. Later on, when the bridge actually starts, it will load and redump (this time with comments), which will make the `config.yaml` file change. Subsequent playbook runs will report "changed" for the "Ensure mautrix-facebook config.yaml installed" task, which is a little strange. We might wish to improve this in the future, if possible. Still, it's better to have a (usually) somewhat meaningless "changed" task than to what we had -- never rebuilding the configuration.
2019-06-07 13:04:59 +02:00
matrix_mautrix_facebook_homeserver_address: 'http://matrix-synapse:8008'
Move mautrix-facebook into a separate role
2019-05-15 02:34:31 +02:00
matrix_mautrix_facebook_homeserver_domain: '{{ matrix_domain }}'
Use new default port config for mautrix-facebook
2019-07-28 17:42:30 +02:00
matrix_mautrix_facebook_appservice_address: 'http://matrix-mautrix-facebook:29319'
Move mautrix-facebook into a separate role
2019-05-15 02:34:31 +02:00
# A list of extra arguments to pass to the container
matrix_mautrix_facebook_container_extra_arguments: []
# List of systemd services that matrix-mautrix-facebook.service depends on.
matrix_mautrix_facebook_systemd_required_services_list: ['docker.service']
# List of systemd services that matrix-mautrix-facebook.service wants
matrix_mautrix_facebook_systemd_wanted_services_list: []
Make Facebook bridge configuration playbook-managed Related to #193, but for the Facebook bridge. (other bridges can be changed to do the same later). This patch makes the bridge configuration entirely managed by the Ansible playbook. The bridge's `config.yaml` and `registration.yaml` configuration files are regenerated every time the playbook runs. This allows us to apply updates to those files and to avoid people having to manage the configuration files manually on the server. ------------------------------------------------------------- A deficiency of the current approach to dumping YAML configuration in `config.yaml` is that we strip all comments from it. Later on, when the bridge actually starts, it will load and redump (this time with comments), which will make the `config.yaml` file change. Subsequent playbook runs will report "changed" for the "Ensure mautrix-facebook config.yaml installed" task, which is a little strange. We might wish to improve this in the future, if possible. Still, it's better to have a (usually) somewhat meaningless "changed" task than to what we had -- never rebuilding the configuration.
2019-06-07 13:04:59 +02:00
matrix_mautrix_facebook_appservice_token: ''
matrix_mautrix_facebook_homeserver_token: ''
Add (Postgres + SQLite) support to matrix-mautrix-facebook bridge
2020-12-14 11:50:42 +02:00
# Database-related configuration fields.
#
# To use SQLite, stick to these defaults.
#
# To use Postgres:
# - change the engine (`matrix_mautrix_facebook_database_engine: 'postgres'`)
# - adjust your database credentials via the `matrix_mautrix_facebook_postgres_*` variables
matrix_mautrix_facebook_database_engine: 'sqlite'
matrix_mautrix_facebook_sqlite_database_path_local: "{{ matrix_mautrix_facebook_data_path }}/mautrix-facebook.db"
matrix_mautrix_facebook_sqlite_database_path_in_container: "/data/mautrix-facebook.db"
Rename `matrix_*_postgres_*` back to `matrix_*_database_*` I was thinking that it makes sense to be more specific, and using `_postgres_` also separated these variables from the `_database_` variables that ended up in bridge configuration. However, @jdreichmann makes a good point (https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/740#discussion_r542281102) that we don't need to be so specific and can allow for other engines (like MySQL) to use these variables.
2020-12-14 13:02:47 +02:00
matrix_mautrix_facebook_database_username: 'matrix_mautrix_facebook'
matrix_mautrix_facebook_database_password: 'some-password'
Add (Postgres + SQLite) support to matrix-mautrix-facebook bridge
2020-12-14 11:50:42 +02:00
matrix_mautrix_facebook_postgres_hostname: 'matrix-postgres'
Rename `matrix_*_postgres_*` back to `matrix_*_database_*` I was thinking that it makes sense to be more specific, and using `_postgres_` also separated these variables from the `_database_` variables that ended up in bridge configuration. However, @jdreichmann makes a good point (https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/740#discussion_r542281102) that we don't need to be so specific and can allow for other engines (like MySQL) to use these variables.
2020-12-14 13:02:47 +02:00
matrix_mautrix_facebook_database_port: 5432
matrix_mautrix_facebook_database_db_name: 'matrix_mautrix_facebook'
Add (Postgres + SQLite) support to matrix-mautrix-facebook bridge
2020-12-14 11:50:42 +02:00
Rename `matrix_*_postgres_*` back to `matrix_*_database_*` I was thinking that it makes sense to be more specific, and using `_postgres_` also separated these variables from the `_database_` variables that ended up in bridge configuration. However, @jdreichmann makes a good point (https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/740#discussion_r542281102) that we don't need to be so specific and can allow for other engines (like MySQL) to use these variables.
2020-12-14 13:02:47 +02:00
matrix_mautrix_facebook_postgres_connection_string: 'postgresql://{{ matrix_mautrix_facebook_database_username }}:{{ matrix_mautrix_facebook_database_password }}@{{ matrix_mautrix_facebook_postgres_hostname }}:{{ matrix_mautrix_facebook_database_port }}/{{ matrix_mautrix_facebook_database_db_name }}'
Add (Postgres + SQLite) support to matrix-mautrix-facebook bridge
2020-12-14 11:50:42 +02:00
matrix_mautrix_facebook_appservice_database: "{{
{
Fix sqlite usage for mautrix-facebook/mautrix-telegram Regression since 2d99ade72f and 9bf8ce878e94, respectively. When SQLite is to be used, these bridges expect an `sqlite://` connection string, and not a plain file name (path), like Appservice Discord and mautrix-whatsapp do.
2020-12-14 12:30:10 +02:00
'sqlite': ('sqlite://' + matrix_mautrix_facebook_sqlite_database_path_in_container),
Add (Postgres + SQLite) support to matrix-mautrix-facebook bridge
2020-12-14 11:50:42 +02:00
'postgres': matrix_mautrix_facebook_postgres_connection_string,
}[matrix_mautrix_facebook_database_engine]
}}"
Move some things around
2020-12-14 12:04:47 +02:00
Add support for automatic Double Puppeting for all Mautrix bridges
2020-01-12 20:28:36 +02:00
# Can be set to enable automatic double-puppeting via Shared Secret Auth (https://github.com/devture/matrix-synapse-shared-secret-auth).
matrix_mautrix_facebook_login_shared_secret: ''
Update matrix-mautrix-facebook config a bit This also disables presence if it's disabled for Synapse.
2020-12-01 11:55:18 +02:00
matrix_mautrix_facebook_bridge_login_shared_secret_map: "{{ {matrix_mautrix_facebook_homeserver_domain: matrix_mautrix_facebook_login_shared_secret} if matrix_mautrix_facebook_login_shared_secret else {} }}"
matrix_mautrix_facebook_bridge_presence: true
Remove spurious 'mxisd' string from mautrix bridge templates comment
2020-01-08 23:36:48 +02:00
# Default configuration template which covers the generic use case.
Make Facebook bridge configuration playbook-managed Related to #193, but for the Facebook bridge. (other bridges can be changed to do the same later). This patch makes the bridge configuration entirely managed by the Ansible playbook. The bridge's `config.yaml` and `registration.yaml` configuration files are regenerated every time the playbook runs. This allows us to apply updates to those files and to avoid people having to manage the configuration files manually on the server. ------------------------------------------------------------- A deficiency of the current approach to dumping YAML configuration in `config.yaml` is that we strip all comments from it. Later on, when the bridge actually starts, it will load and redump (this time with comments), which will make the `config.yaml` file change. Subsequent playbook runs will report "changed" for the "Ensure mautrix-facebook config.yaml installed" task, which is a little strange. We might wish to improve this in the future, if possible. Still, it's better to have a (usually) somewhat meaningless "changed" task than to what we had -- never rebuilding the configuration.
2019-06-07 13:04:59 +02:00
# You can customize it by controlling the various variables inside it.
#
# For a more advanced customization, you can extend the default (see `matrix_mautrix_facebook_configuration_extension_yaml`)
# or completely replace this variable with your own template.
Move configuration templates outside of defaults/main.yml files
2020-06-03 08:33:28 +02:00
matrix_mautrix_facebook_configuration_yaml: "{{ lookup('template', 'templates/config.yaml.j2') }}"
Make Facebook bridge configuration playbook-managed Related to #193, but for the Facebook bridge. (other bridges can be changed to do the same later). This patch makes the bridge configuration entirely managed by the Ansible playbook. The bridge's `config.yaml` and `registration.yaml` configuration files are regenerated every time the playbook runs. This allows us to apply updates to those files and to avoid people having to manage the configuration files manually on the server. ------------------------------------------------------------- A deficiency of the current approach to dumping YAML configuration in `config.yaml` is that we strip all comments from it. Later on, when the bridge actually starts, it will load and redump (this time with comments), which will make the `config.yaml` file change. Subsequent playbook runs will report "changed" for the "Ensure mautrix-facebook config.yaml installed" task, which is a little strange. We might wish to improve this in the future, if possible. Still, it's better to have a (usually) somewhat meaningless "changed" task than to what we had -- never rebuilding the configuration.
2019-06-07 13:04:59 +02:00
matrix_mautrix_facebook_configuration_extension_yaml: |
# Your custom YAML configuration goes here.
# This configuration extends the default starting configuration (`matrix_mautrix_facebook_configuration_yaml`).
#
# You can override individual variables from the default configuration, or introduce new ones.
#
# If you need something more special, you can take full control by
# completely redefining `matrix_mautrix_facebook_configuration_yaml`.
matrix_mautrix_facebook_configuration_extension: "{{ matrix_mautrix_facebook_configuration_extension_yaml|from_yaml if matrix_mautrix_facebook_configuration_extension_yaml|from_yaml is mapping else {} }}"
# Holds the final configuration (a combination of the default and its extension).
# You most likely don't need to touch this variable. Instead, see `matrix_mautrix_facebook_configuration_yaml`.
matrix_mautrix_facebook_configuration: "{{ matrix_mautrix_facebook_configuration_yaml|from_yaml|combine(matrix_mautrix_facebook_configuration_extension, recursive=True) }}"
matrix_mautrix_facebook_registration_yaml: |
id: facebook
as_token: "{{ matrix_mautrix_facebook_appservice_token }}"
hs_token: "{{ matrix_mautrix_facebook_homeserver_token }}"
namespaces:
users:
- exclusive: true
Use stricter regex in bridges' registration.yaml I've been thinking of doing before, but haven't. Now that the Whatsapp bridge does it (since 4797469383c83f94f0ea67e0d), it makes sense to do it for all other bridges as well. (Except for the IRC bridge - that one manages most of registration.yaml by itself)
2019-06-24 06:50:47 +02:00
regex: '^@facebook_.+:{{ matrix_mautrix_facebook_homeserver_domain|regex_escape }}$'
Make Facebook bridge configuration playbook-managed Related to #193, but for the Facebook bridge. (other bridges can be changed to do the same later). This patch makes the bridge configuration entirely managed by the Ansible playbook. The bridge's `config.yaml` and `registration.yaml` configuration files are regenerated every time the playbook runs. This allows us to apply updates to those files and to avoid people having to manage the configuration files manually on the server. ------------------------------------------------------------- A deficiency of the current approach to dumping YAML configuration in `config.yaml` is that we strip all comments from it. Later on, when the bridge actually starts, it will load and redump (this time with comments), which will make the `config.yaml` file change. Subsequent playbook runs will report "changed" for the "Ensure mautrix-facebook config.yaml installed" task, which is a little strange. We might wish to improve this in the future, if possible. Still, it's better to have a (usually) somewhat meaningless "changed" task than to what we had -- never rebuilding the configuration.
2019-06-07 13:04:59 +02:00
url: {{ matrix_mautrix_facebook_appservice_address }}
sender_localpart: facebookbot
rate_limited: false
matrix_mautrix_facebook_registration: "{{ matrix_mautrix_facebook_registration_yaml|from_yaml }}"
Reference in New Issue Copy Permalink