I deployed HA on a Kubernetes cluster. I have two questions about the container permissions.
This first one is more of a Linux question rather than an HA question but even long googling didn’t reveal the answer, and some of you might have had the same issue. I need Z-Wave and thus be able to write to /dev/ttyACM0 (on the host). This seems to be possible only if I run the container in “privileged” mode. This means that the container has root permissions on the host. Does one really need “privileged”, or are some Linux capabilities sufficient? If so, which one(s)?
Second problem in the same direction: I set “hostNetwork: true” for the HA container. I need this so that HA finds my Chromecast sticks. I read that routing certain ports to the HA container might be sufficient. Is there a list of ports that is necessary for the specific auto discovery features being available?
I set up udev rules to make the USB locations persistent so I just use those ijn the command and set them up correctly in my configuration.yaml file.
As far as the second part, I’m not concerned giving network permissions to the HA container so the above works for me (and I would say most people too).
Unfortunately, I cannot pass arguments to Docker with Kubernetes. In particular, I can only bind-mount devices into the container, and so far, I’ve only managed to have write permissions to them if I made the containers privileged (this works with Kubernetes). I can also set Linux capabilities with Kubernetes, thus my question.
The problem with “--net=host” (or “hostNetwork: true” in Kubernetes speak) is that Kubernetes can only route to containers, not to the host’s network. Therefore, while using the host’s network works in principle, I’m on my own there and cannot use Kubernetes’ infrastructure.
I’m not familiar with Kubernetes but I do use Docker. I don’t recall having to do anything special for accessing my Z-Wave stick. I have run into the issue with Chromecast discovery, however. The first setup I used for HA was to use the “official” HA docker image, which I ran with --network=host. In this setup, HA was able to discover Chromecast devices without any issue.
However, I’ve changed my setup and now I have two Docker containers which I manage with docker_compose:
homeassistant which runs HA with port 8123 exposed. (“exposed” means it is accessible through a network that only docker containers can access).
homeassistant_nginx which runs an nginx instance that maps the host port 8123 to guest port 8123. nginx responds to HTTP requests on port 8123 and forwards them to the homeassistant container (described above) on port 8123.
The problem is that Chromecast advertises using multicast packets, which, by default, are not forwarded across networks. When a docker container is run with --network=host, the container is essentially operating directly on the local network, and there’s no problem. If port forwarding is involved, that’s no longer true and something must be done to forward packets between networks.
Note the same problem is encountered when people want to organize their home network to segregate the IoT devices on a separate network from their laptops/phones/desktop computers, etc. When the Chromecast devices are moved to the IoT network, then the devices on the other network are not able to see them anymore. The solution is to forward the multicast packets between the two networks. The solutions I’ve see for this seem relatively simple to implement. However, docker does its own manipulation of the forwarding tables, which complicates things. I’ve not yet hit on the formula that makes it work fine.
Sorry… as I’m using docker only and I don’t know if this solution applies to k8 too. For those containers that usually need “host network” and for the others which you have to add lots of ports my approach is to use the macvlan bridge so they work as just another vm/machine on your network. My config works like this:
docker machine /etc/network/interfaces:
auto intranet
iface intranet inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
pre-up ip link add link enp1s0 name intranet type macvlan mode bridge
I got it working here now and the solution turned out to be much simpler than the lengthy explanations and configurations I ran into. I only had to:
Install avahi-daemon on the host.
Turn on the reflector. Go into /etc/avahi/avahi-daemon.conf and change the reflector section to:
[reflector]
enable-reflector=yes
reflect-ipv=no
With this in place HA was able to detect the devices it could cast to.
The sources I ran into on the web we discussing incrementing the TTL of packets, etc. That turned out to be a red herring on which I lost quite a bit of time.
It took some more work to get TTS to play on the devices. You need a proper base_url, etc. Those issues are discussed in a whole bunch of posts on this forum.
Avahi and network bridges are complicates enough for me to stay with the “host network” configuration. (To be honest, I hate Avahi with a passion. It perpetually runs amok on my systems.)
That said, I got away with hard coding my TV sticks into my HA configuration. I think that now I miss displaying the currently shown movie in HA but I can live with that.
This! So simple and yet it doesn’t seem to be documented anywhere. Running HA with docker-compose, through a named docker network and Caddy reverse proxy. Just make this change, reboot, all the Google cast devices show again.
