* Replace "Element" with "Element Web"
- If Element indicates the web application, then it is changed to Element Web.
- If it indicates clients branded with Element such as Element desktop, web, mobile clients, then it is changed to Element clients.
- If it is combined with location sharing functionality, it is not changed.
with other some changes, including:
- Change "app.element.io" anchor link to "https://github.com/element-hq/element-web" on README.md, following other documentation files
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace "SchildiChat" with "SchildiChat Web"
- If SchildiChat indicates the web application, then it is changed to SchildiChat Web.
- If it indicates clients branded with SchildiChat such as SchildiChat desktop, web, mobile clients, then it is changed to SchildiChat clients.
- If it is combined with location sharing functionality, it is not changed.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename configuring-playbook-client-schildichat.md to configuring-playbook-client-schildichat-web.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename configuring-playbook-client-element.md to configuring-playbook-client-element-web.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
---------
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The old variables still work. The global lets us avoid
auto-detection logic like we're currently doing for
`matrix_nginx_proxy_proxy_matrix_federation_api_enabled`.
In the future, we'd just be able to reference
`matrix_homeserver_federation_enabled` and know the up-to-date value
regardless of homeserver.
Downsides: decreasing security slightly due to less networking isolation
Benefits:
- decreased complexity
- having a generically-named `matrix-addons` network we may use for other things now (client apps, etc.)
- not exhausting the container networks pool with 2 (or more) networks and using just 1
This is still very far from usable.
Various bridges and bots are still talking to
`matrix-nginx-proxy` instead of the new `matrix-homeserver-proxy` role.
These services need to be reworked. While reworking them,
various cleanups are being done as well as adding Traefik-labels to
those that need them.
* Inital work, copeid from mautrix-amp PR
* Some fixes leftover code copeid over from whatsapp
* Got it to run and register
* Fixed service issue with docker image
* I now realize I need 2 roles wsproxy and imessage
* Got someting working, still rough
* Closer to working but still not working
* reverting ports
* Update main.yml
* Add matrix-nginx-proxy config for mautrix-wsproxy
* Changed
* Add back file
* fix for error hopefully
* Changed the the way nginx was recieved
* basically did not add anything ugh
* Added some arguments
* just trying stuff now
* Ugh i messed up port number
* Changed docs
* Change dns config
* changed generic secret key
* Testing new nginx proxy
* test
* Fix linting errors
* Add mautrix syncproxy to wsproxy for Android SMS
* WIP
* Move wsproxy to custom
* Squashed commit of the following:
commit 943189a9aa
Merge: 4a229d68f5a09f30
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Nov 13 08:54:32 2022 +0200
Merge pull request #2259 from throny/patch-3
warn users about upgrading to pg15 when using borg
commit 4a229d6870
Merge: 9b326e08c68def08
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Nov 13 08:53:13 2022 +0200
Merge pull request #2260 from etkecc/patch-117
Update ntfy 1.28.0 -> 1.29.0
commit f5a09f30b7
Author: throny <m.throne12@gmail.com>
Date: Sat Nov 12 23:48:57 2022 +0100
Update maintenance-postgres.md
commit b12cdbd99d
Author: throny <m.throne12@gmail.com>
Date: Sat Nov 12 23:40:46 2022 +0100
Update maintenance-postgres.md
commit c68def0809
Author: Aine <97398200+etkecc@users.noreply.github.com>
Date: Sat Nov 12 22:01:31 2022 +0000
Update ntfy 1.28.0 -> 1.29.0
commit adbc09f152
Author: throny <m.throne12@gmail.com>
Date: Sat Nov 12 11:20:43 2022 +0100
warn users about upgrading to pg15 when using borg
* Fix linting errors
* Cleanup after merge
* Correct outdated variable names
* Enable both Android and iMessage with wsproxy
* Restructure wsproxy service defs and nginx config
* Fix linter errors
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Fix comments for documentation, volumes and ports
* Correct mount syntax
* Complete network and traefik support for wsproxy
* Remove wsproxy data_path
* Fix wsproxy service definitions
* Actually include syncproxy service
* Remove wsproxy PathPrefix, it needs a subdomain
There's no setting in the iMessage bridge that allows a path.
Also don't bind port by default, wsproxy has no TLS.
Syncproxy should never expose a port, it's only internal.
---------
Co-authored-by: hanthor <jreilly112@gmail.com>
Co-authored-by: Miguel Alatzar <miguel@natrx.io>
Co-authored-by: Shreyas Ajjarapu <github.tzarina@aleeas.com>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This allows people to try out the new Element X clients, which need to
run against the sliding-sync proxy (https://github.com/matrix-org/sliding-sync).
Supersedes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2515
The code is based on the existing PR (#2515), but heavily reworked. Major changes:
- lots of internal refactoring and variable renaming
- fixed self-building to support non-amd64 architectures
- changed to talk to the homeserver locally, over the container network (not
publicly)
- no more matrix-nginx-proxy support due to complexity (see below)
- no more `matrix_server_fqn_sliding_sync_proxy` in favor of
`matrix_sliding_sync_hostname` and `matrix_sliding_sync_path_prefix`
- runs on `matrix.DOMAIN/sliding-sync` by default, so it can tried
easily without having to create new DNS records
The variable was necessary when multiple playbooks could have
potentially tried to manage a shared `devture-traefik.serivce` systemd service
and shared `/devture-traefik` directory.
Since adcc6d9723, we use our own `/matrix/traefik`
(`matrix-traefik.service`) installation and no conflicts can arise.
It's safe to always enable the role, just like we do with all the other roles.
The migration is automatic. Existing users should experience a bit of
downtime until the playbook runs to completion, but don't need to do
anything manually.
This change is provoked by https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2535
While my statements there ("Traefik is a shared component among
sibling/related playbooks and should retain its global
non-matrix-prefixed name and path") do make sense, there's another point
of view as well.
With the addition of docker-socket-proxy support in bf2b540807,
we potentially introduced another non-`matrix-`-prefixed systemd service
and global path (`/devture-container-socket-proxy`). It would have
started to become messy.
Traefik always being called `devture-traefik.service` and using the `/devture-traefik` path
has the following downsides:
- different playbooks may write to the same place, unintentionally,
before you disable the Traefik role in some of them.
If each playbook manages its own installation, no such conflicts
arise and you'll learn about the conflict when one of them starts its
Traefik service and fails because the ports are already in use
- the data is scattered - backing up `/matrix` is no longer enough when
some stuff lives in `/devture-traefik` or `/devture-container-socket-proxy` as well;
similarly, deleting `/matrix` is no longer enough to clean up
For this reason, the Traefik instance managed by this playbook
will now be called `matrix-traefik` and live under `/matrix/traefik`.
This also makes it obvious to users running multiple playbooks, which
Traefik instance (powered by which playbook) is the active one.
Previously, you'd look at `devture-traefik.service` and wonder which
role was managing it.
