All machines are on the same subnet; network-wise, it’s all very vanilla. From the machine hosting Home Assistant Supervised, I can ping the Emby server by its name (meaning it can resolve the hostname “io”).
Have I missed a configuration step with Home Assistant Supervised or is this a bug in 0.109.X?
The solution proved to be trivial to implement but it made me realize that I don’t really understand Supervisor’s “network plumbing”.
Using portainer, I opened a console in the Home Assistant container and tried to ping the Emby server io. The ping operation failed. I repeated the test and pinged io’s IP address and that was successful.
I repeated the test from within the container of the instance installed as Home Assistant Core and was able to ping io successfully.
In other words, within the Supervised instance, it cannot resolve host names on my network. On the instance of Core installed as Docker, within its container it can resolve host names. That means it uses my local network’s DNS whereas the Supervised instance apparently doesn’t.
I’ve modified the Emby integration’s configuration and replaced the hostname with its IP address. After a restart, Home Assistant Supervised connected to the Emby server.
Can someone explain how to make the Supervised version recognize the local network’s DNS? Or is that inadvisable?
I may be wrong but I don’t think I need to do that because here’s the current output of ha dns info
host: 172.30.32.3
locals:
- dns://192.168.1.2 <---- This is correct.
servers: []
version: "9"
version_latest: "9"
It’s already configured to use my local DNS exclusively (i.e. no fallback servers). In addition, from the SSH shell I can successfully ping io (although I imagine that has more to do with how the underlying Ubuntu is configured network-wise).
The situation is different within the homeassistant container. I used portainer to open a command shell in the homeassistant container (which is, like all recent versions, running Alpine Linux). Pinging a local host by its name fails:
bash-5.0# ping io
ping: bad address 'io'
Whereas pinging by its IP address works:
bash-5.0# ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5): 56 data bytes
64 bytes from 192.168.1.5: seq=0 ttl=128 time=0.753 ms
64 bytes from 192.168.1.5: seq=1 ttl=128 time=0.655 ms
64 bytes from 192.168.1.5: seq=2 ttl=128 time=0.844 ms
^C
--- 192.168.1.5 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.655/1.517/3.053 ms
I repeated the ping io test in these other containers:
The test succeeded in all of them except hassio_multicast. Therefore out of the five containers just two don’t know how to resolve local host names. The critical one is, of course, the homeassistant container.
See the difference? The two that can’t resolve names lack the ndots option.
I did a few searches for Alpine Linux and ndots and discovered how this option affects name resolution. Long story short, it’s needed here.
To prove it works, I used vi to edit /etc/resolv.conf and added options ndots:0 to the file. I learned that changes to resolv.conf are effective immediately. I tried ping io and it worked instantly.
That was a journey! I intend to post this as an Issue but I’m not sure if the Supervisor repo is the correct one. I guess it would go in whichever repo is responsible for configuring Alpine Linux in each container, notably the hassio_multicast and homeassistant containers.
I submitted this as an Issue in the Supervisor repo.
I received an unexpected response and the Issue was promptly closed. Long story short, I was informed to use Home Assistant Core.
I believe there must have been a miscommunication so I have provided other details in the hope it will clarify the situation.
In a nutshell, any integration that needs to communicate with a local host can currently specify either the host’s name or its IP address. The exception is Home Assistant Supervised (and possibly also the version that runs on HassOS). If you specify an unqualified hostname like this then the integration will fail to connect:
It’s unnecessary to use fully-qualified names with Home Assistant Core (venv or Docker). I’m looking for a way to have Home Assistant Supervised behave like its siblings. One way is to add the ndots:0 option but that suggestion was rejected.
I feel there should be parity among the different “types” of Home Assistant; there should be no need to modify hostnames when switching from one type to another.
I recently changed my production system from Core venv to Supervised. My test system runs Core docker-compose.
Originally I envisioned changing the production system to Core docker-compose because I found it easier to upgrade and manage than the venv version. However, I decided to go one step further and try the Supervised version.
Basically the Supervised version incorporates other applications into a near-seamless management UI. It’s not hard to use docker-compose to upgrade Core or add a Node-Red container. However, it’s downright trivial with Supervised. Upgrades are a one-click operation. Adding the Node-Red Add-On is just a few clicks and the resulting instance is integrated into the management UI.
There are a few other conveniences like the mosquitto container can use accounts created in Home Assistant and backups are simplified by the snapshot feature.
The one thing I don’t like is that everything runs as root. I had mosquitto and Node-Red running on an RPI3 with non-root accounts. I now have those services consolidated on the machine running Supervised where they run as root. Neither my venv or docker-compose instances of Home Assistant run as root so this is an unwelcome change.
In light of the recent announcement that Home Assistant Supervisor on generic Linux is discontinued, the timing of my switch couldn’t be worse. Now I’m running a brand new production system that is no longer supported.
</insert sad pikachu face here>
You may want to take that into consideration when deciding to make the switch. Now the Supervised edition is supported only on specific hardware platforms or in a virtual machine. FWIW, the hardware I’m using isn’t any of the supported ones.
Lucky me has already a Proxmox setup, so I’ll probably going to use the VM image to further test Home Assistant. For the time being I’ll continue using HA Core and roll my own containers.
I really like the smooth integration of add-ons into Home Assistant and it was really easy to configure them. Also the snapshot backup and restore functionality is pretty nice.
I don’t like that I need to install an add-on for Samba and SSH, what if the docker stack fails, how am I supposed to SSH into the machine to fix some code or transfer some files I might have forgotten to backup? What I also don’t like is automatic updates, I want to decide when I want to update what. Fortunately I didn’t have such an issue (yet), but I read quite a lot of topics recently about a failed system after an automatic update of the supervisor, but I’m not sure whether it was related or not.
If this method will not be deprecated as well , I’m probably going to continue using HA Core in Docker. I anyway do automatic regular backups of the HA VM, so the snapshot functionality is of no interest for me. And for the add-ons, I didn’t find anything interesting, that I didn’t have already in my docker stack.
Do you happen to know, if one is still able to run an additional docker-compose stack when using HassOS?
I haven’t used HassOS but my impression is that it is not possible to add services to it. It’s meant to be just enough of an OS to support the docker infrastructure. Additional services are added as docker containers (i.e. Add-Ons).
Currently, I’m using the following Add-Ons:
Mosquitto
Node-Red
Aircast
File Editor
SQLite Web
Installing, configuring, and managing them has proven to be easier than via docker-compose. Installing/configuring via docker-compose isn’t difficult but there’s no common management UI (i.e accounts, logs, status, etc). Portainer certainly helps but account management remains unique to each service.
I run ssh and samba services on Ubuntu as opposed to using Add-Ons. I also run Portainer as a standard docker container as opposed to an Add-On. Should the Supervisor or all of docker fail, I still have a way of accessing the system to fix the problem. This is more valuable to me than the benefits of Add-Ons. If I was no longer able to use Home Assistant Supervised on generic Linux, then I would probably revert to using docker-compose.
For me, everything would change if I was obliged to use HassOS
, I’m probably going to continue using HA Core in Docker. I anyway do automatic regular backups of the HA VM, so the snapshot functionality is of no interest for me. And for the add-ons, I didn’t find anything interesting, that I didn’t have already in my docker stack.