Bug 6144 - People often forget to set agent_hostname
Summary: People often forget to set agent_hostname
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Server Installer (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Henrik Andersson
: 4228 7975 (view as bug list)
Depends on:
Reported: 2017-01-19 13:57 CET by Samuel Mannehed
Modified: 2024-02-06 16:24 CET (History)
5 users (show)

See Also:
Acceptance Criteria:


Description Samuel Mannehed cendio 2017-01-19 13:57:23 CET
One solution could be to offer to set this in tl-setup when choosing agent.
Comment 1 Samuel Mannehed cendio 2017-01-24 13:21:35 CET
Also see bug 2561.
Comment 2 Samuel Mannehed cendio 2021-11-23 13:04:56 CET
One consequence of this is that clients can't reach the agent from outside the LAN.
Comment 3 Pierre Ossman cendio 2022-06-07 16:31:03 CEST
*** Bug 4228 has been marked as a duplicate of this bug. ***
Comment 4 Pierre Ossman cendio 2022-08-15 11:22:51 CEST
*** Bug 7975 has been marked as a duplicate of this bug. ***
Comment 8 Pierre Ossman cendio 2024-02-06 16:24:38 CET
Ideas/goals of what we'd like to improve here:

The basics:

 * Inform the user about the issue, using a new page in tl-setup

 * Allow the user to configure agent_hostname directly from tl-setup

Rudimentary suggestions:

 * The machine's current ip address (just the internet facing one, or all?)

 * The machine's hostname

Rudimentary verification of suggestions, warning users if something seems unlikely to work:

 * Check if the IP address is in a public or private range

 * Check if the hostname looks like a fqdn

Once those things are in place, we could attempt more complex systems that are technically uncertain, or require external services:

 * A reverse DNS lookup of the machine's IP address, hopefully getting something that is more universally useful

 * Assuming tl-setup was started via ssh, can we get anything from ssh that tells how the machine is reached externally?

 * Contact some service on the internet and ask what our external address is

 * Query the infrastructure we're on/in, e.g. some AWS API if we're a VM, UPnP, ...

 * Look up candidate host names in DNS and check if the result is in a public or private range

 * Do the above DNS lookup with an external DNS (e.g. Google's) to get an external perspective

 * Is the hostname using a valid TLD?

 * Request an external service to attempt a connection to our candidate address

 * Ask the user to run some command from a client to attempt a connection to our candidate address

Note You need to log in before you can comment on or make changes to this bug.