Commit Graph

57 Commits

Author SHA1 Message Date
Slavi Pantaleev
b1b4ba501f Replace ExecStop with ExecStopPost
ExecStopPost should allow us to clean up (docker kill + docker rm)
even if the ExecStart (docker run ..) command failed, and not just after
a graceful service stop was initiated.

Source: https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStopPost=
2022-01-04 17:27:25 +02:00
Aaron Raimist
fac497faa5
Fix comments in other roles 2021-12-08 10:13:12 +00:00
Slavi Pantaleev
735c966ab6 Disable systemd services when stopping to uninstall them
Until now, we were leaving services "enabled"
(symlinks in /etc/systemd/system/multi-user.target.wants/).

We clean these up now. Broken symlinks may still exist in older
installations that enabled/disabled services. We're not taking care
to fix these up. It's just a cosmetic defect anyway.
2021-11-10 17:39:21 +02:00
Ahmad Haghighi
e335f3fc77 rename matrix_global_registry to matrix_container_global_registry_prefix related to #990
Signed-off-by: Ahmad Haghighi <haghighi@fedoraproject.org>
2021-04-12 17:23:55 +04:30
Ahmad Haghighi
f52a8b6484 use custom docker registry 2021-04-12 17:23:55 +04:30
rakshazi
2f887f292c
added "matrix_%SERVICE%_version" variable to all roles, use it in "matrix_%SERVICE%_docker_image" var (preserving backward-compatibility) 2021-02-20 19:08:28 +02:00
Slavi Pantaleev
512f42aa76 Do not report docker kill/rm attempts as errors
These are just defensive cleanup tasks that we run.
In the good case, there's nothing to kill or remove, so they trigger an
error like this:

> Error response from daemon: Cannot kill container: something: No such container: something

and:

> Error: No such container: something

People often ask us if this is a problem, so instead of always having to
answer with "no, this is to be expected", we'd rather eliminate it now
and make logs cleaner.

In the event that:
- a container is really stuck and needs cleanup using kill/rm
- and cleanup fails, and we fail to report it because of error
suppression (`2>/dev/null`)

.. we'd still get an error when launching ("container name already in use .."),
so it shouldn't be too hard to investigate.
2021-01-27 10:22:46 +02:00
Slavi Pantaleev
26542308b3 Use |to_json in more places in matrix-appservice-discord config
I don't think this was causing an issue, but it might
if the bot token has a more special value in the future.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/828
2021-01-26 10:00:07 +02:00
Slavi Pantaleev
1692a28fe4 Work around annoying Docker warning about undefined $HOME
> WARNING: Error loading config file: .dockercfg: $HOME is not defined

.. which appeared in Docker 20.10.
2021-01-15 00:23:01 +02:00
Slavi Pantaleev
05ca9357a8 Add .service suffix to systemd units list
We'll be adding `.timer` units later on, so it's good to be
more explicit.
2021-01-14 23:02:10 +02:00
Stuart Mumford
019a4d7dcd Use role relative paths for things 2020-12-23 11:34:48 +00:00
Slavi Pantaleev
15f4cc924d Rename variables (_database_db_name -> _database_name) 2020-12-22 17:10:02 +02:00
Slavi Pantaleev
0f4649a45c Merge branch 'master' into postgres-per-default 2020-12-16 03:35:39 +02:00
Slavi Pantaleev
a4b8baee49 Fix inability to send (Matrix -> Discord) messages via appservice-discord
Revert "Correct inabillity for appservice-discord to connect"
This reverts commit 673e19f830.

While certain things do work even with such a local URL, sending
messages leads to an error like this:

> [DiscordBot] verbose: DiscordAPIError: Invalid Form Body
> avatar_url: Not a well formed URL.

Fixes https://github.com/Half-Shot/matrix-appservice-discord/issues/649

The sample configuration file for appservice-discord
c29cfc72f5/config/config.sample.yaml (L8)
explicitly says that we need a public URL.
2020-12-16 03:35:13 +02:00
Slavi Pantaleev
cba973d6b5 Enable automatic (SQLite -> Postgres) migration for matrix-appservice-discord 2020-12-14 16:25:22 +02:00
Slavi Pantaleev
b9a04a7f95 Rename some remaining matrix_*_postgres_* vars back to matrix_*_database_*
Looks like there are some that I missed in 087dbe4ddc
2020-12-14 14:42:18 +02:00
Slavi Pantaleev
087dbe4ddc 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
Slavi Pantaleev
5dba0c038b Make --tags=import-generic-sqlite-db commands not pass a sensitive connection string around
Instead of passing the connection string, we can now pass a name of a
variable, which contains a connection string.

