I’d actually quite happily run HAOS, I quite like it. It’s much easier to deal with when you have no Linux background.
The only reason I learnt to run supervised was so I could make my addon to be fair.
The main reason I run portainer not as an addon directly is it makes it easier to troubleshoot, particularly restores. As it loads before homeassistant.
Sure I could run container, it would have made my addon not needed. I wouldn’t have learnt how to make an addon(poorly) and would have to find containers to replace my existing addons… I would probably be better in Linux now though(maybe) or perhaps better in yaml.
I could quite happily break stuff nearly as well with docker cli now though.
The better way to do that commit linked a few posts up would have been to make it positive…
Healthy containers
Null
Perhaps I should look into running a vm on my rpi to install HAOS…
Not that I’m encouraging running portainer but for the record, running before homeassistant is an option for addons. See startup in here:
initialize will start add-on on setup of Home Assistant. system is for things like databases and not dependent on other things. services will start before Home Assistant, while application is started afterwards. Finally once is for applications that don’t run as a daemon.
Truth be told, if there’s a piece of software out there that you like and they publish a docker image it’s usually not too difficult to turn it into an addon. You don’t even need a git repo if you just want to make it for yourself, just use /addons.
Some require more effort then others. I feel like the main thing when I do it is usually just finding what folders it uses and using ln to actually make the software store things in /data that should be persistent and look for things in /share or /ssl that it needs as input (for ones that want config files instead of envs and args). But then it can be managed entirely through HA so there’s benefit. And this is only for the ones where someone didn’t do the work for you, people have made and shared a lot of addons on here.
If I was going to do that it would be with the portainer addon that is available…
It would probably achieve starting prior to anything else during a restore, although it also hides the HA related containers.
So I could fiddle with that.
I could even run it as local addon.
Or I could just run portainer directly as a container.
Perhaps it’s time to remove the Supervised install guide… Just list 3 install methods.
I installed the Supervised version many years ago and I’ve totally forgetten why! ROFL. Wasn’t there a restriction on accessing add-ons or cloud-access in the past that made it more ‘functional’ than a straight container-based deployment?
I’m posting on an alt for… reasons. English is also not my first. This change is completely absurd. Having portainer itself as a blacklisted unhealthy trigger??! I run a home automation youtube channel and have always supported and advocated for yall in the past. As you guys slowly tightened down the ‘security’ of home assistant, I made small adjustments and went along. It helps people with no experience prevent something bad happening. I understood, to an extent.
But there comes a point where you are clearly overstepping bounds. Running portainer separate from home assistant has its benefits. Due to the limited CPU/GPU speed, bugs in some of the addons and integrations, sometimes the system gets bogged up. The less powerful the machine, the quicker this happens.
To the point where the system is not reachable. 90/100 pings fail. It’s a headless unit I am running it on, completely inaccessible and behind a literal wall.
The only solution when something goes haywire like that (usually deepstack or something memory intensive), is rebooting and QUICKLY logging into portainer to shutdown the home assistant container itself. I am then able to SSH in, cleanup what is needed, and restart everything.
Having portainer running as an ‘addon’ (even BEFORE home assistant starts) is just not sufficient.
Please revert this change. My followers and many others will be forced to stay on previous versions or slowly lose interest/motivation due to the unncessary work. Other projects will come along and make home assistant redundant long-term if cutting people out like this keeps up. Especially with the rise of start-ups as well as Google taking initiative this year in the automation scene. (Matter catalyst)
The No1 priority of any software project/developer is reliability/stability. As @CentralCommand explained so many times in the past running HAOS or Supervised (HASU) is a closed loop system, allowing tinkering within the bounds of the system. HASU, if left unchecked, generates so much unnecessary noise in the forums, which distracts from the prime objective of HA, which is to reliably run an automation/control system.
If you like tinkering outside the bounds of the HAOS/HASU system then Container (HACO) is your other option, which is boundless, but requires a skilled operator to navigate the environment.
For anyone without the skill or the time to tinker, HAOS/HASU is available to them. For everyone else, HACO is the way to go offering boundless tinkering.
For anyone interested primarily in the automation/control side of things, I strongly suggest HAOS as it is the environment with the least demands in terms of system administration and the most reliable in terms of operation. It also provides a predictable environment to facilitate speedy assistance when, infrequently, issues arise.
If HASU is causing so much havoc in the forums, then obviously the solution is to cull that install option if it detracting from the main purpose of the forums. Removing portainer isn’t going to lessen the havoc.
Just a simple GUI option that requires confirmation you’re happy you may trash your system by using Portainer would be a more ‘open’ solution to an open source project. I appreciate Mike’s very clear and detailed explanations here and I get the merit of trying to keep things safe, but just like a lot of things (click 6 times to get Android developer options), we should have an option to be trusted and keep things flexible.
There’s not going to be a gui option here. If you want to run unsupported or unhealthy that’s a choice you can make and the cli gives that option. Spending dev cycles to make it easier for people to run unsupported easier isn’t really how software works? Dev cycles are spent on the making it easier for people to run the software as intended, users running in other ways are on their own.
This option exists though, it’s in the cli. I mean if you have portainer it was obviously installed via the cli so you have access to that.
Also tbh this isn’t really about safety. Running a container from some random image you found on the internet is the same level of safe as installing a hacs component or installing an addon outside of the official repo. There’s likely one developer responsible with merge access that is also the only one doing reviews. They’re software now has pretty extensive access to your network and system so hopefully you trust them. Maybe more safe in some cases if there is a well-known team behind that particular piece of software.
The main reason behind all this is trying to clearly lay out the bounds of what the HA team supports. Because there is continuous wasted cycles on issues where the root cause turns out to be “user installed x or changed y via the host shell, docker cli, portainer, etc. and it broke”. Which then means the issue is rejected, the developer is unhappy they wasted their time and the user is unhappy because “if it used to work and doesn’t it’s your fault!”
So I’m sorry but it’s not going to be made easier to run unsupported. And more checks will keep being added as things come up in issues. Because otherwise there will eventually be no one left to work on supervisor and addons if developers have to spend all their time debugging issues on unsupported systems.
Here is a workaround that actually helped me to ignore the unhealthy state:
With this file created the superviser won’t complain anymore about the portainer running (and anything else that makes your system “unhealthy”) and will update the HA to the latest version.
Of course, do this only if you are sure what you are doing and WILL remember about this change in the future, in case it becomes a some kind of an obstacle by itself.
P.S. this file should be created in /usr/share/hassio of the host system. Not inside the system of a HA container.
One correction to this: feel free to post whatever you want to this forum. This is community space, if you’re struggling with an unsupported system its a fine place to post and see if anyone else happens to run the same config as you and solved it.
Just don’t create any github issues on HA repos. They will be ignored/rejected unless reproduced on a supported and healthy system.
So i stumbled across the same problem and i was like WTF!?
I am glad i found this topic here so i know what the reason was.
after removing the portainer container from my docker setup and restarting the whole system my system went to healthy again and i could update again. now i reinstall portainer as a container and redo the same procedure when i want to install the next update.
but i mean… come on…
i understand this change happens due to security issues but there should be a way to exclude these checks for certain containers (like portainer). everyone with access to cli can do this tedious workaround with downtime of all containers…
please revert this back or give us users a way to exclude portainer from this “unhealthy list”
There’s no downtime required. Scroll literally one post up from yours to see how.
As I said earlier, this isn’t really about security.
This is primarily about developer time. There is a very small set of developers working on supervisor and unfortunately a lot of that time is spent digging into issues that turn out to be “user did something unsupported and it broke”. Every unsupported or unhealthy check that is added is done so because its a source of at least one issue in supervisor/addons/ha, most of them many.
As to why portainer is unhealthy vs unsupported, its container orchestration software. There’s no one thing it does that is bad, it makes it easy to change any number of things about the docker setup in ways that break HA and supervisor. Plus its job is literally the same as supervisor, to manage your system and the docker network. So if you want to use portainer, just switch to a container install and get rid of supervisor instead of having putting two pieces of container orchestration software on the same system.
I think it’s easier to get rid of portainer than switching the installation methods and dependencies of all add ons.
And I think that is what I will do.
I see your arguments but I don’t think this will be the best solution to your problem.
As you see there are already two workarounds for this and portainer could still work with supervised install.
So people who want to run portainer with supervised could still do it. Mostly they are not the same people which will break there System and ask for help.
I think you will have some hard time to justify this decision when every supervised user with portainer wants to update
And I hope you will implement some gui switch to switch the healthy check on/off or a button which says“ I know I do crap and my system can break but I won’t ask for help when I update and something went wrong“
EDIT: when i would disable the health check is it save to run ha supervised? or do i need it?
That’s ok. In fact if there were no workaround that would be a real problem. It is your hardware after all.
The goal isn’t to stop people from shooting themselves in the foot if that’s what they really want to do. That’s not possible and trying to do so is a waste of time.
The goal is simple:
Make sure people are aware what they are doing is unsupported, untested, has broken systems unexpectedly and very likely will do so again without warning in any update (major, minor or patch)
Make sure developers can easily identify and filter out issue reports from users choosing to run unsupported systems since those aren’t bugs. Users running unsupported systems must either reproduce their issues on a supported system or fix any issues they encounter themselves.
Yeah but this seems a bit hard for me. There should be a message or something but not an error you cant fix in an easy way.
But thats just my opionion i can live with any of the workarounds. Im still very happy that you and all other devs are doing such a great job and giving me some good time with my smart home.
I hope that i didnt sound too angry, i just paniced a little and i my only thought was why in the world would anybody do this. now some hours later i can totally agree with this.
the only thing which should be done is to notify supervised users (maybe with portainer) what they should or can do.
I have just seen this error in supervisor log which is blocking HA updates:
— Found image in unhealthy image list ‘portainer/portainer-ce’ on the host…
I assume from this thread, that it is because I installed portainer as a container manager on the same system (which I assumed 2 years ago was a totally passive/acceptable thing to do).
Can anyone help me out and advise what I should be doing with a supervised install from now on. Also is there an inference from this topic chat that I cannot install any containers (outside selected HA addon’s) on my server?.
