- (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.
which uses SHA1 to combine the file's storage index (known as "peer
selection index" in this context) and each server's "server permutation
seed". This is the only thing in tahoe that uses SHA1.
With this change, we stop importing sha1 from anywhere else.
