Ansible playbook that deploys prosody to a server. https://git.fennell.dev/xmpp-prosody-ansible-deploy/atom?h=master 2026-09-09T21:57:57Z 2026-09-09T21:57:57Z Matthew Fennell matthew@fennell.dev 2026-09-09T21:57:57Z urn:sha1:79defd7005932723df05f96b33ad7d3f5876413d This ensures that the necessary packages and prosody-specific munin plugins are configured by default. 2026-09-09T21:22:07Z Matthew Fennell matthew@fennell.dev 2026-09-09T21:22:07Z urn:sha1:4d958b4784ceda51e0dbb95f8f87d23fdbc4153a I've moved these tasks into their own roles, which can now be used directly. 2026-09-09T20:02:34Z Matthew Fennell matthew@fennell.dev 2026-09-09T20:02:34Z urn:sha1:a9d2acc5987edc8425bfb39156befa7a14adae6b 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. 2026-08-29T23:36:11Z Matthew Fennell matthew@fennell.dev 2026-08-29T23:36:11Z urn:sha1:184a6ac426a0cc5ed1ee9dbb5287affa94464142 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). 2026-08-29T21:09:30Z Matthew Fennell matthew@fennell.dev 2026-08-29T21:09:30Z urn:sha1:8b1ba2a7d9f0509253e37e5832c4bc74b44d009d Begin with already-included and postgres modules. I'll look to add prosody-specific modules in time. 2026-01-14T23:11:39Z Matthew Fennell matthew@fennell.dev 2026-01-14T23:11:39Z urn:sha1:546a3bb370a8394d133228236a835a0b606ae8a8 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. 2026-01-11T15:05:36Z Matthew Fennell matthew@fennell.dev 2026-01-11T15:05:36Z urn:sha1:71dff47fe74bd888feb957ee545ba9bdad6fb076 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. 2026-01-10T15:45:03Z Matthew Fennell matthew@fennell.dev 2026-01-10T15:45:03Z urn:sha1:4cdb662d1ee723d3190d29d65732a1877d628fbf Technically, the database is only being created and not fully set up. 2026-01-10T15:41:57Z Matthew Fennell matthew@fennell.dev 2026-01-10T15:41:57Z urn:sha1:f0c3a3056f317aa1065fbf23668a245b62b55165 This enables delta backups, reducing bandwidth sent off the server. 2026-01-10T15:39:31Z Matthew Fennell matthew@fennell.dev 2026-01-10T15:39:31Z urn:sha1:f3a0496912c4ceb9d2032946bb0e31525f50a613 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.