Hello,
Following my post on Flatcar Gladys Assistant and the use of Avahi to have an address “gladysbox
So does that mean a new user who installs Gladys on their new machine will be able to directly access http://gladysassistant.local without needing nmap or an IP scanner?
If so, then that’s GENIAAAAAAAAAALLLLLLLLL!
And we can close: Découverte de Gladys en automatique sur réseau local and this request.
Follow-up question: Does it work with Mac, Linux, Windows, iPhone, and Android phones?
That’s the goal. If you want to test, I’m open to feedback.
Tests performed for name resolution:
- mac: ok
- iphone: ok
- windows 11: ok
- android: I don’t have one to test
- linux: yes in a Debian VM (with Jeedom installed) and no in my Proxmox LXC containers and hosts, I must need a package to install that I don’t know.
The name modification works very well:
However, I have dedicated ports on my instances and therefore I don’t have the default 80.
This means that if you stop at xxx.local, it doesn’t work in my case.
In my Gladys discovery request, I mentioned a find.gladysassistant.com that would allow scanning of Gladys instances on the local network, a bit like Synology does when you install a new server.
Do you think it’s feasible in addition to the mDNS part?
I couldn’t find out if it was local or on the web server 
Another point, I find some redundancy between the yellow version of Gladys and the green version:
Another super cool development!
I’m going to give some feedback (constructive, of course)…
The label, I think, would be more accurate if we put ‹ Host IP › instead of just ‹ IP ›…
What do you think?
On the contrary.
At first I had put IP address but it was too long. I can try with your suggestion and take a screenshot for you.
For the version yes it’s redundant I agree
Thanks for your feedback @mutmut, I’ll look at it as soon as I can.
@GBoulvin, here you go
On Linux (LXC / Proxmox hosts)
This is expected behavior, and there’s nothing to fix on Gladys’ side: .local name resolution must be handled by the client machine, which needs an mDNS resolver. Your Debian VM with Jeedom works because an avahi-daemon is already installed (Jeedom includes it), whereas minimal LXC containers have neither Avahi nor the NSS module.
On a Debian/Ubuntu system, you usually just need to:
apt install avahi-daemon libnss-mdns
libnss-mdns adds mdns4_minimal to the hosts: line in /etc/nsswitch.conf, allowing ping, curl, and the browser to resolve gladysassistant.local. Note that in a non-privileged LXC, multicast may also be blocked by the host’s network configuration — in that case, you need to check the Proxmox firewall/bridge, not Gladys.
On dedicated ports
Good news: this is already handled, and your own capture shows it — Gladys displays http://gladysassistant-test.local:8001 and not just gladysassistant-test.local.
There are two distinct mechanisms at play:
- Gladys publishes an SRV record, which contains the hostname and the actual port. Any client doing service discovery (_http._tcp) will therefore retrieve the instance with its correct port, whatever it is.
- The A record, on the other hand, only translates xxx.local to an IP address. The DNS protocol does not allow attaching a port to it.
So typing xxx.local alone in a browser will indeed always go to port 80: this is a limitation of DNS itself, not an implementation choice, and it’s precisely the purpose of SRV. In your case, you need to use the full URL with the port, the one Gladys displays in the settings.
On find.gladysassistant.com I need to find out how this works on Synology, I don’t know it at all.
Great, thanks a lot @Will_71, I’m going to set up a clean machine to test if it works on first boot.
I had already done a POC with Windsurf and AI that worked quite well but with a very simple interface.
That’s really great @Will_71. I confirm that it works on a fresh installation.