Override of version.home-assistant.io

[bentasker]

Part of how I got pulled into looking at HomeAssistant's DNS issues was because I was looking for a way to stop Supervisor's automatic updates:

I've had multiple instances where HomeAssistant has broken because Supervisor updated to a version that wouldn't work with core etc. I want my home automation to be stable/reliable, and clearly that's not possible with HomeAssistant's approach to updating.

Unfortunately, there isn't a way provided to prevent this (and it seems that there won't be, because the devs are opposed)

Supervisor checks for the latest version by making a HTTP call out to https://version.home-assistant.io/stable.json

The thing that led me to the DNS nightmare was looking to block version.home-assistant.io in Pi-Hole so that I could control the update rollout process.

So, I've gone off on quite a tangent. But.... now we're interfering with HomeAssistant's DNS operations, it makes sense to extend the addon so that it's able to block auto-updates.

The aim of this ticket is to add (config gated) functionality that'll work to prevent Supervisor from finding out there's an update for it to install.

[bentasker]

Supervisor uses hassio_dns

➜  ~ docker exec -it hassio_supervisor bash         
bash-5.1# cat /etc/resolv.conf 
search local.hass.io

nameserver 172.30.32.3

nameserver 127.0.0.11

options ndots:0

Although it also uses Docker's built in resolver too.

So, if we want to do this at the DNS level, there are two options

• Push config into hassio_dns to mis-resolve version.home-assistant.io
• Update /etc/hosts in supervisor to mis-resolve version.home-assistant.io

The issue with the former is that results will sometimes get in - when resolution goes via docker instead (odd that they've got both in there, doesn't that rather undermine arguments in favour of having hassio_dns in the first place?)

My inclination, then, is to go with the latter.

[bentasker]

It's not an option any more, but for completeness - one option used to be to patch code in the supervisor container to remove the update task.

But, it now detects changes and marks the instance as unsupported and unhealthy.

Unsupported is one thing, but unhealthy prevents the user from installing addon or homeassistant updates.

[bentasker]

The functionality is implemented - but off by default.

It is a bit racey, as supervisor may still get through after a container restart (i.e. when the addon hasn't had chance to run yet), but on a stable system should block things most of the time.

[bentasker]

But, it now detects changes and marks the instance as unsupported and unhealthy.

I did some digging in #3 - https://github.com/bentasker/HomeAssistantAddons/issues/3#issuecomment-961754704

The protection isn't actually implemented very resiliently - I'd expected there'd be some signature checking etc - if push comes to shove, it can be patched out without too much headache