Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add mDNS support per container #11

Open
MatthewCroughan opened this issue Nov 12, 2019 · 7 comments
Open

Add mDNS support per container #11

MatthewCroughan opened this issue Nov 12, 2019 · 7 comments

Comments

@MatthewCroughan
Copy link
Contributor

Each container should either run mDNS via the Avahi-Daemon, or should at the very least have some manner of having mDNS redirected to it. The latter solution does not yet exist, but is something I could potentially write in Python after a bit of reading. My idea for that is that there should be a sort of broker that sits between the applications on the hypervisor that will take all of the container names and masquerade as their hostname. It would then redirect to the relevant internal IP of the container it's meant for, like a webserver would. Though I'm going to try and implement the former first just to get it done.

@MatthewCroughan
Copy link
Contributor Author

MatthewCroughan commented Nov 12, 2019

This may not happen so smoothly for a multitude of reasons.

There is no clear method of doing this, and running an avahi-daemon inside every container is no longer supported and is outright unsupported/removed as functionality since 2017 as mentioned in this Readme:
https://github.com/balena-io-playground/balena-mdns-service

Avahi now runs on the host os and communicates to guests via Dbus. Though I have been unsuccessful in getting any of the containers pingable at the requested hostname.local, despite the hostos having a process labelled 'requesting $hostnamewhere $hostname is the hostname applied in this script.mqtt is the example.

BUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket \
  dbus-send \
  --system \
  --print-reply \
  --reply-timeout=2000 \
  --type=method_call \
  --dest=org.freedesktop.Avahi \
  / \
  org.freedesktop.Avahi.Server.SetHostName \
  string:"mqtt"

All the guides suggest using https://github.com/balena-io-playground/balena-avahi-dbus and https://github.com/balena-io-playground/avahi-zoo-publisher/tree/master/avahi-publisher but I've had little success. Will pick up on this when I'm less tired.

@ajlennon
Copy link
Member

There's already some kind of internal host name mapping which is how containers communicate with each other. Have you looked at this?

There's also a Balena example of how to enable mDNS for containers ?

https://github.com/balena-io-playground/balena-mdns-service

@MatthewCroughan
Copy link
Contributor Author

MatthewCroughan commented Nov 12, 2019

@ajlennon I linked to that github page already, it reads:
"Important: this will only work with resinOS 1.x devices! On resinOS 2.x the system comes with Avahi,"

So this is no longer functional, as I've tested and noted. Dbus rejects an in-container avahi-daemon.

The Dbus command gets some success, as it tells the host to tell Avahi to register a hostname. But I can't seem to ping it, despite top showing the fact that this has registered and worked.

The example python script in this dir is visible on avahi-browse -a but not pingable either. Although it's important to note that it is ostensibly doing the exact same thing in a more robust way https://github.com/balena-io-playground/balena-avahi-dbus

@MatthewCroughan
Copy link
Contributor Author

MatthewCroughan commented Nov 12, 2019

This seems to be the go-to utility. But it breaks using alpine since it relies on systemd, and worse means we cannot use other people's images since it uses ENV INITSYSTEM on which I thought relied upon basing everything we make upon a balenalib image.. so it's very annoying.
Anything that requires this much overhead is way too much for me, when all that should be required for our use is either that dbus script and-or the successor to the project you linked (https://github.com/balena-io-playground/balena-avahi-dbus)

@MatthewCroughan
Copy link
Contributor Author

It seems that when we use Wifi-Connect on BalenaOS 2.44+ on a Pi3, all requests for any hostname are redirected to 192.168.42.1

As weird as this is, it somewhat solves the issue we're having temporarily. ping mqtt.local will go right to 192.168.42.1, which is actually what we want. ping ahgdwayg will also be redirected to 192.168.42.1, which is strange but irrelevant.

@MatthewCroughan
Copy link
Contributor Author

It might be wise to simply have the whole device pingable at ming.local. This will save us from worrying about the per-container mDNS for now, whilst giving us a non-random usable hostname. @ajlennon I've read https://www.balena.io/docs/reference/OS/network/2.x/#setting-a-static-ip

After reading this, it implies we need to modify the sd card's boot partition to do any of this, is this true? Can we modify the hostname via the files in the git repo?

@ajlennon
Copy link
Member

ajlennon commented Dec 3, 2019

There's an API to modify the hostname yes. All a bit of a faff. I did a post on this -

https://forums.balena.io/t/a-hack-to-change-the-device-hostname/6195

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants