titanz
/
matrix-docker-ansible-deploy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'b354155d7c'
${ noResults }
matrix-docker-ansible-deploy/roles/matrix-bridge-mautrix-facebook/defaults/main.yml

72 lines
3.8 KiB
Raw Normal View History Unescape

Move mautrix-facebook into a separate role
6 years ago
# 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.
5 years ago
Rename some variables for consistency
5 years ago
matrix_mautrix_facebook_container_image_self_build: false
Move mautrix-facebook into a separate role
6 years ago
Use mautrix-facebook Docker image from new official registry
5 years ago
# 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.
4 years ago
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).
6 years ago
matrix_mautrix_facebook_docker_image_force_pull: "{{ matrix_mautrix_facebook_docker_image.endswith(':latest') }}"
Move mautrix-facebook into a separate role
6 years ago
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.
6 years ago
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
5 years ago
matrix_mautrix_facebook_docker_src_files_path: "{{ matrix_mautrix_facebook_base_path }}/docker-src"
Move mautrix-facebook into a separate role
6 years ago
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.
6 years ago
matrix_mautrix_facebook_homeserver_address: 'http://matrix-synapse:8008'
Move mautrix-facebook into a separate role
6 years ago
matrix_mautrix_facebook_homeserver_domain: '{{ matrix_domain }}'
Use new default port config for mautrix-facebook
5 years ago
matrix_mautrix_facebook_appservice_address: 'http://matrix-mautrix-facebook:29319'
Move mautrix-facebook into a separate role
6 years ago
# 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.
6 years ago
matrix_mautrix_facebook_appservice_token: ''
matrix_mautrix_facebook_homeserver_token: ''
Add support for automatic Double Puppeting for all Mautrix bridges
5 years ago
# 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: ''
Remove spurious 'mxisd' string from mautrix bridge templates comment
5 years ago
# 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.
6 years ago
# 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
5 years ago
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.
6 years ago
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)
5 years ago
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.
6 years ago
url: {{ matrix_mautrix_facebook_appservice_address }}
sender_localpart: facebookbot
rate_limited: false
matrix_mautrix_facebook_registration: "{{ matrix_mautrix_facebook_registration_yaml|from_yaml }}"