| Age | Commit message (Collapse) | Author |
|---|
|
This enables delta backups, reducing bandwidth sent off the server.
|
|
There are some cases where I do not want to run DNS-related steps. For
instance, when setting up a new server, which should replace an existing one,
it is necessary to skip the DNS steps until the server has been fully migrated
and I am ready to switch the hot/cold sides.
Therefore, tag all DNS steps. This allows them to be skipped during ansible
playbook execution using --skip-tags dns.
|
|
This allows users who are registering using the invite webpage to register an
account directly online, in case their desired client is not listed.
I doubt this will ever be used, but without this module, the register manually
link is broken in the invite page, and on the off chance it is used, I want to
provide a good experience.
|
|
While ensuring that all hosts are deployed to the chat subdomain, I applied the
same logic to the invite pages too.
However, this broke invites as prosody's HTTP module has a check which ensures
that the page being served is on the same domain as the virtual host, meaning
that invite pages hosted under the chat subdomain would receive a 404.
So, serve invite pages from the domain itself (which is the default config in
prosody). To do this, we must direct such requests from nginx too.
|
|
A year is a little excessive.
|
|
I have now moved all servers' nameservers to Mythic Beasts. Replace the old
deSEC requests to ones to Mythic Beasts.
|
|
I only want to store the actual hash in dane_hash and not a full python object
corresponding to the execution of the command.
|
|
My current deployment of non-transport servers looks like this:
xmpp-prod host:
chat.fennell.dev
chat.koyo.haus
prod turn server
xmpp-nonprod host:
chat.continuous.nonprod.fennell.dev
chat.continuous.nonprod.koyo.haus
nonprod turn server
So, for each environment, there are two XMPP servers and only a single turn
server.
Therefore, within each environment, all XMPP servers need to point to the same
turn server. I decided arbitrarily that that server would be defined for the
koyo.haus domain.
I used to have a variable defined for each host to manually point the turn
server to that domain. However, we can prevent some duplication of information
in the playbook if we just define the turn_domain (i.e. koyo.haus) in the
inventory, and then derive the full path for that environment from that.
|
|
I have two different kinds of servers - transport servers (which connect to
legacy networks and have s2s disabled) and non-transport servers (which are
XMPP-only and have s2s enabled).
I previously had an is_transport_server boolean defined for each host in the
inventory - however, this is duplicated information that can be derived from
the length of the transports value (which lists the legacy networks to
transport to).
Transport servers have a non-empty transports list, while non-transport servers
do not define the variable at all. So, handle this case in the playbook by
deriving an empty list if the value is not present.
|
|
I previously had separate inventories for each environment: prod, transport and
staging, with each inventory having a single xmpp_server group.
I want to start adopting group_vars so that I can share common variables
between hosts, so I've moved all hosts into a common hosts.yaml file with
groups for each environment.
This means there is no longer an xmpp_server group, and all hosts are in a
single inventory. Adjust the playbook to account for this.
|
|
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.
|
|
I am moving DNS provider from deSEC to Mythic Beasts. As part of this change, I
need to use Mythic Beast's DNS API [1] in the playbook.
I want to reduce the number of operations that are made by grouping several
records together. To do this, I can use the "Identifying records to replace"
method from their DNS tutorial. [2] This provides a way to specify which
records should be replaced by the new records that you PUT onto the endpoint.
To use this, you specify the records via a url-encoded series of select
queries. Then, you can combine them into a disjunction of conjunctions like so:
?select=type%3DA%26host%3Dchat&select=type%3DAAAA
This gets split into two separate queries which are then decoded into:
type=A&host=chat
type=AAAA
Then, these records are replaced by whichever records are specified in the PUT
request.
It's painful to write these by hand, so write a script to generate them
automatically. Then, they should be pasted into the playbook when the desired
records update. If this happens often, we should make the playbook call the
script to get the values directly.
As an additional benefit, the script definitively states which records are
"owned" by the playbook. This is because the records specified in the script
are the ones that will be replaced each time the playbook is run.
Finally, since we've now added python to the playbook for the first time, add
the black linter to keep the code style in check.
[1] https://www.mythic-beasts.com/support/api/dnsv2
[2] https://www.mythic-beasts.com/support/api/dnsv2/tutorial
|
|
I initially created these targets so that I could easily redeploy a full server
from the terminal, including creating the necessary VPSs using my libcloud
helper repository.
However, a couple of years in, I have never done a -fresh deploy. While I am
planning to migrate to a different hosting provider soon, it doesn't have a
libcloud backend, so it turns out that this -fresh idea was overengineered and
unecessary.
I already have a runbook for transferring VPSs, so I can gradually automate
that instead if it becomes necessary.
|
|
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.
|
|
As far as I know, this playbook is only used by me. I'm failing to update the
README, and I don't think it really serves any benefit.
|
|
All hosts I previously used had unattended-upgrades already installed, but a
standard debian install doesn't have it installed by default. So, make sure it
is installed.
|
|
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.
|
|
This change allows targeted deployments just to transport servers, or
deployments to all prod servers (including transport) at once.
|
|
Prosody falls back to a legacy DNS module and also logs warnings if lua-unbound
is not installed.
|
|
If a section is not enabled on a particular server, that section's header
comment should not be visible.
|
|
This provides a more performant alternative to BOSH for clients wishing to
access the server over HTTP.
|
|
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!
|
|
According to mod_tls documentation, c2s_require_encryption and
s2s_require_encryption already default to true. Therefore, they can be removed.
Likewise, the default for authentication is internal_hashed, and the certs are
already in the "certs" subdirectory relative to the prosody config file.
|
|
I have s2s_secure_auth enabled, which disables dialback. Therefore, this module
is not needed.
|
|
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.
|
|
I added python3-pexpect to the dependency list in
de867dadbcc3c69d97acf96bf3e86d11295eea39, to use the pexpect ansible module for
a reason that is lost to the sands of time. This module is no longer used, so
the dependency can be removed.
|
|
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.
|
|
Whoops! mod_component is not supposed to be loaded directly, instead it
gets indirectly loaded as a result of the relevant component
definitions.
|
|
I took the opportunity to look through the module list and add some
extra ones that were missing before.
|
|
These are newly available in Trixie. I believe Monal will start loudly
warning if they are not used in the near future.
|
|
According to prosodyctl check, this module is no longer used or needed.
|
|
This is not available in prosody-modules
0.0~hg20250402.f315edc39f3d+dfsg-2.
|
|
I found these variables a bit confusing after having to interact with
them again. It is useful to have some context now I have forgotten all
about the DS record setup!
|
|
It is useful to jump to diferent variables using the {} keys in vim, and
the rest of the playbook has similar whitespace.
|
|
domain_with_ds is checked against the empty string when checking whether
we should define ds_subname.
When no parent_domain was found, we setting domain_with_ds to None,
which in Ansible 10 was (correctly) failing the domain_with_ds != ""
check. However, in Ansible 12, it now fails that check, meaning that
Ansible tried to evaluate ds_subname even when domain_with_ds was None,
resulting in a type conversion failure.
Therefore, make sure that domain_with_ds is always a string, even if
parent_domain is undefined, and use the empty string to represent this,
as expected in the playbook itself.
|
|
Some services, such as munin, read the hostname from the system, and
don't allow "virtual host" configuration like prosody. For such
services, we want to make sure the hostname is set correctly.
|
|
I want ansible to take full control of managing /etc/hosts, hostname
etc. I think it is most convenient to disable cloud-init entirely, to
prevent contention between ansible and cloud-init.
|
|
db and database have been deprecated, and replaced with login_db.
|
|
I don't need to specify the exact interpreter through ansible, as I can
do this from the host itself.
|
|
This is now enforced by ansible-lint.
|
|
There's no need to jump back to 2 GiB yet, but I was finding 10 MiB too
restrictive.
|
