*hass2.pyrocufflink.blue* is a Raspberry Pi Compute Module 4-based
system, currently mounted in a WaveShare CM4 Mini Base Board (A). With
an NVMe SSD for primary storage, it runs significantly faster than a
standard Raspberry Pi 4, and blows the old Raspberry Pi 3-based Home
Assistant deployment out of the water. It has a Zooz 700 series Z-Wave
Plus S2 USB stick and a ConBee II Zigbee USB stick attached to its USB
2.0 ports. It runs a customized Fedora Minimal distribution.
*Mosquitto* implements an MQTT server. It is the recommended
implementation for using MQTT with Home Assistant.
I have added this role to deploy Mosquitto on the Home Assistant server.
It will be used to send data from custom sensors, such as the
temperature/pressure/humidity sensor connected to the living room wall
display.
The *websites/proxy-matrix* role configures the Internet-facing reverse
proxy to handle the *hatch.chat* domain. Most Matrix communication
happens over the default HTTPS port, and as such will be directed
through the reverse proxy.
* Need to apply the *postgresql-server* role to ensure PostgreSQL is
properly configured
* Need to supply a PostgreSQL certificate (use Let's Encrypt so we don't
have to manage a CA)
* Missing Ansible Vault file that includes the DB user password
This commit updates the configuration for *pyrocufflink.net* to use the
wildcard certificate managed by *lego* instead of an unique certificate
managed by *certbot*.
*chmod777.sh* is a simple static website, generated by Hugo. It is
built and published from a Jenkins pipeline, which runs automatically
when new commits are pushed to Gitea.
The HTTPS certificate for this site is signed by Let's Encrypt and
managed by `lego` in the `certs` submodule.
For reasons that totally elude me, Gitea LDAP authentication suddenly
stopped working, citing an error about not trusting the server's
certificate. I thought this was probably some change in a recent
version of Gitea or Go that changed how the system trust store was used,
but it turned out the problem was actually that Samba was not sending
the intermediate CA certificate. I am not sure if this was always the
case, and the fact that it worked before was a coincidence, or if
something changed in Samba. In any case, the fix was (apparently) to
include the intermediate and root CA certificates in the server
certificate file.
The `logo` symbolic link under `certs` serves as a more convenient path
for the certificates in the `.certs` submodule. Roles can refer to
certificates using this path instead of the submodule directly.
The *certs* repository contains certificates issued by Let's Encrypt
automatically using Lego. A Jenkins job runs daily to renew these
certificates as needed, and commit updated certificate files to the
repository.
To deploy these certificates to the applications that use them,
jobs will need to be scheduled to apply configuration policy for those
applications regularly. Using symlinks to the files in this submodule,
Ansible can deploy those files whenever they change.
Since the same certificate is used for LDAPS and RADIUS (EAP-TLS), it
makes more sense to store it only once, with the later file as a symlink
to the former.
Dustin