Both are supported for having extra flexibility.
2020-12-14 11:47:00 +02:00
Slavi Pantaleev
d91aa5a060 Do not introduce sub-variables exposing implementation details 2020-12-14 10:52:07 +02:00
Slavi Pantaleev
4617984b9f Add (SQLite -> Postgres) migration instructions 2020-12-14 02:24:32 +02:00
Slavi Pantaleev
b87b754372 Fail if appservice-discord wants Postgres, but has leftover SQLite data 2020-12-14 01:36:15 +02:00
Slavi Pantaleev
a374d309c8 Make appservice-discord support both SQLite and Postgres
People can toggle between them now. The playbook also defaults
to using SQLite if an external Postgres server is used.

Ideally, we'd be able to create databases/users in external Postgres
servers as well, but our initialization logic (and `docker run` command,
etc.) hardcode too many things right now.
2020-12-14 00:52:25 +02:00
transcaffeine
d9f4914e0d
WIP: postgres: create databases for all services
If a service is enabled, a database for it is created in postgres with a uniqque password. The service can then use this database for data storage instead of relying on sqlite.
2020-12-10 18:26:22 +01:00
Slavi Pantaleev
d08b27784f Fix systemd services autostart problem with Docker 20.10
The Docker 19.04 -> 20.10 upgrade contains the following change
in `/usr/lib/systemd/system/docker.service`:

```
-BindsTo=containerd.service
-After=network-online.target firewalld.service containerd.service
+After=network-online.target firewalld.service containerd.service multi-user.target
-Requires=docker.socket
+Requires=docker.socket containerd.service
Wants=network-online.target
```

The `multi-user.target` requirement in `After` seems to be in conflict
with our `WantedBy=multi-user.target` and `After=docker.service` /
`Requires=docker.service` definitions, causing the following error on
startup for all of our systemd services:

> Job matrix-synapse.service/start deleted to break ordering cycle starting with multi-user.target/start

A workaround which appears to work is to add `DefaultDependencies=no`
to all of our services.
2020-12-10 11:43:20 +02:00
John Goerzen
673e19f830
Correct inabillity for appservice-discord to connect
After recently updating my matrix-docker-ansible-deploy installation, matrix-appservice-discord would refuse to start, logging ECONNREFUSED to https://matrix.[mydomain]:443, which was resolving to 172.18.0.2 due to the `--hostname` in mailer grabbing that hostname.

Curious why the IRC bridge didn't have this issue, I looked into it, and it was connecting to `http://matrix-synapse:8008`.  Correcting this one to that URL resolved the issue.
2020-12-09 21:20:06 -06:00
Slavi Pantaleev
b3d91ed488 Fix passing of matrix_appservice_discord_auth_usePrivilegedIntents 2020-12-04 01:06:42 +02:00
Slavi Pantaleev
05cecb5261 Merge branch 'discord-v1.0'
This may be a bit premature, because the bridge didn't work for me
the last time I tried it (RC3).

Some bugs have been fixed to make our config compatible with v1.0.0
though, so it may work for some people (especially those starting
fresh).

I'm not for shipping potentially broken things, but given that we were
using `docker.io/halfshot/matrix-appservice-discord:latest` and that
points to v1.0.0 already (with no other tag we can use), our setup was
already broken in any case.

Now, at least it has some chance of running.
2020-12-03 15:17:30 +02:00
Slavi Pantaleev
edd40811a5 Update matrix-appservice-discord to v1.0.0 final 2020-12-03 15:16:26 +02:00
Slavi Pantaleev
75f9fde7a4 Remove some more -v usage
Continuation of 1fca917ad1.

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/722
2020-11-25 10:49:59 +02:00
Slavi Pantaleev
ccabc82d4c Use more fully-qualified container images
This is both for consistency with 93cc71cb69976c
and for making things more obvious.
2020-11-14 23:01:11 +02:00
Slavi Pantaleev
6dbb90258e Mention and recommend enabling usePrivilegedIntents 2020-11-13 08:23:40 +02:00
Slavi Pantaleev
fe7bed5df3 Upgrade appservice-discord 2020-11-12 08:21:02 +02:00
Scott Crossen
fa5d85426b Renamed systemd descriptions for all bridges 2020-10-13 16:40:30 -07:00
Slavi Pantaleev
5da31ba579 Move configuration templates outside of defaults/main.yml files 2020-06-03 09:33:28 +03:00
Chris van Dijk
6e3b877dc2 Remove hardcoded command paths in playbook shell usage 2020-05-27 23:14:56 +02:00
Chris van Dijk
6334f6c1ea Remove hardcoded command paths in systemd unit files
Depending on the distro, common commands like sleep and chown may either
be located in /bin or /usr/bin.

