add connection-policy configuration #2788

New issue

Closed

opened 2016-05-11 23:56:46 +00:00 by warner · 29 comments

warner commented

2016-05-11 23:56:46 +00:00

This ticket is for implementing the cache/reuse/override scheme described in #2759 (but that ticket is specifically about multiple Tubs, which is already done).

Here are the relevant ideas, copied from #2759:

this relates to #68 multi-introducer, and #517 server-override
store each introducer's data is written into a cache file (YAML-format, with one clause per server)
there is also an override file, which contains YAML clauses of server data that should be used instead-of/in-addition-to the data received from the introducer
the StorageFarmBroker, when deciding how to contact a server, combines data from all introducers, then updates that dict with data from the override file

workflow:

start up the node normally, wait for the introducers to collect announcements
copy the cached clauses for his local servers into the override file
edit the override file to modify the FURL to use a direct "tcp:HOST:PORT" hint, instead of the "tor:XYZ.onion:80" hint that they advertised

So our idea was that each YAML clause has two chunks of data: one local, one copied from the introducer announcement. The local data should include a string of some form that specifies the properties of the Tub that should be used for connections to this server. The StorageFarmBroker will spin up a new Tub for each connection, configure it according to those properties, then call getReference() (actually connectTo(), to get the reconnect-on-drop behavior).

The tahoe.cfg settings for foolscap connection-hint handlers get written into the cached introducer data. StorageFarmBroker creates Tubs that obey those rules because those rules are sitting next to the announcement that will contain the FURL.

This ticket is for implementing the cache/reuse/override scheme described in #2759 (but that ticket is specifically about multiple Tubs, which is already done). Here are the relevant ideas, copied from #2759: * this relates to #68 multi-introducer, and #517 server-override * store each introducer's data is written into a cache file (YAML-format, with one clause per server) * there is also an override file, which contains YAML clauses of server data that should be used instead-of/in-addition-to the data received from the introducer * the StorageFarmBroker, when deciding how to contact a server, combines data from all introducers, then updates that dict with data from the override file workflow: * start up the node normally, wait for the introducers to collect announcements * copy the cached clauses for his local servers into the override file * edit the override file to modify the FURL to use a direct "tcp:HOST:PORT" hint, instead of the "tor:XYZ.onion:80" hint that they advertised So our idea was that each YAML clause has two chunks of data: one local, one copied from the introducer announcement. The local data should include a string of some form that specifies the properties of the Tub that should be used for connections to this server. The StorageFarmBroker will spin up a new Tub for each connection, configure it according to those properties, then call getReference() (actually connectTo(), to get the reconnect-on-drop behavior). The tahoe.cfg settings for foolscap connection-hint handlers get written into the cached introducer data. StorageFarmBroker creates Tubs that obey those rules because those rules are sitting next to the announcement that will contain the FURL.

warner added the

labels 2016-05-11 23:56:46 +00:00

warner added this to the undecided milestone 2016-05-11 23:56:46 +00:00

warner commented

2016-05-12 00:07:35 +00:00

Author

Current status: reviewing https://github.com/tahoe-lafs/tahoe-lafs/pull/281 . Then we'll look at https://github.com/david415/tahoe-lafs/tree/2759.add_connections_yaml_config.0 .

Current status: reviewing <https://github.com/tahoe-lafs/tahoe-lafs/pull/281> . Then we'll look at <https://github.com/david415/tahoe-lafs/tree/2759.add_connections_yaml_config.0> .

warner commented

2016-05-12 00:10:36 +00:00

Author

