| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
I used to have a dedicated server for cert renewals; now I just run it
from my laptop, with an increased cron frequency. This is simpler,
especially when there is a powercut, and I'll certainly use my laptop
every 30 days.
|
|
It's too time-consuming, especially when making multiple commits in one
go, and having tested those changes by manually running make staging
already.
|
|
These steps where not idempotent, because there was no way to check if
the password was correct. So, they would again each time.
The playbook gets run infrequently enough, and it is simple enough, to
add users manually.
|
|
|
|
This makes it easier to debug why a step is unexpectedly not idempotent.
|
|
Backups are now handled outside of the playbook.
|
|
This was quite generous, and if everyone used it at the same time, the
host would fall over!
|
|
|
|
|
|
The main way the config varies from Debian's default, is that we make sure to
reboot after each upgrade.
|
|
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 lets us log each individual stanza from a server perspective, which can be
useful when debugging client behaviour.
|
|
This is to test how clients handle downloading large files.
|
|
This is not always installed by default on all hosts. We encountered an issue
where this package was not installed, and it was causing the system time to
gradually drift.
|
|
These vary significantly from deployment to deployment, and running this
playbook previously caused issues on fennell.dev deployments, where I need to
be able to deploy certificates by other means.
|
|
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.
|
|
In the README section for acme account information, I had incorrectly referred
to the CAA records as TLSA records (which do not need this information at all).
This commit fixes that mistake.
|
|
This commit updates the README to include config lines that are being used as
of previous commits.
|
|
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.
|
|
Although this playbook originally installed certificates to the server, this
turned out to be a bad idea, because the playbook could in some circumstances
(if the acme project had already renewed the certs) have installed a different
certificate to the remote server.
By delgating responsibility to the acme server fully, this should prevent any
such issues, as well as potential DANE misconfigurations.
|
|
|
|
The naming scheme I'm using for prod and nonprod environments have changed,
therefore this commit also updates the documentation to match this.
|
|
These references were out of date with what was needed from the playbook.
|
|
The AAAA record should be created by the libcloud bootstrap process instead, so
that the playbook can ssh using the hostname as normal.
|
|
The playbook initially deleted the public keys from root's authorized_keys
after copying them to admin, but this prevents the playbook from running the
"Ensure admin account is created" commands in subsequent runs. Therefore, we
shouldn't delete them.
In the long term, I would like to find a way to only attempt to run the root
commands if it's not possible to ssh as admin. This is as I don't like the idea
of root having direct ssh access.
|
|
Initially, I used AWS Lightsail for deployment. However, I am now using Vultr
via libcloud, which does not create a user named "admin" by default. Therefore,
this commit aims to ensure that such an account is created, even on providers
that don't create it by default.
|
|
We remove some extra MUC configuration here that should not be needed, as these
settings should be handled by the defaults anyway.
|
|
These are now fully automated, thanks to the libcloud setup, which is currently
sitting in a separate repository, that will be merged with this one.
Therefore, there is no longer any need to configure these manually.
|
|
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.
|
|
I have moved DNS configuration for all of my servers to deSEC, thanks to its
easy-to-use REST interface. This allows me to configure DNS records as part of
the playbook, instead of having to add them manually for each new server I'd
like to create. The consequence of this is that the playbook now has a hard
dependency on deSEC.
|
|
My ACME scripts currently reload (instead of restarting) prosody after
installing new certificates. Therefore, I would like to make sure that these
new certificates are picked up on such an action.
|
|
This makes it easier to navigate through the playbook, and jump to the part
that you're interested in editing, using the { and } keys in vim.
|
|
I would like certificate renewal to be handled centrally across all of my
deployed services. Therefore, responsibility for certificate renewal no longer
belongs in this playbook.
|
|
I tried to create a fresh nonprod deployment today on
continuous.staging.nonprod.chat.fennell.dev. However, the first step failed
because the apt command could not find borgmatic.
The solution was to run apt update before running apt install. Unfortunately,
ansible's package module does not have an option for this. Therefore, although
I would have liked to stick with "package" (to keep it general and away from
the specific of using "apt" as a package manager), I have switched back to
using the apt module so that the step can succeed without any manual
intervention on fresh install.
|
|
I'll use this file to store notes about the specific deployments I have.
|
|
|
|
This commit adds support for XEPS 0065 and 0365 - i.e. sending files from one
account to another.
|
|
This is based on the recommendation of Monal's "Considerations for XMPP server
admins" document.
|
|
This commit adds support for XEP-0215, or the discovery of external services.
|
|
This commit adds support for XEP-0357, or cloud push notifications, and lets
notifications be reliably delivered on iOS and Android.
|
|
This should help reduce XMPP clients' battery consumption on mobile devices.
|
|
I would like the message expiry to be very long, so that there is very little
chance of users not being able to retrieve messages.
|
|
This commit enabled SOCKS5 Bytestreams, allowing users to send and receive
files.
|
|
Previously, the playbook would fail if it needed to install packages, as this
(in the case of apt) requires sudo.
|
|
At present, these are not automated by the runbook and need to be manually run
as part of setup for each new managed host the playbook is run against.
|
|
This directory is created by a user command, not as part of the package
installation process. Therefore, it may not exist if the user has not yet
configured borgmatic on the host.
|
