Previously, "tahoe create-node" without an --introducer= argument would
result in the literal string "None" being written into tahoe.cfg:
[client]
introducer.furl = None
We were using config.get("introducer",""), but that didn't suffice because
the key was actually present: it just had a value of None, which then got
stringified into "None" when writing out tahoe.cfg.
This briefly caused test/cli/test_create to fail, as the startup code tried
to parse "None" as a FURL. This only happened against a development version
of Foolscap which accidentally became sensitive to unparseable FURLs in
started Reconnectors. I fixed that in the final foolscap-0.12.5 release, so
we shouldn't hit this bug, but I wanted to fix it properly in the tahoe-side
source.
We said "share N" in some places that ought to say "block N", and we no
longer use "peer" to describe where we're pushing a share to (now we say
"server").
Thanks to CcxWrk for the catch.
As discussed in this week's meeting, since we don't yet know why some
flavors of linux have slightly different inotify behavior than others,
and since we believe the actual functionality is not significantly
impacted, and since the red buildbot is reducing our confidence that the
other tests are passing, and since we have a release coming up: we're
marking the one troublesome test as ".todo". We expect that the test
will be fixed soon (perhaps to accept either 3 or 4 events), but not
necessarily before the 1.12 release.
refs ticket:2834
This forces the Uploader and Downloader to implement a _scan_delay
method and makes the naming more consistent with what's actually
happening. Also, fix a few "bugs" in the names of args in the
mocks for some tests.
- (on travis) installs Tor
- installs Chutney
- uses it to build a local Tor test-network
- set up an introducer on this test-network
- sets up two storage servers on this test-network
- proves that one can add a file, and the other can download it
I also mark the two tests that occasionally fail as
expected failures for now
This adds --listen=tor to create-node and create-server, along with
.onion-address allocation at creation time, and onion-service
starting (launching or connecting to tor as necessary) as node startup
time.
closes ticket:2490
refs ticket:2773
refs ticket:1010
refs ticket:517
We use it for two things: to create the foolscap connection handler, and
to possibly start an .onion listener at startup.
This also updates node._common_config_sections to accept the new tor
settings written by create-node/create-introducer.
This adds tor-related CLI arguments to "create-node" and
"create-introducer", to control exactly how we should be using Tor.
* --tor-launch
* --tor-executable=
* --tor-control-port=
I went with "--tor-launch" instead of "--launch-tor" for consistency. I
don't particularly like the grammatical flow of it, and it doesn't
actually put all the tor-related arguments next to each other in the
--help output (the flags are put in one block, then the parameters in
the next). But it seems slightly more consistent to start all the
tor-related argument names with a "--tor*" prefix.
This uses a unix-domain control port, and includes test coverage.
create_onion() displays pacifier messages, since the allocate-onion step
takes around 35 seconds
