| Age | Commit message (Collapse) | Author |
|---|
|
I use the playbook to deploy to three different domains. Before this commit,
some instances were deployed to the root domain (e.g. example.org) and others
were deployed to a subdomain (e.g. chat.example.org), so that other
services/hosts could easily live at the root.
I would now like to enforce that all instances live under the chat. subdomain.
There is no real benefit to having this difference in deployments, having more
consistency will make reasoning about the different instances easier and allow
me to delete some extra variables, and it will also allow me to deploy separate
services to the root domains in the future if needed.
|
|
When I first made this playbook, I was a little sceptical of -or-later
licenses. However, I've come around to the idea over time.
|
|
I used to have separate admin@ and abuse@ accounts for each virtual host. I
don't really need that separation, though, as I am the only admin, and no-one
has ever contacted them anyway. So, set all admin accounts to the account I
actually use and check every day anyway.
|
|
This is needed as the transports are by default treated as guests by prosody,
and therefore unable to upload files without explicit permission.
|
|
The template worked fine for singleton lists, but it fails when adding another
entry since there is no separator between the elements! Thankfully Lua has some
nice syntax allowing you to use a semicolon as a separator, which doesn't by
itself imply more than one element.
|
|
This commit allows transport servers to define the relevant components on the
XMPP server. Transports are configured by adding the following config to the
inventory's variables:
transports:
- subdomain: a-example-legacy-network
secret: a-long-randomly-generated-secret
- subdomain: another-example-legacy-network
secret: another-long-randomly-generated-secret
These are iterated over and a privileged component is created for each.
|
|
If a section is not enabled on a particular server, that section's header
comment should not be visible.
|
|
This configuration allows me to remove the proxy DNS records, and keep the
configuration internal to prosody.
|
|
We do not need s2s modules or config for a single-user transport oriented
server.
Likewise, we do not need admin or abuse contacts if s2s is disabled. No
messages can escape, and it would be impossible to contact them regardless!
|
|
Use consistent 4-space indentation.
Do not allow new scopes to be opened and closed on the same line. This allows
me to more easily add jinja if statements without having to make formatting
changes at the same time.
|
|
There will be no s2s connections on the transport server, so anti-spam modules
won't provide much benefit.
|
|
Invites are not needed on a single-user transport-only server. Therefore, place
this functionality behind a flag.
|
|
I am planning on deploying a new single-user server, without s2s connections or
other features, specifically for transports.
This necessiates splitting off some functionality behind a flag, so that it is
only enabled for non-transport ("standard") servers.
|
|
While looking through the list of available prosody-modules, these
seemed useful.
|
|
While looking through the list of available prosody-modules, these two
seemed useful.
|
|
Thankfully the servers I manage have not seen any spam, nevertheless,
I'd rather set up some kind of mitigation now, before it becomes a
problem.
|
|
This is not available in prosody-modules
0.0~hg20250402.f315edc39f3d+dfsg-2.
|
|
There's no need to jump back to 2 GiB yet, but I was finding 10 MiB too
restrictive.
|
|
This was originally intended for motoristic, but is no longer needed by
any domain.
|
|
This was only ever enabled for testing purposes, and is no longer
needed.
|
|
I made a mistake in the original configuration - I tried to give each
virtual host a separate turnserver on its own subdomain. However, since
koyo.haus and fennell.dev (and likewise in nonprod) share a virtual
machine, they can only have one turnserver between them (in the
turnserver.conf, there can only be a single realm).
Therefore, always point to koyo.haus for the turnserver in each
environment.
|
|
|
|
This was quite generous, and if everyone used it at the same time, the
host would fall over!
|
|
|
|
This is useful for two reasons:
* To test clients that render roster groups provided by the server
* To evaluate whether it is worth enabling this flag in production
|
|
This is to test how clients handle downloading large files.
|
|
This is in order to debug an issue I was seeing with group chats previously. I
don't believe it actually had an impact, but I can't remember for sure now. I
should debug this at some point and remove if necessary.
|
|
This is so that I can test sending a relatively large APK in order to debug an
issue in Dino.
|
|
I am rolling out a Matrix bot that will auto-reply to contacts in bridged
conversations, encouraging people to reach out to me on XMPP.
The bot will send them an invite link, retrieved from this API.
|
|
This will primiarly be used for motoristic.
|
|
|
|
We remove some extra MUC configuration here that should not be needed, as these
settings should be handled by the defaults anyway.
|
|
I misunderstood how MAM works, and thought that storing messages long-term
would allow new clients to retrieve long-term history. This commit moves the
server's configuration back to the default of one week.
|
|
|
|
This commit adds support for XEPS 0065 and 0365 - i.e. sending files from one
account to another.
|
|
This commit uses the new per-host virtual_host variable to create the necessary
prosody host-specific cfg files.
|
