| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
This is now enforced by ansible-lint.
|
|
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.
|
|
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.
|
|
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.
|
|
Backups are now handled outside of the playbook.
|
|
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 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 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 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.
|
|
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.
|
|
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.
|
|
|
|
This commit adds support for XEPS 0065 and 0365 - i.e. sending files from one
account to another.
|
|
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.
|
|
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.
|
|
This commit uses the simpler, more standard validate feature of template
instead of triggering a handler. The feature is there - may as well use it!
|
|
This commit adds borgmatic, to provide automated backups.
|
|
The playbook previosuly assigned the prosody config files to the root group.
With root as the owner, and permissions as 0640, this meant that prosody was
not able to read the files. This commit fixes this.
|
|
This commit ensures certificates are installed, via Lets Encrypt.
|
|
There is no sense reloading prosody if none of its configuration files have
changed. Therefore, this commit moves the reload to a handler that only gets
triggered in this situation.
|
|
This commit uses the new per-host virtual_host variable to create the necessary
prosody host-specific cfg files.
|
|
This commit adds a prosody configuration file that can be installed on the
remote hosts. This lets me make the configuration locally, deploy it to staging
environments, and then to prod, without having to directly login to the hosts.
|
|
This commit enables the necessary ports for XMPP, web hosting (to allow certbot
to renew automatically) and SSH.
|
|
At present, the playbook simply ensures that all required packages are
installed.
|
