Ansible configuration policy for the private network/home lab of Dustin C. Hatch
http://dustin.hatch.name/
Dustin
288b050a33
Installing Home Assistant in a Python virtualenv is rather tedious, especially on non-x86 machines. The main issue is Python packages that include native extensions, as many of these do not have binary wheels available for aarch64, etc. on PyPI. Thus, to install these, they have to be built from source, which then requires the appropriate development packages to be installed. Additionally, compiling native code on a Raspberry Pi is excruciatingly slow. I have considered various ways of mitigating this, but all would require a substantial time investment, both up front and ongoing, making them rather pointless. Eventually, I settled on just deploying the official Home Assistant container image with Podman. Although Podman includes a tool for generating systemd service unit files for running containers, I ended up creating my own for several reasons. First and foremost, the generated unit files configure the containers to run as *root*, but I wanted to run Home Assistant as an unprivileged user. Unfortunately, I could not seem to get the container to work when dropping privileges using the `User` directive of the unit. Fortunately, `podman` has `--uidmap` and `--gidmap` arguments, which I was able to use to map UID/GID 0 in the container to the *homeassistant* user on the host. Another drawback of the generated unit files is that they specify a "forking" type service, which is not really necessary. Podman/conmon supports the systemd notify protocol, but the generator has not been updated to make use of that yet. Recent versions of Home Assistant are more strict with respect to how reverse proxies are handled. In order to use one, it must be explicitly listed in the configuration file. Therefore, the *homeassistant* Ansible role will now create a stub `configuration.yaml`, based on the one generated by Home Assistant itslf when it starts for the first time on a new machine, that includes the appropriate configuration for a reverse proxy running on the same machine. The stub configuration will not overwrite an existing configuration file, so it is only useful when deploying Home Assistant for the first time on a new machine. Overall, although I think a 300+ MB container image is ridiculous, deploying Home Assistant this way should make it a lot easier to manage, especially when updating. |
||
|---|---|---|
| .certs@654b52b608 | ||
| certs | ||
| ci | ||
| group_vars | ||
| host_vars | ||
| passwords/kojiweb_secret | ||
| roles | ||
| vars | ||
| vault | ||
| .gitignore | ||
| .gitmodules | ||
| .vault-secret.sh | ||
| ansible.cfg | ||
| ansible.yml | ||
| aria2.yml | ||
| base.yml | ||
| bitwarden_rs.yml | ||
| burp-client.yml | ||
| burp-server.yml | ||
| certbot.yml | ||
| collectd.yml | ||
| dch-gw.yml | ||
| dch-proxy.yml | ||
| dch-root-ca.crt | ||
| dch-vpn.yml | ||
| dhcpcd.yml | ||
| dhcpd.yml | ||
| docker.yml | ||
| domain-controller.yml | ||
| dyngroups.yml | ||
| fileserver.yml | ||
| firewalld.yml | ||
| gitea.yml | ||
| grafana.yml | ||
| graylog.yml | ||
| hassdb.yml | ||
| homeassistant.yml | ||
| hostname.yml | ||
| hosts | ||
| hosts.offline | ||
| jenkins-slave.yml | ||
| koji-builder.yml | ||
| koji-hub.yml | ||
| koji-web.yml | ||
| koji.yml | ||
| motioneye.yml | ||
| named-server.yml | ||
| net-ifaces.yml | ||
| network.yml | ||
| nextcloud.yml | ||
| ntp.yml | ||
| postgresql.yml | ||
| protonvpn.yml | ||
| pyrocufflink.yml | ||
| radius.yml | ||
| radvd.yml | ||
| remount.yml | ||
| rngd.yml | ||
| samba-dc.yml | ||
| smtp-relay.yml | ||
| squid.yml | ||
| synapse.yml | ||
| taiga.yml | ||
| vmhost.yml | ||
| websites.yml | ||
| wheelhost.yml | ||
| zabbix-agent.yml | ||
| zabbix-server.yml | ||
| zabbix.yml | ||
| zezere.yml | ||