One solution could be to offer to set this in tl-setup when choosing agent.
Also see bug 2561.
One consequence of this is that clients can't reach the agent from outside the LAN.
*** Bug 4228 has been marked as a duplicate of this bug. ***
*** Bug 7975 has been marked as a duplicate of this bug. ***
Ideas/goals of what we'd like to improve here:
* Inform the user about the issue, using a new page in tl-setup
* Allow the user to configure agent_hostname directly from tl-setup
* 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