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: 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
(In reply to Pierre Ossman from comment #8) > > * Query the infrastructure we're on/in, e.g. some AWS API if we're a VM, > UPnP, ... > Getting information from AWS seems to be trivial at least: https://stackoverflow.com/questions/38679346/get-public-ip-address-on-current-ec2-instance