Bug 2561 - IP address isn't always the best fallback for /vsmagent/agent_hostname
Summary: IP address isn't always the best fallback for /vsmagent/agent_hostname
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Agent (show other bugs)
Version: trunk
Hardware: PC Linux
: P2 Normal
Target Milestone: LowPrio
Assignee: Bugzilla mail exporter
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-29 11:23 CET by Erik Forsberg
Modified: 2023-08-23 13:16 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Erik Forsberg cendio 2007-10-29 11:23:48 CET 
Currently, an unset /vsmagent/agent_hostname results in the agent calculating the value by trying to connect to an IP address, then asking the socket module which address was used as outgoing address. This has served us well.

However, for split-DNS sites, there is still the need to set /vsmagent/agent_hostname to the hostname available in DNS, which means vsmagent.hconf has to be unique on a per-agent basis.

Being able to tell VSM Agent that it should send the fully qualified hostname of the machine as agent_hostname, would allow administrators to set the FQDN of the machine to the hostname available in both internal and external DNS, and have the same vsmagent.hconf on all agents.
Comment 1 Peter Åstrand cendio 2013-05-07 09:22:22 CEST 
As I interpret this bug, it's unclear if the suggested solution should be an agent side or master side solution. One idea is to do this on the agent side, for example by allowing you to set some "special" value in the agent_hostname parameter, such as $HOSTNAME. To make this a generic feature, we could allow environment variable expansion. 

OTOH, it may be that $HOSTNAME (and `hostname`) does not give you what you want. For example, consider our EU demo system where `hostname` is bard.thinlinc.com, but we want to report eudemo.thinlinc.com. 

One solution, although not automatic, is to use separate config files:

* Comment out agent_hostname from vsmagent.hconf

* Create a new config file local.hconf with:

[/vsmagent]
agent_hostname=eudemo.thinlinc.com
Comment 2 Samuel Mannehed cendio 2017-01-24 13:21:54 CET 
Also see bug 6144.
Comment 3 Pierre Ossman cendio 2023-02-10 10:25:52 CET 
Ideally, the agent can automatically determine if $HOSTNAME is useful or not. It could then prefer that over the IP address by default.

As an approximation of "useful", we could check that it is in DNS. Hopefully, that means that it is not just something set locally, and, hopefully, that also means the clients can resolve it.

The problem is that getaddrinfo() doesn't just use DNS. It also talks to systemd, which will always respond with the local IP address for $HOSTNAME.

We could talk to DNS ourselves. That is messy, though. Especially if we want to consider respecting everything in /etc/resolv.conf.

Perhaps we can use glibc's resolver API? I.e. res_nquery() and friends. It doesn't seem to be accessible from Python. But we could use ctypes? Or have a helper program?
Comment 4 Pierre Ossman cendio 2023-08-23 13:16:54 CEST 
We could also try to figure out the public address automatically, in case the system is behind NAT. The most popular protocol for this is STUN.

This would likely give us just an IP address, but we could either use that, or do a reverse lookup on the address.

A problem here is that it requires some server for us to talk to so that it can report back what address it sees on our connection. There doesn't seem to be an obvious choice for that.

I did find this service, though:

https://www.ipify.org/

It's not STUN, but it would do what we need.

We could also run some service ourselves that does what we require.


A big concern with this approach is the privacy aspect. It would expose some form of tracking of ThinLinc servers for the service used. So it would likely need to be explicitly opt-in.
Note You need to log in before you can comment on or make changes to this bug.