In testing out PR281, I noticed that the yaml.dump() is emitting some pretty horrible-looking YAML, because of the preponderance of unicode strings in our announcements (which comes from the fact that we're shipping around JSON, in which everything is unicode). One test node I looked at had a NODEDIR/private/introducer_cache.yaml with entries like:

- ann:
    !!python/unicode 'anonymous-storage-FURL': !!python/unicode 'pb://w2hqnbaa25yw4qgcvghl5psa3srpfgw3@tcp:127.0.0.1:51309,tcp:10.0.1.43:51309,tcp:10.0.1.57:51309/vucto2z4fxment3vfxbqecblbf6zyp6x'
    !!python/unicode 'app-versions': {!!python/unicode 'Nevow': !!python/unicode '0.14.0',
      !!python/unicode 'OpenSSL': !!python/unicode '1.0.2h', !!python/unicode 'PyYAML': !!python/unicode '3.11',
      !!python/unicode 'Twisted': !!python/unicode '16.1.1', !!python/unicode 'attrs': !!python/unicode '15.2.0',
      !!python/unicode 'cffi': !!python/unicode '1.6.0', !!python/unicode 'characteristic': !!python/unicode '14.3.0',
      !!python/unicode 'cryptography': !!python/unicode '1.3.2', !!python/unicode 'enum34': !!python/unicode '1.1.5',
      !!python/unicode 'foolscap': !!python/unicode '0.11.0', !!python/unicode 'idna': !!python/unicode '2.1',
      !!python/unicode 'ipaddress': !!python/unicode '1.0.16', !!python/unicode 'platform': !!python/unicode 'Darwin-15.4.0-x86_64-i386-64bit',
      !!python/unicode 'pyOpenSSL': !!python/unicode '16.0.0', !!python/unicode 'pyasn1': !!python/unicode '0.1.9',
      !!python/unicode 'pyasn1-modules': !!python/unicode '0.0.8', !!python/unicode 'pycparser': !!python/unicode '2.14',
      !!python/unicode 'pycrypto': !!python/unicode '2.6.1', !!python/unicode 'pycryptopp': !!python/unicode '0.7.1.869544967005693312591928092448767568728501330214',
      !!python/unicode 'python': !!python/unicode '2.7.11', !!python/unicode 'service-identity': !!python/unicode '16.0.0',
      !!python/unicode 'setuptools': !!python/unicode '21.0.0', !!python/unicode 'simplejson': !!python/unicode '3.8.2',
      !!python/unicode 'six': !!python/unicode '1.10.0', !!python/unicode 'tahoe-lafs': !!python/unicode '1.11.0.post96.dev0',
      !!python/unicode 'twisted': !!python/unicode '16.1.1', !!python/unicode 'zfec': !!python/unicode '1.4.24',
      !!python/unicode 'zope.interface': !!python/unicode 'unknown'}
    !!python/unicode 'my-version': !!python/unicode 'tahoe-lafs/1.11.0.post96.dev0'
    !!python/unicode 'nickname': !!python/unicode 'node-4'
    !!python/unicode 'nonce': !!python/unicode 'ig7y65ufqcopdq3pul5efixhtf7kqw2i33sp3pxsifryw5gvm27a'
    !!python/unicode 'oldest-supported': !!python/unicode '1.0.0'
    !!python/unicode 'permutation-seed-base32': !!python/unicode 'w2hqnbaa25yw4qgcvghl5psa3srpfgw3'
    !!python/unicode 'seqnum': 53
    !!python/unicode 'service-name': !!python/unicode 'storage'
    !!python/unicode 'version': 0
  key_s: v0-o5vaij77fgdsj5npijjq3gydm6cbblspirkjqcxh44qvrtyp2moa

That's.. pretty ugly, and I'm not sure I'd want to ask someone to copy/edit/paste it into an override file.

I'm wondering if we should move to JSON instead (with indent=1 on the output so we get newlines and indentation). It's not entirely human-friendly, but it wouldn't treat unicode as something magical.

I noticed that if we used yaml.safe_dump() to write the file, intead of yaml.dump(), then both unicode and bytes get written out as normal strings (without the !!python/unicode mess). When parsed with yaml.safe_load() (or unsafe yaml.load()), these come back as either bytes or unicode (probably depending upon whether it can be represented as ASCII or not). That's not ideal (I wish it would be consistently unicode), but it'd be easier to work with than the !!python/unicode things.

In testing out PR281, I noticed that the `yaml.dump()` is emitting some pretty horrible-looking YAML, because of the preponderance of unicode strings in our announcements (which comes from the fact that we're shipping around JSON, in which everything is unicode). One test node I looked at had a `NODEDIR/private/introducer_cache.yaml` with entries like: ``` - ann: !!python/unicode 'anonymous-storage-FURL': !!python/unicode 'pb://w2hqnbaa25yw4qgcvghl5psa3srpfgw3@tcp:127.0.0.1:51309,tcp:10.0.1.43:51309,tcp:10.0.1.57:51309/vucto2z4fxment3vfxbqecblbf6zyp6x' !!python/unicode 'app-versions': {!!python/unicode 'Nevow': !!python/unicode '0.14.0', !!python/unicode 'OpenSSL': !!python/unicode '1.0.2h', !!python/unicode 'PyYAML': !!python/unicode '3.11', !!python/unicode 'Twisted': !!python/unicode '16.1.1', !!python/unicode 'attrs': !!python/unicode '15.2.0', !!python/unicode 'cffi': !!python/unicode '1.6.0', !!python/unicode 'characteristic': !!python/unicode '14.3.0', !!python/unicode 'cryptography': !!python/unicode '1.3.2', !!python/unicode 'enum34': !!python/unicode '1.1.5', !!python/unicode 'foolscap': !!python/unicode '0.11.0', !!python/unicode 'idna': !!python/unicode '2.1', !!python/unicode 'ipaddress': !!python/unicode '1.0.16', !!python/unicode 'platform': !!python/unicode 'Darwin-15.4.0-x86_64-i386-64bit', !!python/unicode 'pyOpenSSL': !!python/unicode '16.0.0', !!python/unicode 'pyasn1': !!python/unicode '0.1.9', !!python/unicode 'pyasn1-modules': !!python/unicode '0.0.8', !!python/unicode 'pycparser': !!python/unicode '2.14', !!python/unicode 'pycrypto': !!python/unicode '2.6.1', !!python/unicode 'pycryptopp': !!python/unicode '0.7.1.869544967005693312591928092448767568728501330214', !!python/unicode 'python': !!python/unicode '2.7.11', !!python/unicode 'service-identity': !!python/unicode '16.0.0', !!python/unicode 'setuptools': !!python/unicode '21.0.0', !!python/unicode 'simplejson': !!python/unicode '3.8.2', !!python/unicode 'six': !!python/unicode '1.10.0', !!python/unicode 'tahoe-lafs': !!python/unicode '1.11.0.post96.dev0', !!python/unicode 'twisted': !!python/unicode '16.1.1', !!python/unicode 'zfec': !!python/unicode '1.4.24', !!python/unicode 'zope.interface': !!python/unicode 'unknown'} !!python/unicode 'my-version': !!python/unicode 'tahoe-lafs/1.11.0.post96.dev0' !!python/unicode 'nickname': !!python/unicode 'node-4' !!python/unicode 'nonce': !!python/unicode 'ig7y65ufqcopdq3pul5efixhtf7kqw2i33sp3pxsifryw5gvm27a' !!python/unicode 'oldest-supported': !!python/unicode '1.0.0' !!python/unicode 'permutation-seed-base32': !!python/unicode 'w2hqnbaa25yw4qgcvghl5psa3srpfgw3' !!python/unicode 'seqnum': 53 !!python/unicode 'service-name': !!python/unicode 'storage' !!python/unicode 'version': 0 key_s: v0-o5vaij77fgdsj5npijjq3gydm6cbblspirkjqcxh44qvrtyp2moa ``` That's.. pretty ugly, and I'm not sure I'd want to ask someone to copy/edit/paste it into an override file. I'm wondering if we should move to JSON instead (with `indent=1` on the output so we get newlines and indentation). It's not entirely human-friendly, but it wouldn't treat unicode as something magical. I noticed that if we used `yaml.safe_dump()` to write the file, intead of `yaml.dump()`, then both unicode and bytes get written out as normal strings (without the `!!python/unicode` mess). When parsed with `yaml.safe_load()` (or unsafe `yaml.load()`), these come back as either bytes or unicode (probably depending upon whether it can be represented as ASCII or not). That's not ideal (I wish it would be consistently unicode), but it'd be easier to work with than the `!!python/unicode` things.

warner commented

2016-05-12 01:07:39 +00:00

Author

I'm changing the PR281 branch to use safe_dump(), to avoid this. Thanks to dstufft, I'm also modifying the loading side to always give us unicode strings, to match what we wrote out.

In the longer run, I'm still thinking about JSON instead of YAML. On IRC, dstufft and simpson were in favor of JSON for machine-written files, but either YAML or TOML for files written by humans. (He said that Python is likely to be using TOML in the future, and !Rust/Cargo already does).

What about this: the cache could be in JSON, but the override file could be in YAML or TOML? I think we're only going to be putting three things in the override file (serverid as the key, FURL and connection-policy as the values), so it might not be necessary to copy-and-paste stuff from one to the other very much, and YAML/TOML is certainly easier to edit than JSON.

I'm changing the PR281 branch to use `safe_dump()`, to avoid this. Thanks to dstufft, I'm also modifying the loading side to always give us unicode strings, to match what we wrote out. In the longer run, I'm still thinking about JSON instead of YAML. On IRC, dstufft and simpson were in favor of JSON for machine-written files, but either YAML or TOML for files written by humans. (He said that Python is likely to be using TOML in the future, and !Rust/Cargo already does). What about this: the cache could be in JSON, but the override file could be in YAML or TOML? I think we're only going to be putting three things in the override file (serverid as the key, FURL and connection-policy as the values), so it might not be necessary to copy-and-paste stuff from one to the other very much, and YAML/TOML is certainly easier to edit than JSON.

Brian Warner <warner@lothar.com> commented

2016-05-12 01:32:25 +00:00

Owner

In 73b08d2/trunk:

Merge pr281: load YAML cache when connection fails

refs ticket:2788

In [73b08d2/trunk](/tahoe-lafs/trac/commit/73b08d2a54a8c564127986f8b4b444456987fa46): ``` Merge pr281: load YAML cache when connection fails refs ticket:2788 ```

warner commented

2016-05-12 01:37:45 +00:00

Author

The distutils-sig folks did a review of various structured-data file formats, in https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f , which makes for interesting reading.

The distutils-sig folks did a review of various structured-data file formats, in <https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f> , which makes for interesting reading.

david415 commented

2016-05-17 15:12:13 +00:00

here's the step 1 of the connections.yaml file:

https://github.com/tahoe-lafs/tahoe-lafs/pull/283

Daira has reviewed it. I committed a fix. What's next?

step 2 of the connections.yaml will include multiple introducers.
step 3 allow specification of transport plugins in various scopes; per server, per introducer and globally scoped.

here's the step 1 of the connections.yaml file: <https://github.com/tahoe-lafs/tahoe-lafs/pull/283> Daira has reviewed it. I committed a fix. What's next? step 2 of the connections.yaml will include multiple introducers. step 3 allow specification of transport plugins in various scopes; per server, per introducer and globally scoped.

warner commented

2016-05-17 22:05:52 +00:00

Author

Updating ticket title: this ticket is now the right place for connections.yaml stuff, and using the cache is just a minor part of that effort.

We spent most of today's devchat exploring syntax options for the "connection policy configuration file", aka connections.yaml.

We're still not entirely sure what to call it. connections.yaml? policy.yaml? config.yaml? We're also not sure about using YAML at all. We did decide that we like the nested-dictionary aspect of YAML, but we're leery of the gotchas that YAML offers (like strings vs identifiers vs booleans vs numbers, where some things are quoted and others are not). I'd still like to evaluate TOML for this, but I don't know if it does nested dictionaries nicely.

But we did come up with syntax ideas that seem pretty good.

Introducers

First off: introducers. The introducers: section would map introducer nickname to FURL:

introducers:
    intro_nick1:
      furl: pb://u33m4y7klhz3bypswqkozwetvabelhxt@tor:abcdef.onion:80/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b
    intro_nick2:
      furl: pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:example.org:12345/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b

The nickname is used to name the cache file. The introducer.furl from tahoe.cfg is also used (if any), and it gets some default-ish nickname like introducer.

If someone really convinces us, we could add connection-policy clauses (described below). But in the devchat we couldn't think of a use case where you'd want different policies for connecting to different introducers. And you can already influence the connection by just editing the FURL to change the hint types.

We also agreed that having different connection policies for the servers you learned from one introducer versus another was not likely to be a good idea (as in, "every server I learn from introducer A should get Tor-ified, but I'll make direct TCP connections to servers I meet through introducer B). Especially when dawuud pointed out that you might learn about the same storage server from two different introducers, in which case you'd have to figure out how to reconcile their two policies. But if you really wanted to do this, you could have another policy stanza under each introducer section, somehow named to make it clear that you're talking about servers learned through the introducer, rather than how you talk to the introducer itself.

"Introducerless mode" means tahoe.cfg has an empty introducer.furl=, and there is no introducers: section in the YAML file. "Multi-introducer mode" means there are two or more introducers among tahoe.cfg and introducers:.

Connection Policy

Now the global connection policy section. This tells Tahoe what to do when asked to make connections (to Foolscap connection hints now, later to HTTP things). For each type of connection hint, the policy file specifies a "handler" and some arguments. The default values are something like:

global:
  connection_types:
    tcp:
      handler: tcp
    tor:
      handler: tor
      launch_my_own_tor: true

(We aren't sure this should be in a "global" section.. maybe the "connection_types" string should be at the top level. Also we aren't sure that it should be spelled "connection_types": maybe "connections" or "foolscap_connections" or something shorter)

The tcp: section controls what happens when a FURL wants you to connect via plain TCP (because the connection hint looks like tcp:example.org:1234). The handler: tcp goes to a lookup table that tells Tahoe to use a foolscap connection handler that uses plain TCP. In the future, handler: xyz could ask the setuptools/twisted/zope.interface plugin system for a module that has registered itself with the name "xyz" (and to handle some specific Interface).

The tor: section handles connection hints like tor:abcxyz.onion:80. The tor handler would probably live in the Tahoe source tree (for now), and would try to import txtorcon (and log+ignore if it couldn't be imported). The keys under tor: that aren't "handler" are passed as keyword arguments into the plugin. In this case, we're telling the tor-for-foolscap plugin that it's expected to launch it's own copy of the Tor daemon. Other options would be like control_endpoint: tcp:localhost:9051, to use a pre-running system Tor daemon.

(question: we originally discussed:

    tor:
      handler: tor
      args:
        control_endpoint: tcp:localhost:9051

with the extra args: because we originally thought handler: would be a fully-qualified import+funcname string, like what setuptools entrypoint specifications do. In that case, args would be passed as keyword arguments to the referenced callable. But with handler: being an index instead, we could probably be a bit more flexible about how arguments are passed. Also having the args at the same level as handler: is a bit cleaner. Maybe we should just pass the entire dictionary into the plugin and let it ignore handler: itself)

For nodes that are configured to use Tor instead of plain TCP, there would be two nearly-identical sections, one for tcp: and one for tor:, both specifying the "tor" handler:

global:
  connection_types:
    tcp:
      handler: tor
      launch_my_own_tor: true
    tor:
      handler: tor
      launch_my_own_tor: true

Note that any connection hint type not listed here would be ignored, to avoid the possibility of a new future connection type accidentally violating anonymity. Or maybe we only do that if anonymous=1 is set.

We can also imagine:

    tcp:
      handler: socks
        socks_endpoint: tcp:localhost:9050

Server Overrides and New Servers

The servers: clause would serve two purposes. The first is to provide data on brand new (synthetic) servers, ones that might not be advertised through any introducer. This would mostly be used for the "introducerless" mode, but could also be used augment the regular introducer-based grid with a private server for just your own client.

The second is to modify data about introducer-advertised servers, generally their connection policy and/or FURL. The following example would allow a private TCP-based server on a mostly-Tor grid (where the global policy says tcp should go to tor).

servers: # storage servers only, not hypothetical other kinds of servers
    "v0-c2ng2pbrmxmlwpijn3mr72ckk5fmzk6uxf6nhowyosaubrt6y5mq": # does this need quotes?
      nickname: foo # mainly for brand-new-servers, not for overriding
      anonymous-storage-FURL: pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b
      permutation-seed-base32: w2hqnbaa25yw4qgcvghl5psa3srpfgw3 # maybe default to pubkey
      connection_types: # replaces global mapping
        tcp:
          handler: tcp

The dictionary key is the server identity key (an !Ed25519 public verifying key, currently used as the main index for introducer announcements). (we need to experiment to see if YAML can have hyphens or non-identifier characters in dictionary keys; we'd rather not put quotes around the string if we can avoid it).

Many of the other keys would replace or augment the data heard from the introducer. "nickname" is published by servers themselves, but could be overridden locally, in which case it would behave more like a pet name. anonymous-storage-FURL is the current way that clients connect to storage servers, although that will change when #666 Accounting happens (probably to accounting-storage-FURL or similar), and storage-URL will happen when we move to an HTTP-based storage protocol. permutation-seed-base32 is important for compatibility of share placement for older servers, but I think newer servers default to using the !Ed25519 pubkey for this, so it could maybe be omitted for synthetic servers.

And then the connection_types section would control the connection policy. The idea is that each server (the allmydata.storage_client.NativeStorageServer instance) will use the connection policy from the servers[$SERVERID]connection_types dict if that's present, else it will fall back to the globalconnection_types config.

We must be careful to prevent servers from publishing connection_types: themselves. We originally thought of putting the server-provided keys in one place, and the locally-specified keys in another, like:

servers:
    v0-c2ng2pbrmxmlwpijn3mr72ckk5fmzk6uxf6nhowyosaubrt6y5mq:
      announcement:
        nickname: foo
        anonymous-storage-FURL: pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b
      connection_types:
        tcp:
          handler: tcp

but it felt too verbose. Without the separate announcement: section, the code should probably first check for connection_types, then overlay the announcement with all remaining keys:

  ct = servers[serverid].get("connection_types", global["connection_types"])
  ann = announcement.copy()
  for key,value in servers[serverid]:
    if key not in ["connection_types"]:
      ann[key] = value

The introducer announcement includes a lot of additional data that isn't very useful to override: version strings, sequence numbers, a "nonce" that I don't even remember the purpose of. While it might be useful to allow the YAML file to override any possible announcement key, it might be better to throw an error if we see any unknown key, or a key that doesn't make sense to override.

Finally, note that the Introducer was designed to let you publish more than just storage servers: each announcement includes a service-name field, and we originally planned to advertise Helpers, repairers, and even extra introducers through these announcements. The client only subscribes to storage, and we don't have any code to publish anything else. For brevity, we'll probably declare that the YAML file's servers: section is only referring to storage servers. If some future version of tahoe adds a new thing that we really want to call a "server" but which isn't a storage server, we'll have to come up with a new YAML section to describe it. Or, we could change the YAML section from servers: to storage: or storage-servers: or something.

Accidentally Introducing A New Config-File Format

We know that we'd like to eventually move away from the INI-format tahoe.cfg file, for two reasons. The first is that it doesn't really support structured data (the original multi-introducer syntax would have needed lines like introducer.furl1= and introducer.furl2=, since INI doesn't have lists). The second is that it'd be nice to safely machine-edit the config file.

In Petmail, I've been experimenting with keeping all state in a SQLite database (config, runtime updates, user messages, everything). Config changes are done with CLI tools, or a web-based wizard-thing that gets to write changes as you click the boxes. While it's sad to not be able to point emacs at the file, you win transactional changes, schema enforcement, and no data-killing race conditions between user edits and program changes.

We talked a week or two ago about a tahoe configure command which could ask you some questions ("should we offer storage? you have X GB, how much should I use?") walk you through the setup process, examine your network situation ("it looks like you're behind NAT. Do you know what port-forwarding is? Let me test your setup. Great, we can be reached from the outside, enabling server."), sanity-check the config, then start the node. To re-run this tool inside a running node, we'd need the ability to safely modify the config file after startup.

So I just want to avoid accidentally moving us to a YAML-based config file, if maybe we should be deliberately moving to an SQLite-based one. This YAML syntax is kind of nice, I can imagine moving other tahoe.cfg items over to it (eventually deprecating tahoe.cfg and automatically converting it to YAML at startup). But if we're going to do that, we should probably be intentional about it.

Updating ticket title: this ticket is now the right place for connections.yaml stuff, and using the cache is just a minor part of that effort. We spent most of today's devchat exploring syntax options for the "connection policy configuration file", aka connections.yaml. We're still not entirely sure what to call it. `connections.yaml`? `policy.yaml`? `config.yaml`? We're also not sure about using YAML at all. We did decide that we like the nested-dictionary aspect of YAML, but we're leery of the gotchas that YAML offers (like strings vs identifiers vs booleans vs numbers, where some things are quoted and others are not). I'd still like to evaluate TOML for this, but I don't know if it does nested dictionaries nicely. But we did come up with syntax ideas that seem pretty good. ## Introducers First off: introducers. The `introducers:` section would map introducer nickname to FURL: ``` introducers: intro_nick1: furl: pb://u33m4y7klhz3bypswqkozwetvabelhxt@tor:abcdef.onion:80/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b intro_nick2: furl: pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:example.org:12345/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b ``` The nickname is used to name the cache file. The introducer.furl from `tahoe.cfg` is also used (if any), and it gets some default-ish nickname like `introducer`. If someone really convinces us, we could add connection-policy clauses (described below). But in the devchat we couldn't think of a use case where you'd want different policies for connecting to different introducers. And you can already influence the connection by just editing the FURL to change the hint types. We also agreed that having different connection policies for the servers you learned from one introducer versus another was not likely to be a good idea (as in, "every server I learn from introducer A should get Tor-ified, but I'll make direct TCP connections to servers I meet through introducer B). Especially when dawuud pointed out that you might learn about the same storage server from two different introducers, in which case you'd have to figure out how to reconcile their two policies. But if you really wanted to do this, you could have another policy stanza under each introducer section, somehow named to make it clear that you're talking about servers learned *through* the introducer, rather than how you talk to the introducer itself. "Introducerless mode" means `tahoe.cfg` has an empty `introducer.furl=`, and there is no `introducers:` section in the YAML file. "Multi-introducer mode" means there are two or more introducers among tahoe.cfg and `introducers:`. ## Connection Policy Now the global connection policy section. This tells Tahoe what to do when asked to make connections (to Foolscap connection hints now, later to HTTP things). For each type of connection hint, the policy file specifies a "handler" and some arguments. The default values are something like: ``` global: connection_types: tcp: handler: tcp tor: handler: tor launch_my_own_tor: true ``` (We aren't sure this should be in a "global" section.. maybe the "connection_types" string should be at the top level. Also we aren't sure that it should be spelled "connection_types": maybe "connections" or "foolscap_connections" or something shorter) The `tcp:` section controls what happens when a FURL wants you to connect via plain TCP (because the connection hint looks like `tcp:example.org:1234`). The `handler: tcp` goes to a lookup table that tells Tahoe to use a foolscap connection handler that uses plain TCP. In the future, `handler: xyz` could ask the setuptools/twisted/zope.interface plugin system for a module that has registered itself with the name "xyz" (and to handle some specific Interface). The `tor:` section handles connection hints like `tor:abcxyz.onion:80`. The `tor` handler would probably live in the Tahoe source tree (for now), and would try to import txtorcon (and log+ignore if it couldn't be imported). The keys under `tor:` that aren't "handler" are passed as keyword arguments into the plugin. In this case, we're telling the tor-for-foolscap plugin that it's expected to launch it's own copy of the Tor daemon. Other options would be like `control_endpoint: tcp:localhost:9051`, to use a pre-running system Tor daemon. (question: we originally discussed: ``` tor: handler: tor args: control_endpoint: tcp:localhost:9051 ``` with the extra `args:` because we originally thought `handler:` would be a fully-qualified import+funcname string, like what setuptools entrypoint specifications do. In that case, `args` would be passed as keyword arguments to the referenced callable. But with `handler:` being an index instead, we could probably be a bit more flexible about how arguments are passed. Also having the args at the same level as `handler:` is a bit cleaner. Maybe we should just pass the entire dictionary into the plugin and let it ignore `handler:` itself) For nodes that are configured to use Tor instead of plain TCP, there would be two nearly-identical sections, one for `tcp:` and one for `tor:`, both specifying the "tor" handler: ``` global: connection_types: tcp: handler: tor launch_my_own_tor: true tor: handler: tor launch_my_own_tor: true ``` Note that any connection hint type *not* listed here would be ignored, to avoid the possibility of a new future connection type accidentally violating anonymity. Or maybe we only do that if `anonymous=1` is set. We can also imagine: ``` tcp: handler: socks socks_endpoint: tcp:localhost:9050 ``` ## Server Overrides and New Servers The `servers:` clause would serve two purposes. The first is to provide data on brand new (synthetic) servers, ones that might not be advertised through any introducer. This would mostly be used for the "introducerless" mode, but could also be used augment the regular introducer-based grid with a private server for just your own client. The second is to modify data about introducer-advertised servers, generally their connection policy and/or FURL. The following example would allow a private TCP-based server on a mostly-Tor grid (where the global policy says tcp should go to tor). ``` servers: # storage servers only, not hypothetical other kinds of servers "v0-c2ng2pbrmxmlwpijn3mr72ckk5fmzk6uxf6nhowyosaubrt6y5mq": # does this need quotes? nickname: foo # mainly for brand-new-servers, not for overriding anonymous-storage-FURL: pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b permutation-seed-base32: w2hqnbaa25yw4qgcvghl5psa3srpfgw3 # maybe default to pubkey connection_types: # replaces global mapping tcp: handler: tcp ``` The dictionary key is the server identity key (an !Ed25519 public verifying key, currently used as the main index for introducer announcements). (we need to experiment to see if YAML can have hyphens or non-identifier characters in dictionary keys; we'd rather not put quotes around the string if we can avoid it). Many of the other keys would replace or augment the data heard from the introducer. "nickname" is published by servers themselves, but could be overridden locally, in which case it would behave more like a pet name. `anonymous-storage-FURL` is the current way that clients connect to storage servers, although that will change when #666 Accounting happens (probably to `accounting-storage-FURL` or similar), and `storage-URL` will happen when we move to an HTTP-based storage protocol. `permutation-seed-base32` is important for compatibility of share placement for older servers, but I think newer servers default to using the !Ed25519 pubkey for this, so it could maybe be omitted for synthetic servers. And then the `connection_types` section would control the connection policy. The idea is that each server (the `allmydata.storage_client.NativeStorageServer` instance) will use the connection policy from the `servers[$SERVERID]connection_types` dict if that's present, else it will fall back to the `globalconnection_types` config. We must be careful to prevent servers from publishing `connection_types:` themselves. We originally thought of putting the server-provided keys in one place, and the locally-specified keys in another, like: ``` servers: v0-c2ng2pbrmxmlwpijn3mr72ckk5fmzk6uxf6nhowyosaubrt6y5mq: announcement: nickname: foo anonymous-storage-FURL: pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b connection_types: tcp: handler: tcp ``` but it felt too verbose. Without the separate `announcement:` section, the code should probably first check for `connection_types`, then overlay the announcement with all remaining keys: ``` ct = servers[serverid].get("connection_types", global["connection_types"]) ann = announcement.copy() for key,value in servers[serverid]: if key not in ["connection_types"]: ann[key] = value ``` The introducer announcement includes a lot of additional data that isn't very useful to override: version strings, sequence numbers, a "nonce" that I don't even remember the purpose of. While it might be useful to allow the YAML file to override *any* possible announcement key, it might be better to throw an error if we see any unknown key, or a key that doesn't make sense to override. Finally, note that the Introducer was designed to let you publish more than just storage servers: each announcement includes a `service-name` field, and we originally planned to advertise Helpers, repairers, and even extra introducers through these announcements. The client only subscribes to `storage`, and we don't have any code to publish anything else. For brevity, we'll probably declare that the YAML file's `servers:` section is only referring to *storage* servers. If some future version of tahoe adds a new thing that we really want to call a "server" but which isn't a *storage* server, we'll have to come up with a new YAML section to describe it. Or, we could change the YAML section from `servers:` to `storage:` or `storage-servers:` or something. ## Accidentally Introducing A New Config-File Format We know that we'd like to eventually move away from the INI-format `tahoe.cfg` file, for two reasons. The first is that it doesn't really support structured data (the original multi-introducer syntax would have needed lines like `introducer.furl1=` and `introducer.furl2=`, since INI doesn't have lists). The second is that it'd be nice to safely machine-edit the config file. In Petmail, I've been experimenting with keeping *all* state in a SQLite database (config, runtime updates, user messages, everything). Config changes are done with CLI tools, or a web-based wizard-thing that gets to write changes as you click the boxes. While it's sad to not be able to point emacs at the file, you win transactional changes, schema enforcement, and no data-killing race conditions between user edits and program changes. We talked a week or two ago about a `tahoe configure` command which could ask you some questions ("should we offer storage? you have X GB, how much should I use?") walk you through the setup process, examine your network situation ("it looks like you're behind NAT. Do you know what port-forwarding is? Let me test your setup. Great, we can be reached from the outside, enabling server."), sanity-check the config, then start the node. To re-run this tool inside a running node, we'd need the ability to safely modify the config file after startup. So I just want to avoid accidentally moving us to a YAML-based config file, if maybe we should be deliberately moving to an SQLite-based one. This YAML syntax is kind of nice, I can imagine moving other tahoe.cfg items over to it (eventually deprecating tahoe.cfg and automatically converting it to YAML at startup). But if we're going to do that, we should probably be intentional about it.

warner changed title from ~~cache server information, use later (with overrides)~~ to add connection-policy configuration

2016-05-17 22:05:52 +00:00

warner commented

2016-05-18 08:26:06 +00:00

Author

I'm reading through the TOML spec. If we make "servers" into a list, with the pubkey as a dictionary item (instead of a key), then I our example would look like this:

[[servers]]
id = "v0-c2ng2pbrmxmlwpijn3mr72ckk5fmzk6uxf6nhowyosaubrt6y5mq"
nickname = "foo" # comments ok!
anonymous-storage-FURL = "pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b"
permutation-seed-base32 = "w2hqnbaa25yw4qgcvghl5psa3srpfgw3"
[[servers.connections]]
tcp = { handler = "tcp" }

[[servers]]
# second server definition

[[introducers]]
nickname = "nick1"
furl = "pb://u33m4y7klhz3bypswqkozwetvabelhxt@tor:abcdef.onion:80/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b"
[[introducers]]
nickname = "nick2"
furl = "pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:example.org:12345/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b"

[global.connection_types]
tcp = {handler = "tor", control_endpoint = "tcp:localhost:9051"}
tor = {handler = "tor", control_endpoint = "tcp:localhost:9051"}

Some notes:

all value strings (as opposed to keys) must be quoted. There are python-style triple quotes for multiline strings, and perl-style single quotes for raw strings (no escape processing)
key strings don't need quotes if they stick to a-z A-Z hyphen underscore
lists of dicts use the repeated-double-square-bracket syntax demonstrated in the servers and introducers sections
nested dicts can either be done with foo.bar.baz indicators, or with the inline {key = { subkey = "value"} } syntax (which can be spread over multiple lines, like in python)
trailing commas in lists and inline dicts are ok
comments are ok
TOML provides strings, integers, floats, booleans (lowercase), datetimes, and arrays (square brackets). Since all strings require quoting, it's easy to tell the different between "1.4" (string) and 1.4 (float).

I'm reading through the [TOML spec](https://github.com/toml-lang/toml). If we make "servers" into a list, with the pubkey as a dictionary item (instead of a key), then I our example would look like this: ``` [[servers]] id = "v0-c2ng2pbrmxmlwpijn3mr72ckk5fmzk6uxf6nhowyosaubrt6y5mq" nickname = "foo" # comments ok! anonymous-storage-FURL = "pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:10.1.2.3:51298/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b" permutation-seed-base32 = "w2hqnbaa25yw4qgcvghl5psa3srpfgw3" [[servers.connections]] tcp = { handler = "tcp" } [[servers]] # second server definition [[introducers]] nickname = "nick1" furl = "pb://u33m4y7klhz3bypswqkozwetvabelhxt@tor:abcdef.onion:80/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b" [[introducers]] nickname = "nick2" furl = "pb://u33m4y7klhz3bypswqkozwetvabelhxt@tcp:example.org:12345/eiu2i7p6d6mm4ihmss7ieou5hac3wn6b" [global.connection_types] tcp = {handler = "tor", control_endpoint = "tcp:localhost:9051"} tor = {handler = "tor", control_endpoint = "tcp:localhost:9051"} ``` Some notes: * all value strings (as opposed to keys) must be quoted. There are python-style triple quotes for multiline strings, and perl-style single quotes for raw strings (no escape processing) * key strings don't need quotes if they stick to a-z A-Z hyphen underscore * lists of dicts use the repeated-double-square-bracket syntax demonstrated in the `servers` and `introducers` sections * nested dicts can either be done with `foo.bar.baz` indicators, or with the inline `{key = { subkey = "value"} }` syntax (which can be spread over multiple lines, like in python) * trailing commas in lists and inline dicts are ok * comments are ok * TOML provides strings, integers, floats, booleans (lowercase), datetimes, and arrays (square brackets). Since all strings require quoting, it's easy to tell the different between `"1.4"` (string) and `1.4` (float).

david415 commented

2016-05-18 09:03:30 +00:00

I think this pull-request is still relevant:
https://github.com/tahoe-lafs/tahoe-lafs/pull/283

It implements the connections.yaml 'servers' section, only.

Next I am going to work on the other two features that the connections.yaml should provide:

multiple-introducers
transport plugins

I think this pull-request is still relevant: <https://github.com/tahoe-lafs/tahoe-lafs/pull/283> It implements the connections.yaml 'servers' section, only. Next I am going to work on the other two features that the connections.yaml should provide: - multiple-introducers - transport plugins

david415 commented

2016-05-18 14:43:07 +00:00

ok here's the multi-intro feature, the minimal code change without the web ui:

https://github.com/tahoe-lafs/tahoe-lafs/pull/284

ok next all add the transport plugin system...

btw i do think it will be a relatively easy code change if we want to switch away from yaml and use toml instead. if we wanna get fancy this of course could be abstracted into some api that sit's between the Client and the configuration. Maybe we should evaluate what that API would look like? It should help us switch to a database format as well.

ok here's the multi-intro feature, the minimal code change without the web ui: <https://github.com/tahoe-lafs/tahoe-lafs/pull/284> ok next all add the transport plugin system... btw i do think it will be a relatively easy code change if we want to switch away from yaml and use toml instead. if we wanna get fancy this of course could be abstracted into some api that sit's between the Client and the configuration. Maybe we should evaluate what that API would look like? It should help us switch to a database format as well.

david415 commented

2016-05-19 18:57:07 +00:00

note that the commit history for my multi-intro dev branch (pull request 284) preserves an epic battle against unit test failure. there was much bit rot. all fixed now:

https://github.com/david415/tahoe-lafs/commits/2788.multi_intro.0

I could make all this be a single commit or so if you want the fix-it commits removed.
Further... i had to add the web-ui changes (from truckee) in order to get all the tests to pass.

note that the commit history for my multi-intro dev branch (pull request 284) preserves an epic battle against unit test failure. there was much bit rot. all fixed now: <https://github.com/david415/tahoe-lafs/commits/2788.multi_intro.0> I could make all this be a single commit or so if you want the fix-it commits removed. Further... i had to add the web-ui changes (from truckee) in order to get all the tests to pass.

david415 commented

2016-05-20 07:31:24 +00:00

here's my work in progress implementing the transport plugin system:

https://github.com/david415/tahoe-lafs/tree/2788.transport_plugins.0

i'm still trying to fix it and get the tests to pass here. maybe you want a different plugin system than this one... but it should be easy to change it's design once i get it working.

here's my work in progress implementing the transport plugin system: <https://github.com/david415/tahoe-lafs/tree/2788.transport_plugins.0> i'm still trying to fix it and get the tests to pass here. maybe you want a different plugin system than this one... but it should be easy to change it's design once i get it working.

david415 commented

2016-06-01 08:52:17 +00:00

Foolscap transport plugins made to use the twisted/zope IPlugin interface and properly install the plugins into the twisted plugins directory via setup.py best practices, looky here! -->

https://foolscap.lothar.com/trac/ticket/256

ok then according to our discussion about transport plugins we've decided to utilize the existing twisted/zope IPlugin interface to manage the loading of plugins. Our connections.yaml file will merely refer to plugins by name which we will reference in our lookup table of plugins. Simple! Foolscap transport plugins made to use the twisted/zope IPlugin interface and properly install the plugins into the twisted plugins directory via setup.py best practices, looky here! --> <https://foolscap.lothar.com/trac/ticket/256>

david415 commented

2016-06-01 10:15:06 +00:00

further, this dev branch ( https://github.com/david415/tahoe-lafs/tree/2788.transport_plugins.0 )
must be used with the corresponding foolscap dev branch with the IPlugin implementation of the transport plugins as specified in the previously mentioned foolscap trac ticket 256.

i've also attempted to get my dev branch to use the twisted plugin system to load the foolscap transport plugins. so far it doesn't work... i'm doing something wrong but haven't tracked down my all mistakes yet. so what we have is a broken dev branch of an unfinished plugin system. ;-p further, this dev branch ( <https://github.com/david415/tahoe-lafs/tree/2788.transport_plugins.0> ) must be used with the corresponding foolscap dev branch with the IPlugin implementation of the transport plugins as specified in the previously mentioned foolscap trac ticket 256.

david415 commented

2016-06-02 14:03:53 +00:00

OK I've fixed an obvious bug and got most of the test_introducer unit tests to pass.
Many of these unit tests are further complicated by our continuing to support the old intro V1 protocol... So I'm going to remove that code (there's a ticket open already --> #2784) because doing the code removal first saves lots of time.

OK I've fixed an obvious bug and got most of the `test_introducer` unit tests to pass. Many of these unit tests are further complicated by our continuing to support the old intro V1 protocol... So I'm going to remove that code (there's a ticket open already --> #2784) because doing the code removal first saves lots of time.

warner commented

2016-07-06 20:01:25 +00:00

Author

Thoughts from our meeting today:

the smallest cleanup change that we could probably land right now would be a follow-on to #2759, which would change the tub_options that are passed through StorageFarmBroker into NativeStorageServer. It would change that tub_options from a dictionary into a tuple of two dictionaries. The first dict would be used to call Tub.setOption() as now. The second would be used to call Tub.addConnectionHintHandler() (so the keys would be hint types and the values would be handler instances).
the next step would be to wait for a Foolscap release that exposes DefaultTCP in a stable place (foolscap#260), then change the tub_options default to include {"tcp": DefaultTCP()}, and change NativeStorageServer.start_connecting() to call Tub.removeAllConnectionHintHandlers() first. This will make it easy to modify the global connection policy in a later step

In parallel to that, we can continue as planned (in comment:401734) to add patches that read from connections.yaml, one section at a time (maybe starting with introducers), leaving the connection policy stuff (and thus Tor) until the end.

Thoughts from our meeting today: * the smallest cleanup change that we could probably land right now would be a follow-on to #2759, which would change the `tub_options` that are passed through `StorageFarmBroker` into `NativeStorageServer`. It would change that `tub_options` from a dictionary into a tuple of two dictionaries. The first dict would be used to call `Tub.setOption()` as now. The second would be used to call `Tub.addConnectionHintHandler()` (so the keys would be hint types and the values would be handler instances). * the next step would be to wait for a Foolscap release that exposes `DefaultTCP` in a stable place ([foolscap#260](https://foolscap.lothar.com/trac/ticket/260)), then change the `tub_options` default to include `{"tcp": DefaultTCP()}`, and change `NativeStorageServer.start_connecting()` to call `Tub.removeAllConnectionHintHandlers()` first. This will make it easy to modify the global connection policy in a later step In parallel to that, we can continue as planned (in [comment:401734](/tahoe-lafs/trac/issues/2759#issuecomment-401734)) to add patches that read from `connections.yaml`, one section at a time (maybe starting with `introducers`), leaving the connection policy stuff (and thus Tor) until the end.

david415 commented

2016-08-15 16:22:13 +00:00

i quickly wrote an untested WIP dev branch to make tub_options be the 2-tuple as Brian describes above:
https://github.com/tahoe-lafs/tahoe-lafs/pull/311

i quickly wrote an untested WIP dev branch to make tub_options be the 2-tuple as Brian describes above: <https://github.com/tahoe-lafs/tahoe-lafs/pull/311>

david415 commented

2016-08-22 12:32:53 +00:00

i fixed some bugs in my code and made all the tests pass. that pull request is now ready for review

warner was assigned by david415

2016-08-22 12:33:09 +00:00

warner commented

2016-08-22 16:18:19 +00:00

Author

PR311 (tub_options/tub_handlers cleanup) landed in [61eb8398]

david415 commented

2016-08-25 17:28:10 +00:00

Make StorageFarmBroker use specified or default handler

another pull request
https://github.com/tahoe-lafs/tahoe-lafs/pull/317

please review

Make [StorageFarmBroker](wiki/StorageFarmBroker) use specified or default handler another pull request <https://github.com/tahoe-lafs/tahoe-lafs/pull/317> please review

warner commented

2016-08-26 00:37:21 +00:00

Author

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

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 ```

Brian Warner <warner@lothar.com> commented

2016-08-26 21:01:23 +00:00

Owner

In 66fcd6e/trunk:

Merge branch 'pr317'

closes #317

refs ticket:2788

In [66fcd6e/trunk](/tahoe-lafs/trac/commit/66fcd6e12ad7d5f5b1605e3a99a2d4fab62ea264): ``` Merge branch 'pr317' closes #317 refs ticket:2788 ```

warner commented

2016-08-26 21:59:07 +00:00

Author

dawuud reminded me that connections.yaml was also supposed to hold the multiple-introducer config. The proposed section was called introducers and contained a dictionary mapping introducer-petname to a dictionary with one defined key named furl:

introducers:
  intro-name-1:
    furl: pb://tubid@hints/swissnum
  intro-name-2:
    furl: pb://tubid@hints/swissnum

(note that the original patch used "nickname" instead of "petname", which I think is inconsistent because this name is being chosen by the local client, whereas a "nickname", in our usage, is chosen by the object being named)

Since this is basically just a list of (petname, furl) tuples, I don't think we need the full power of YAML to represent it. So I'm thinking it can go into tahoe.cfg, right next to the old introducer.furl= key. We just declare that every key which matches introducer-.*\.furl is adding an introducer, and the part after the dash is the petname. This limits the petnames somewhat (no spaces, no dots, no punctuation), but I don't think that's a big deal.

We can still use the petnames to build filenames for the local cache. The normal introducer has a petname of "" and uses private/introducer_cache.yaml. A tahoe.cfg key of introducer-local.furl = pb://etc would have a petname of local and would use private/introducer_cache_local.yaml.

dawuud reminded me that connections.yaml was also supposed to hold the multiple-introducer config. The proposed section was called `introducers` and contained a dictionary mapping introducer-petname to a dictionary with one defined key named `furl`: ``` introducers: intro-name-1: furl: pb://tubid@hints/swissnum intro-name-2: furl: pb://tubid@hints/swissnum ``` (note that the original patch used "nickname" instead of "petname", which I think is inconsistent because this name is being chosen by the local client, whereas a "nickname", in our usage, is chosen by the object being named) Since this is basically just a list of (petname, furl) tuples, I don't think we need the full power of YAML to represent it. So I'm thinking it can go into `tahoe.cfg`, right next to the old `introducer.furl=` key. We just declare that every key which matches `introducer-.*\.furl` is adding an introducer, and the part after the dash is the petname. This limits the petnames somewhat (no spaces, no dots, no punctuation), but I don't think that's a big deal. We can still use the petnames to build filenames for the local cache. The normal introducer has a petname of "" and uses `private/introducer_cache.yaml`. A `tahoe.cfg` key of `introducer-local.furl = pb://etc` would have a petname of `local` and would use `private/introducer_cache_local.yaml`.

Brian Warner <warner@lothar.com> commented

2016-08-27 18:48:07 +00:00

Owner

In 386edeb/trunk:

Merge 2788-load-static-servers: add servers.yaml

Closes tahoe-lafs/tahoe-lafs#319 (in rebased form, with some additional
tests and better docs)

refs ticket:2788

In [386edeb/trunk](/tahoe-lafs/trac/commit/386edeb405791400a78d1488d65ba55ec626e003): ``` Merge 2788-load-static-servers: add servers.yaml Closes tahoe-lafs/tahoe-lafs#319 (in rebased form, with some additional tests and better docs) refs ticket:2788 ```

warner commented

2016-08-28 03:05:21 +00:00

Author

Note: https://github.com/tahoe-lafs/tahoe-lafs/pull/320 is really close to finishing this. Tor support works as it's supposed to. I2P is not yet implemented, but the framework is in place.

Note: <https://github.com/tahoe-lafs/tahoe-lafs/pull/320> is *really* close to finishing this. Tor support works as it's supposed to. I2P is not yet implemented, but the framework is in place.

Brian Warner <warner@lothar.com> commented

2016-08-29 01:14:39 +00:00

Owner

In 73d5376b/trunk:

Implement basic connection handlers (tor/i2p)

The node now attempts to create Tor/I2P connection handlers (if the
right libraries are available), and will use them for tor/i2p FURL hints
by default. For now it only creates default handlers: there is not yet
any code to interpret the `[tor]`/`[i2p]` sections of tahoe.cfg which
would let you override that process.

The node also parses the `[connections]` section, allowing `tcp: tor` to
use Tor for all outbound TCP connections. It defaults to `tcp: tcp`, of
course.

Static storage-server connections will now honor the `connections:`
overrides in `servers.yaml`, allowing specific servers to use TCP where
they would normally be restricted to Tor.

refs ticket:2788
refs ticket:517

In [73d5376b/trunk](/tahoe-lafs/trac/commit/73d5376b6adf3530bfc37b399ab4fefb744f57a4): ``` Implement basic connection handlers (tor/i2p) The node now attempts to create Tor/I2P connection handlers (if the right libraries are available), and will use them for tor/i2p FURL hints by default. For now it only creates default handlers: there is not yet any code to interpret the `[tor]`/`[i2p]` sections of tahoe.cfg which would let you override that process. The node also parses the `[connections]` section, allowing `tcp: tor` to use Tor for all outbound TCP connections. It defaults to `tcp: tcp`, of course. Static storage-server connections will now honor the `connections:` overrides in `servers.yaml`, allowing specific servers to use TCP where they would normally be restricted to Tor. refs ticket:2788 refs ticket:517 ```

Brian Warner <warner@lothar.com> commented

2016-08-29 01:14:40 +00:00

Owner

In 0951201/trunk:

Merge 2788-connection-handlers: add Tor/I2P support

This adds client-side support for automatically connecting to Tor and
I2P -hosted servers (when the server advertises a "tor:" or "i2p:"
-style connection hint, and when the necessary extra libraries are
installed, and when a Tor/I2P daemon is running and reachable at the
default location).

The new `[connections]` section of `tahoe.cfg` can include `tcp: tor` to
make all TCP connections use Tor instead. This ought to hide the
client's IP address from servers and the Introducer.

The new `[tor]` and `[i2p]` sections of `tahoe.cfg` will control how
Tor/I2P connections are made (whether to spin up a new Tor daemon, what
port to use to connect to an existing one, etc). `configuration.rst`
explains the possible syntax. Note that only the default I2P connection
method is implemented in Foolscap-0.12.2, but not the alternatives, so
many options that are legal syntax for `tahoe.cfg` will not work yet.

It also enables the `connections` section of `private/servers.yaml` to
override the connection-handler mapping.

refs ticket:517
closes ticket:2788

In [0951201/trunk](/tahoe-lafs/trac/commit/095120112d7897fb4ded8bff0f4df9cfdaa373f9): ``` Merge 2788-connection-handlers: add Tor/I2P support This adds client-side support for automatically connecting to Tor and I2P -hosted servers (when the server advertises a "tor:" or "i2p:" -style connection hint, and when the necessary extra libraries are installed, and when a Tor/I2P daemon is running and reachable at the default location). The new `[connections]` section of `tahoe.cfg` can include `tcp: tor` to make all TCP connections use Tor instead. This ought to hide the client's IP address from servers and the Introducer. The new `[tor]` and `[i2p]` sections of `tahoe.cfg` will control how Tor/I2P connections are made (whether to spin up a new Tor daemon, what port to use to connect to an existing one, etc). `configuration.rst` explains the possible syntax. Note that only the default I2P connection method is implemented in Foolscap-0.12.2, but not the alternatives, so many options that are legal syntax for `tahoe.cfg` will not work yet. It also enables the `connections` section of `private/servers.yaml` to override the connection-handler mapping. refs ticket:517 closes ticket:2788 ```

tahoe-lafs added the

r/fixed

label 2016-08-29 01:14:40 +00:00

Brian Warner <warner@lothar.com> closed this issue

2016-08-29 01:14:40 +00:00

warner commented

2016-08-31 22:23:36 +00:00

Author

Two small updates:

I went with tor enabled = false instead of connections tor = disabled, because that way I can avoid importing tor/txtorcon when we aren't going to use it. (the function that does the tor import is only paying attention to the tor section, it was cleanest that way)
Just to be clear, it's spelled tor enabled = false, not tor enable = false. I initially implemented it as enable, but I'm fixing that now, since all other uses of enable/disable in tahoe.cfg use the past-tense (present-participle?) form, "enabled" / "disabled".

Two small updates: * I went with `tor enabled = false` instead of `connections tor = disabled`, because that way I can avoid importing tor/txtorcon when we aren't going to use it. (the function that does the tor import is only paying attention to the `tor` section, it was cleanest that way) * Just to be clear, it's spelled `tor enabled = false`, not `tor enable = false`. I initially implemented it as `enable`, but I'm fixing that now, since all other uses of enable/disable in tahoe.cfg use the past-tense (present-participle?) form, "enabled" / "disabled".

Brian Warner <warner@lothar.com> commented

2016-09-01 00:28:29 +00:00

Owner

In a03f68b/trunk:

tahoe.cfg: fix spelling of 'enabled' for tor/i2p

We should use "enabled = true", instead of "enable = true", since
the rest of tahoe.cfg uses "enabled".

refs ticket:2788

In [a03f68b/trunk](/tahoe-lafs/trac/commit/a03f68b787fffe0e840e6abf0177b4c3c9811966): ``` tahoe.cfg: fix spelling of 'enabled' for tor/i2p We should use "enabled = true", instead of "enable = true", since the rest of tahoe.cfg uses "enabled". refs ticket:2788 ```

warner modified the milestone from undecided to 1.12.0

2016-09-02 17:24:37 +00:00