PR 2789 does not allow: "People can run what ever they want"

[tdejneka]

Describe the issue you are experiencing

This is somewhere between a bug and a feature request. The "bug" is a recent PR does more than merely warn a user and the "feature request" is to workaround the PR by allowing for slightly more functionality.

---

For at least two months now, I have been making a small change to Supervisor's source code in order to reduce the number of connectivity and version checks. It amounts to nothing more than altering the value of two integers in tasks.py.

This value was changed to 7200

line 50: RUN_CHECK_CONNECTIVITY = 30

and this value was changed to 86400

line 456: if value >= 600

That was sufficient to perform connectivity checks every few hours and a version check once a day.

I was unaware of this PR whose goal is:

This is not to provent code modification, it's just to show that it lost the supported state and people are on his own if they run into issue which not should be sended to sentry. This just prevent reports from modified installation.

People can run what ever they want, it should just not show as supported.

I wish to report that it does more than just benignly warn the user and people cannot "run whatever they want".

I run two instances and both use Home Assistant Supervised on Debian 10. They run a slightly modified Supervisor (as described above) and so both reported they were unsupported and unhealthy.

On the generic Intel machine, I was allowed to open any of the installed Add-Ons. However, on the RPI3 it prevented me from opening any of the three installed Add-ons (File Editor, Portainer, Samba). The response was "401: Unauthorized". I don't know why the two (otherwise similar) systems differed but they did and the RPI3 version is where I first discovered it was unhealthy due to "source_mods".

On both machines, one could no longer install Add-Ons:

Failed to install add-on
AddonManager.install' blocked from execution, system is not healthy

That's not unexpected, given that the system is now considered unsupported and unhealthy, but doesn't comply with the PR's claim "People can run what ever they want, it should just not show as supported"

I thought fixing the problem would be as easy as replacing the Supervisor image with a fresh copy but there's no ha command to do that (neither repair or update succeeded). Rather than turn to docker to replace Supervisor's image, I simply reversed the source-code changes I had made, restarted Supervisor, and the system reverted to being healthy and supported.

I suspect the PR was intended to protect users from malicious changes to Supervisor's source code. However, if someone is being truly malicious, they will also disable this self-check thereby rendering this PR moot. As a consequence, only users making benign changes to the code are adversely affected by the PR.

Ideally, I'd like the self-check to be removed, but I realize that's highly unlikely to happen. Therefore I would appreciate it if the user can be granted control over the frequency of the connectivity/version checks. The current frequency makes my two systems one of the most "chatty" clients on my local network.

---

NOTE

Originally I used Home Assistant OS on an RPI3 but its operating system has a hard-coded connectivity check every 5 minutes in addition to the 10-minute connectivity check performed by Supervisor. The check performed by the operating system cannot be throttled so I switched to Home Assistant Supervised on Debian (because Debian does not perform a connectivity check by default). However, now even that avenue has been blocked (because Supervisor's source-code mods are flagged) so I'm left with no functional means of throttling connectivity/version checks (other than switching to Container or Core which seems like a high-maintenance way of acquiring the trivial ability to throttle the checks).

What is the used version of the Supervisor?

supervisor-2021.04.3

What type of installation are you running?

Home Assistant Supervised

Which operating system are you running on?

Debian

What is the version of your installed operating system?

Debian GNU/Linux 10 (buster)

What version of Home Assistant Core is installed?

2021.5.1

Steps to reproduce the issue

Simply make a small benign change to tasks.py and that's sufficient to prevent installing Add-ons and potentially, as I experienced with an RPI3, even opening existing, installed Add-ons.

Anything in the Supervisor logs that might be useful for us?

Logger: homeassistant.components.hassio
Source: components/hassio/websocket_api.py:109
Integration: Home Assistant Supervisor (documentation, issues)
First occurred: 09:25:01 (2 occurrences)
Last logged: 09:38:50

Failed to to call /addons/core_configurator/install - 'AddonManager.install' blocked from execution, system is not healthy

Additional information

No response

[frenck]

For at least two months now, I have been making a small change to Supervisor's source code in order to reduce the number of connectivity and version checks.

The connectivity checks are used to prevent tasks from using the internet, while not available. If the internet returns, it works again 🤷 . It prevents erroring out. That is not weird or blocking anything.

I run two instances and both use Home Assistant Supervised on Debian 10. They run a slightly modified Supervisor (as described above) and so both reported they were unsupported and unhealthy.

That would be correct. If you change the code, it becomes your system/software/project/custom thingy with your modifications. You can run it, but it won't be supported by the Home Assistant project. We can't validate or ensure quality on changes you make. Nor can we support any problems that that may cause.

Nevertheless, one can run an unsupported system. The unsupported message doesn't adjust any behavior, except for 2 things:

• A visual indication.
• One cannot opt-in to crash reporting and such, as we cannot know what you change or running.

Unhealty; this means you are running things that cause problems for the Supervisor to function. E.g., missing permissions, known problematic compatibilities issues with e.g., Docker or simply missing parts on the system it runs on. These are things that can damage your system if the Supervisor continues to do its job. As a result, it stops making changes. You can override those jobs via the Home Assistant CLI if you really want to, but I would highly recommend fixing unhealthy things.

TL;DR:

• Unsupported = Custom/out of spec. Feel free to run it, but not supported by the Home Assistant project.
• Unhealthy = System problems on a level that may cause serious issues. As many tasks as possible are halted to prevent a broken or unavailable system.

[tdejneka]

Unhealty; this means you are running things that cause problems for the Supervisor to function. E.g., missing permissions, known problematic compatibilities issues with e.g., Docker or simply missing parts on the system it runs on

That was my point, by all the usual metrics for health, my system is healthy with the minor modification. The proof is that two instances ran flawless for over two months. Now they are both deemed to be unhealthy based on an over-reaching metric (any code patching is instantly flagged as unhealthy).

If it was only marked as unsupported then it would fair; I have patched the code so I am on my own. However, this takes the added step of including unhealthy which then constrains Add-Ons, etc.

[frenck]

You can disable that if you don't share that opinion. That is up to you.

[tdejneka]

Sorry, I didn't understand your suggestion. I should disable what exactly?

If you meant I should refrain from patching Supervisor then that leaves me with no ability to throttle its frequent DNS lookups, connectivity checks, version checks, etc. If this would be configurable then I wouldn't need to patch it.

Or did you mean something else?

[frenck]

If you meant I should refrain from patching Supervisor then that leaves me with no ability to throttle its frequent DNS lookups, connectivity checks, version checks, etc.

Personally, I think those are fine.

If this would be configurable then I wouldn't need to patch it.

Sure, feel free to contribute a suggestion implementation for those.

Or did you mean something else?

You can override jobs conditions using the Home Assistant CLI as stated in my first response.

[tdejneka]

Follow-up:

Thanks for the tip regarding the CLI; I wasn't aware of the option's availability.

I executed ha supervisor options --content-trust=false then restarted Supervisor. Now the instance is no longer unhealthy, just unsupported. That's a fair compromise; it now allows me to use the Add-On store and perform updates. Should something go awry, I can easily restore supported mode (reverse the patch, enable content-trust).

Naturally, I would prefer not to disable content-trust nor to patch Supervisor's code. Ideally, I could configure Supervisor's polling frequency (for connectivity and version checks). Therefore, I followed through on your suggestion and posted a Feature Request to have more control over Supervisor's configuration.

https://community.home-assistant.io/t/allow-some-degree-of-control-over-supervisor/306830?u=123

Although I described using a supervisor.yaml file, to store its configuration, it would be equally acceptable to use the CLI to set options like the time interval for --connectivity-check and --version-check.

The Feature Request is open to users' suggestions but I've asked that it be limited to configuring Supervisor's existing functionality (as opposed to requesting entirely new Supervisor functions).