[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2788: add connection-policy configuration

[Tahoe-LAFS]

#2788: add connection-policy configuration
------------------------------+-----------------------
     Reporter:  warner        |      Owner:  warner
         Type:  enhancement   |     Status:  new
     Priority:  normal        |  Milestone:  undecided
    Component:  code-network  |    Version:  1.11.0
   Resolution:                |   Keywords:
Launchpad Bug:                |
------------------------------+-----------------------

Comment (by warner):

 In reviewing the code to implement this, I'm starting to think that
 `connections.yaml` should *only* contain the per-server configuration
 (either overrides for introducer-announced servers, or complete
 information for non-Introducer locally-defined servers). And as a result,
 it should be called `servers.yaml`.

 Then `tahoe.cfg` would contain both the defaults (e.g. "use Tor to connect
 to TCP things"), and the details of how each connection type is
 implemented (e.g. "to use Tor, speak SOCKS to localhost:9050"). Neither
 one needs a lot of structure, so I don't think we need the nested
 dictionaries of YAML to control them.

 So I'm suggesting the following `tahoe.cfg` syntax:

 {{{
 [tor]
  socks.port =
  control.port =
  launch =

 [i2p]
  etc =

 [connections]
  tcp = tcp
  tor = tor
  i2p = i2p
 }}}

 The `[tor]` section is defined as in #517 (defaulting to SOCKS on
 9050/9150). The `[connections]` section maps Foolscap connection-hint type
 (or "tcp" for HTTP) to a handler. To disable a type, map it to
 "`disabled`" (which replaces the `[tor] enable = false` setting from
 #517):

 {{{
 [connections]
  tor = disabled
 }}}

 (note that any unrecognized value for a `[connections]` key will cause a
 boot-time error, which should aid discovery of the correct syntax)

 Then `servers.yaml` won't have a `global` section. It would still have a
 top-level section name (to preserve room for other sections, if we need to
 add them in the future), but I think it could be named `storage` instead
 of `servers`, to make it clear that everything below is talking about
 storage servers and not about Helpers or something else. To add a brand-
 new (non-Introducer) server, you'd populate the `announcement` clause with
 a few important keys:

 {{{
 # servers.yaml

 storage:
   v0-c2ng2pbrmxmlwpijn3mr72ckk5fmzk6uxf6nhowyosaubrt6y5mq:
     ann:
       nickname: bob
       anonymous-storage-FURL:
 pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b
       permutation-seed-base32: w2hqnbaa25yw4qgcvghl5psa3srpfgw3
 }}}

 (if you're pinning an introducer announcement, you could copy and indent
 the `ann` clause from `introducer_cache.yaml`, although you don't strictly
 need to copy all the keys:

 What should happen if the same server-id show up in both `servers.yaml`
 and an introducer announcement? We could have `servers.yaml` overlay the
 announcement data (e.g. `ann = introducer_ann.copy(); ann.update(yaml)`),
 which would let you override specific properties. But I can't think of any
 good use for that. I think it might be better to log an error when the
 announcement shows up. Since this log won't be very discoverable, it'd be
 a good idea to record the fact that an announcement appeared, and display
 a note on the relevant WUI page ("warning: announcement received (and
 ignored) for static server, see logs for details").

 Note that synthetic servers don't need a real server-id, and announcements
 are only accepted if they're signed, and the public verification key *is*
 the the server-id. So if you make up a server-id, there's no way for an
 announcement to ever overlap:

 {{{
 storage:
   my-serverid-1:
     ann:
       nickname: my-server-1
       anonymous-storage-FURL:
 pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b
       permutation-seed-base32: w2hqnbaa25yw4qgcvghl5psa3srpfgw3
 }}}


 Each storage server has an implicit `connections` section, which is filled
 with the settings from `tahoe.cfg [connections]`. To handle Leif's use-
 case of a TCP-enabled server on a otherwise-Tor-restricted client, you'll
 need to override `connections`, to replace the `tcp: tor` mapping with
 `tcp: tcp`:

 `tahoe.cfg`:

 {{{
 [node]
  anonymous = true
 [connections]
  # this forces the use of Tor for all tcp hints
  tcp = tor
 }}}

 `servers.yaml`:
 {{{
 storage:
   my-serverid-1:
     ann:
       nickname: my-server-1
       anonymous-storage-FURL:
 pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b
       permutation-seed-base32: w2hqnbaa25yw4qgcvghl5psa3srpfgw3
     connections: # overrides global mapping
       tcp: tcp
 }}}

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