[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2773: `tahoe create-node` should require `--location` and/or `--hostname`, and not autodetect

[Tahoe-LAFS]

#2773: `tahoe create-node` should require `--location` and/or `--hostname`, and
not autodetect
--------------------------------+-----------------------
     Reporter:  warner          |      Owner:
         Type:  task            |     Status:  new
     Priority:  normal          |  Milestone:  undecided
    Component:  code-nodeadmin  |    Version:  1.11.0
   Resolution:                  |   Keywords:
Launchpad Bug:                  |
--------------------------------+-----------------------

Comment (by warner):

 At today's devchat, meejah and I worked something out.

 The node creation commands are responsible for writing `tub.location` and
 `tub.port` into `tahoe.cfg`, with the same semantics as we have now:
 `tub.location` is a foolscap hint list (e.g.
 "tcp:HOSTNAME:PORT,tcp:HOST2:PORT2"), and `tub.port` is a twisted server
 endpoint specifiction ("tcp:12345" or "tcp:12345:interface=127.0.0.1").
 These commands will also write information about Tor setup, when
 necessary. All allocation is finished by the time `create-node` exits, so
 nothing dynamic needs to happend at runtime (`tahoe start`).

 Then the server-like node-creation commands (`create-server`, `create-
 introducer`, and `create-node` if it means client+server) have a couple of
 different allowable cases

 * `tahoe create-server --hostname=HOST`: This allocates a TCP port (maybe
 an IANA-standardized Tahoe port, maybe just any free one), and sets
 location to `tcp:HOSTNAME:PORT` and port to `tcp:PORT`.

 * `--listen-tor`: This allocates an onion address (inside `create-server`,
 which will need to start up a reactor, maybe start a tor instance, and
 talk to Tor's control port to create the private key), then sets location
 to `tor:XYZ.onion:PORT1` and port to `tcp:PORT2:interface=127.0.01`. If
 we're able to use a unix socket for the inbound connections from tor, the
 port will be something like `unix:PATH` instead.

 * `--listen-i2p`: same, but for I2P

 * any combination of the above three

 * `--location= --port=`: This explicitly provides both the FURL connection
 hints and the listening port. `--location` and `--port` must be provided
 as a pair (both, or neither, but never just one). If they are provided,
 none of `--hostname`/`--listen-tor`/`--listen-i2p` are accepted.

 In the outbound direction, clients will automatically use Tor hints if
 possible. At node startup, they'll attempt to import txtorcon, and if that
 works, they'll register a foolscap connection handler for "tor" hints. The
 handler will provide Tor endpoints on request (synchronously). Then, when
 `.connect()` is called on one of those hints, the handler will attempt to
 spin up a Tor instance. If this fails (e.g. because Tor is not actually
 installed), the connection will fail, no big deal. Same story for i2p: try
 to import `txi2p`, if that works install the connection handler (which
 might not work), if not, don't.

 `tahoe.cfg` will have an option to *not* use Tor, for the benefit of folks
 operating in an environment where they have txtorcon and Tor installed,
 but for whatever reason don't want want Tahoe to use them. I don't think
 this is common enough to need a CLI argument: folks can just edit
 tahoe.cfg after node creation.

 The client-like node creation commands (`create-client`, maybe `create-
 node`) will then have an argument like `--only-tor` which indicates that
 all outbound TCP connections ought to route through Tor instead. It will
 also have an `--anonymous` flag that enforces restrictions on the other
 settings: it requires --only-tor, it looks at the server settings and
 complains if it sees non-onion hints in `--location` or non-localhost
 listening ports in `--port`.

 The client-like commands will also take something like `--socks-port`,
 which registers a foolscap connection handler (for both tcp and tor) that
 sends everything to the given SOCKS server. This might be a Tor instance
 (in which case both tcp:HOST:PORT and tor:XYZ.onion:PORT will work), or it
 might be a plain SOCKS daemon (so tor: won't work).

 All commands will accept `--tor-controlport=endpoint`, which means
 txtorcon ought to talk to the pre-existing Tor instance at that control
 port, rather than launching its own. This gets written into tahoe.cfg
 somehow.

 It might be a good idea to have the node creation commands, when asked to
 use tor, check to see if it will actually work. That means spinning up a
 Tor executable (or connecting to the `--tor-controlport=` provided) and
 seeing if Tor can get the full descriptor list. Maybe even making a
 connection to a tahoe-lafs.org -hosted onion service to make sure it
 works.

 And looking towards the future, meejah had a great idea about a sort of
 "setup wizard". `tahoe create-node --web` could run a server and pop open
 your web browser to a control panel. It could then run ifconfig and see if
 your box seemed to have a public IP address, or try to get a UPnP port, or
 provide instructions for setting up a firewall port-forwarding, etc. Then
 it could ask the user for permission to confirm connectivity, by having a
 service on tahoe-lafs.org connect back down to the purported address.

 In the end, we really want running a server to be as easy as running a
 client, but the networking world in which we live doesn't make that
 trivial. I think `--hostname=` is about the simplest possible tool (but
 only works if you have a public-IP VPS server of some sort), and
 `--location= --port=` is the second-simplest tool.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2773#comment:4>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage