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

CLI banner displays .local domain in HA URLs regardless of user-provided settings #499

Open
njbair opened this issue Jun 19, 2024 · 4 comments

Comments

@njbair
Copy link

njbair commented Jun 19, 2024

I noticed today that the welcome banner in the CLI includes two URLs to Home Assistant endpoints:

  Home Assistant URL:       http://homeassistant.local:8123
  Observer URL:             http://homeassistant.local:4357

These endpoints are hard-coded to use the .local domain, as seen here in cmd/banner.go:

cli/cmd/banner.go

Lines 167 to 168 in 8d8c11a

fmt.Printf(" %-25s %s://%s.local:%d\n", "Home Assistant URL:", protocol, (*hostinfo)["hostname"], int(port))
fmt.Printf(" %-25s http://%s.local:%d\n", "Observer URL:", (*hostinfo)["hostname"], 4357)

In my case, these URLs were not working because I had not enabled mDNS on my network.

Enabling mDNS would fix the issue on my network, but I think it would be better if HA reported the user-configured domain where possible, then gracefully fall back to .local if no domain is available.

Can anyone think of any downsides to this approach? Would there be any interest in merging a PR to make this change? Is this info even available to the CLI, or would I have to move upstream and change the Supervisor info API?

@githuballrutz
Copy link

Thank you, my network is ".lan" as provided by pi-hole. So this message from "ha banner" is missleading.

@agners
Copy link
Member

agners commented Sep 5, 2024

Enabling mDNS would fix the issue on my network, but I think it would be better if HA reported the user-configured domain where possible, then gracefully fall back to .local if no domain is available.

With user configured domain you mean the domain suffix as provided through DHCP?

This might be the better option here indeed. We kinda use mDNS as fallback since most folks have mDNS enabled and almost all platform support it out-of-the box. So it is a somewhat safe fallback.

I guess the question would be how many folks have a borked router/setting where the DHCP provided suffix ends up not working 🤔 😬

Also, technically if you have two instances with the same name, your DHCP might not allocate the domain name for you. But that problem also exists on mDNS so 🤷‍♂️ . Maybe we could even learn if that was the case from the DHCP response? 🤔

@agners
Copy link
Member

agners commented Sep 5, 2024

Hm, yeah NetworkManager actually exposes quite some information:

DHCP4.OPTION[5]:                        domain_name = lan
...
DHCP4.OPTION[8]:                        host_name = ha-virt-proxmox-dev
...
DHCP4.OPTION[12]:                       requested_domain_name = 1

I guess if we look at this information we can say with reasonably high accuracy that ha-virt-proxmox-dev.lan will work in this case.

@njbair
Copy link
Author

njbair commented Sep 5, 2024

I think you're right that those values would work in the case of DHCP-assigned hostname.

A full solution would also have to account for cases where HA has been configured with a static IP & hostname; and also perhaps cases where DHCP is used but the DHCP server doesn't provide all those values.

It seems like this logic is already present, as the settings dashboard gives the option to use an automatic local URL or override it:

image

Maybe the same result could be of use to the CLI as well?

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

3 participants