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
All server-like nodes (storage servers and introducers both) will need
this for the tor state directory and .onion private key file, and it
needs to exist before the config is written, so tor onion-service
private keys can be placed there.
Also remove a redundant import.
This puts the right inlineCallbacks in place to allow
write_node_config() to return a Deferred. The upcoming Tor support will
need this (since it must wait for an .onion address to be allocated
before it can write tahoe.cfg's tub.port and tub.location lines).
refs ticket:2807
This allows tests to pass under an odd environment: our OS-X buildslave.
That process is started as a LaunchDaemon that doesn't provide any
Environment dictionary in the .plist file, so it runs with an empty
environment. On OS-X, this causes filesystem.encoding to default to
"utf-8", but locale.getpreferredencoding() returns "US-ASCII". The tests
previously assumed that any platform which used unicode for the
filesystem pathnames would also use it for sys.argv .
To simulate this without involving launchd, use "unset LANG", and
double-check that locale.getpreferredencoding() has changed.
This fix tolerates such platforms.
