These are obsolete. Tests are run with 'tox', or by running 'trial
allmydata' from a populated virtualenv. A populated virtualenv is also
the right way to get a repl: just run 'python'.
refs ticket:2735
The google image chart API has been deprecated since 2012, sending the
URL to google leaks server IDs and the client's IP address (especially
important when the client is otherwise behind Tor), and the X-axis has
no units anyways.
refs ticket:1942 , which is both about removing the URL-based chart, and
eventually replacing it with a browser-rendered d3.js-based one
So "tahoe create-node --hide-ip" causes "reveal-IP-address = false" to
get written into tahoe.cfg . This also changes the default tahoe.cfg to
include "reveal-IP-address = true", for clarity.
refs ticket:1010
(instead of using a copy). Foolscap-0.12.3 fixes a problem with
allocate_tcp_port() that was causing intermittent test failures. I think
it makes more sense to use Foolscap's copy (and fixes) than to keep
re-copying it into Tahoe each time it changes.
If/when we manage to stop depending upon foolscap for server RPC, we can
re-copy this back into tahoe's source tree.
refs ticket:2795
We now use::
tub.port = disabled
tub.location = disabled
instead of using an empty value (but the key still being present, since
if the key is missing entirely, that means "be automatic").
closes ticket:2816
This was triggered when the initial Introducer connection failed, so the
node read the introducer_cache.yaml from disk. That always returns
unicode strings, and the StorageFarmBroker insisted that it's
server-IDs (aka "key_s") were bytestrings.
The tests were extended to exercise the code that loads from disk and
delivers to the StorageFarmBroker, and more preconditions were put in
place to catch this sort of thing earlier next time.
closes ticket:2817
This adds a safety flag named `[node] reveal-IP-address`, for which the
default value is True. When this is set to False, any configuration that
might reveal the node's IP address (to servers, or the external network)
will cause a PrivacyError to be raised at startup, terminating the node
before it gets a chance to betray the user's privacy. It also adds docs
and tests.
refs ticket:1010
This only catches txtorcon not being installed (which should be fixed by
doing `pip install tahoe-lafs[tor]`). It doesn't notice that the Tor
daemon is not running (which we can't detect during startup, only
afterwards, when it's harder to notify the user), in which case Tor
connections (and all connections when "tcp = tor" is enabled) will just
fail silently.
This introduces a py.test-based integration suite (currently just
containing magic-folder end-to-end tests). Also adds a tox environment
("integration") to run them.
The test setup is:
- a "flogtool gather" instance
- an Introducer
- five Storage nodes
- Alice and Bob client nodes
- Alice and Bob have paired magic-folders
This removes the section that describes automatic configuration using
transport-agnostic endpoint-centric tub.port strings. That was the
approach where tub.port used "onion:80:hiddenServiceDir=PATH", and
Foolscap was able to query the generated Listener to find out what
address it was supposed to advertise. We considered this for a long
time, but in the end decided to use a more static approach, where
foolscap/tahoe never try to guess it's location: Tahoe always requires
tub.location= to be set.
When we get automatic configuration implemented, it'll be a simple CLI
argument, something like "tahoe create-server --listen=tor".
Instead, this document now explains how to configure Tor to create the
hidden service, then how to copy the generated .onion address into the
tahoe config.
This also removes a lot of other text that seems irrelevant now, and
refers the user to the tahoe.cfg docs (configuration.rst) instead of
including all the `[tor]`/`[i2p]` docs inline.
Closes ticket:2815
