| Age | Commit message (Collapse) | Author |
|---|
|
This ensures that the necessary packages and prosody-specific munin plugins are
configured by default.
|
|
I've moved these tasks into their own roles, which can now be used directly.
|
|
Now that I am splitting the repo into smaller roles, this any ansible
configuration should be shared. For instance, I want to install roles to
/usr/local/share/ansible/roles, but that isn't present in the default
roles_path.
Since ansible doesn't merge config files and only considers the one with
highest precedence, this means I should either define that override in every
role and playbook, or delete all custom ansible.cfg's and define it once, in my
~/.ansible.cfg. I decided to do the latter, to reduce duplication.
|
|
Servers on different providers had different apt sources by default. For
instance - some enabled trixie-backports while others did not. This lack of
consistency could lead to unexpected problems in the future - so ensure all
servers use consistent apt sources now.
Preserve the ability to use use mirrors by making uri a configurable parameter.
Likewise - make debian_version a configurable parameter. While I could set the
distribution to stable, I don't want to risk an upgrade moving onto a new
stable release without it being my explicit choice - a variable allows me to
set the version as trixie as well as upgrade servers incrementally (first in
staging, then transport, then prod).
|
|
Begin with already-included and postgres modules. I'll look to add
prosody-specific modules in time.
|
|
I have two keys, one for interactive access, and one for automated jobs. On
migration to the new host, I added the interactive key via the VPS provider's
form, but neglected to add the key for automated jobs. This led to the backup
jobs failing.
Therefore, define keys in the inventory that should be copied to the host, and
ensure they are installed to root. The subsequent step then copies these to the
admin account.
There is one problem with this approach: ssh remains open to root. Although
privilege escalation from admin is possible, I would like to take steps to
reduce root access where possible.
However, the playbook currently has to work both on first run when
bootstrapping the box, as well as subsequent runs. On the first run, the
playbook only has access to root and must create the admin account. However,
once the admin account has been created, the playbook should never again
interact with root.
Therefore, in the near future, I'd like to introduce a "bootstrap" action to
the playbook, that should only be run on the first deploy to the host, and
disable ssh access to root once finished. Subsequent runs should only interact
via admin.
|
|
I initially had a single notes.md file with just the changes that I needed.
But, I want to expand this to also include some runbooks and ad-hoc scripts,
that are too tied to my specific installation to be in the public repository.
|
|
Technically, the database is only being created and not fully set up.
|
|
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!
|