Systemd added path lookup to ExecStart in v239, allowing only the
command name to be put in unit files and not the full path as
historically required. At least Ubuntu 18.04 LTS is however still on
v237 so we should maintain portability for a while longer.
2020-05-27 23:14:54 +02:00
Chris van Dijk
7585bcc4ac Allow the matrix user username and groupname to be configured separately
No migration steps should be required.
2020-05-01 19:59:32 +02:00
mooomooo
eebc6e13f8 Made directory variables for /etc/systemd/system , /etc/cron.d , /usr/local/bin 2020-03-24 11:27:58 -07:00
Daniel Løvbrøtte Olsen
3f7af3ef3f
Expose self service bridging in matrix_appservice_discord
This allows for users to bridge already existing matrix rooms to discord
2019-12-11 14:47:44 +01:00
Michael Haak
5b213e6ad0 Replace constructs appending elements with variables to matrix_synapse_container_extra_arguments. Fixes issue https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/304 2019-11-09 23:16:12 +01:00
Slavi Pantaleev
59d807fca7 Ensure auth.clientID is passed as string in Discord configuration
Discord client IDs are numeric (e.g. 12345).
Passing them as integers however, causes the Discord bridge's YAML parser
to parse them as integers and its config schema validation will fail.

Fixes #240 (Github Issue)
2019-08-11 16:16:05 +03:00
Slavi Pantaleev
c40d28a0dc Relocate user-store.db/room-store.db when migrating Discord bridge files
Refer to 524436ebef and #230 (Github Issue).
2019-08-01 14:40:12 +03:00
Slavi Pantaleev
524436ebef Add missing required parameters for Discord bridge
Fixes #230 (Github Issue).

Related to https://github.com/Half-Shot/matrix-appservice-discord/issues/510
2019-08-01 14:36:02 +03:00
Slavi Pantaleev
87e3650327 Ensure Discord client id is passed as a string
Looks like these client ids are actually integers,
but unless we pass them as a string, the bridge would complain with
an error like:

    {"field":"data.auth.clientID","message":"is the wrong type","value":123456789012345678,"type":"string","schemaPath":["properties","auth","properties","clientID"]}

Explicitly-casting to a string should fix the problem.

The Discord bridge should probably be improved to handle both ints and
strings though.
2019-07-12 10:15:43 +03:00
Slavi Pantaleev
8529efcd1c Make Discord bridge configuration playbook-managed
Well, `config.yaml` has been playbook-managed for a long time.
It's now extended to match the default sample config of the Discord
bridge.

With this patch, we also make `registration.yaml` playbook-managed,
which leads us to consistency with all other bridges.

Along with that, we introduce `./config` and `./data` separation,
like we do for the other bridges.
2019-06-26 10:35:00 +03:00
Slavi Pantaleev
00383a73ac Make running --tags=setup-synapse only not fail to register bridges
Until now, if `--tags=setup-synapse` was used, bridge tasks would not
run and bridges would fail to register with the `matrix-synapse` role.
This means that Synapse's configuration would be generated with an empty
list of appservices (`app_service_config_files: []`).

.. and then bridges would fail, because Synapse would not be aware of
there being any bridges.

From now on, bridges always run their init tasks and always register
with Synapse.

For the Telegram bridge, the same applies to registering with
matrix-nginx-proxy. Previously, running `--tags=setup-nginx-proxy` would
get rid of the Telegram endpoint configuration for the same reason.
Not anymore.
2019-06-14 10:19:52 +03:00
Slavi Pantaleev
7d3adc4512 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 14:30:28 +03:00
Slavi Pantaleev
d6d6c152a3 Delay bridge startup to ensure Synapse is up
Bridges start matrix-synapse.service as a dependency, but
Synapse is sometimes slow to start, while bridges are quick to
hit it and die (if unavailable).

They'll auto-restart later, but .. this still breaks `--tags=start`,
which doesn't wait long enough for such a restart to happen.

This attempts to slow down bridge startup enough to ensure Synapse
is up and no failures happen at all.
2019-06-07 12:15:37 +03:00
Slavi Pantaleev
328d981b05 Fix undefined variables in mxisd and Dimension configuration 2019-06-07 11:46:35 +03:00
Slavi Pantaleev
70487061f4 Prefer --mount instead of -v for mounting volumes
This doesn't replace all usage of `-v`, but it's a start.

People sometimes troubleshoot by deleting files (especially bridge
config files). Restarting Synapse with a missing registration.yaml file
for a given bridge, causes the `-v
/something/registration.yaml:/something/registration.yaml:ro` option
to force-create `/something/registration.yaml` as a directory.

When a path that's provided to the `-v` option is missing, Docker
auto-creates that path as a directory.
This causes more breakage and confusion later on.

We'd rather fail, instead of magically creating directories.
Using `--mount`, instead of `-v` is the solution to this.

From Docker's documentation:

> When you use --mount with type=bind, the host-path must refer to an existing path on the host.
> The path will not be created for you and the service will fail with an error if the path does not exist.
2019-05-29 09:59:50 +03:00