feat(synapse): add quadlet-managed synapse matrix server role #94
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "add-synapse"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a quadlet-managed setup for synapse, the main matrix server implementation.
Note: The config file is currently not managed via ansible and needs to be setup manually.
This is atm not easy to set up out of the box and needs some manual work.
@ -0,0 +13,4 @@
Image = {{ synapse_containerimage }}:{{ synapse_image_tag }}
ContainerName = synapse
# AutoUpdate = registry
@histalek FYI: I disabled these on most of my roles, especially the larger projects like synapse and mastodon because they should only restart when explicitly told to (rather critical parts of the infra) and also are partly not capable of correctly restarting atm. See mastodon and would cause it to fail.
Is this fine? What are your thoughts on the AutoUpdate config?
Let's roughly decide on a general baseline consensus on this setting.
In general i think this is fine for smaller less relevant containers. For more critical services, i think this should in theory work fine too, but could still lead to some issues where systems do not correctly restart or break due to some weird interaction with the restart / race conditions. I'd like to have that off there by default.
Jup that's fine.
i'd consider such cases to be a bug - which should be fixed. But disabling auto-updates for known bad services is totally fine until they can restart properly.
same goes for this
3df45cef7f
tod9af987c83
@ -0,0 +18,4 @@
# Server name removing
-Server
}
we have this exact caddy block, dozens of times in our roles
we probably should create some default Caddy snippets in the caddy role to reduce clutter and/or highlight places where our default isn't used.
@ -0,0 +27,4 @@
{% endif %}
Network = caddy.network
DNS = 1.1.1.1
This is a workaround right? Do you remember what it was for?
good catch, will document it in a comment.
This is because somehow synapse with SSO on the same host sometimes has issues resolving the DNS for that host.
God knows why, but explicitly using an external DNS here seemed to have fixed the issue.