removing IP-address autodetection, Tor integration

[Brian Warner]

On 6/18/15 2:56 PM, David Stainton wrote:
> What would happen if the foolscap transport plugin state directory was
> removed but the tahoe.cfg config file remained intact?

With the implementation I'd been considering, it would basically just
re-generate the listener. If that resulted in a different connection
hint, things would probably break. I guess that's a problem :).

> In that error case when the Tor-Foolscap plugin is used, the correct
> behavior would be to exit with an error telling the user that the
> Tahoe-LAFS configuration file expresses the desire to advertise a
> particular onion address but the key material to do so is not present.
> Too bad!

To clean up the Tahoe startup process, we don't get to learn the current
connection hints until some time after node startup. So we couldn't
throw an error while the Node object is being constructed, or during
startService, but rather a little bit later. I'd really like to throw
these errors while 'tahoe start' is still running. (one possibility is
to have 'tahoe start' watch the newly-launched process for a little
while, and not exit until it gets a signal that says "everything is
cool".. I did this for Buildbot a decade ago, but it requires some
annoying coordination between multiple processes, and frequently times
out).

> Should we have some sort of "reset-advertised-endpoint" command line
> tool? It would make it possible to recompute the advertised name based
> on new input for a dynamic server endpoint (e.g. tcp:0 or onion:80);
> and it writes the resulting new client side endpoint descriptor string
> to the tub.location section of the tahoe.cfg.

Yeah, another situation is that somebody's just modified the tub.listen
string in their tahoe.cfg, and didn't modify the tub.location to match.
Having an external tool would help us maintain our position that the
running node should not modify tahoe.cfg itself (but it's ok if a tahoe
CLI command does). But having too like that sounds a little weird. Maybe
it'd be ok if the tool just accepted the same --listen= and --advertise=
arguments that 'tahoe create-node' did (i.e. instead of telling users to
modify tahoe.cfg and then run the tool, we tell them to just run the
tool, and the tool will write both strings into tahoe.cfg, just like
create-node did except it doesn't create a brand-new node).

cheers,
 -Brian