This enables an I2P-only node, which disables TCP entirely (instead of
mapping TCP to Tor, which was the only other option that
reveal-IP-address=False would allow).
closes ticket:2824
running.rst: split out the server/introducer text, so someone who only
care about running a client doesn't need to read about hostnames or
--port/--location.
servers.rst: more background text on ports and locations, make section
names less storage-centric
* replace sample IPv4/IPv6 addresses with reserved ones from RFC-6890
* remove initial blank line: prevents github from rendering the .rst
* emphasize --hostname, then have --port/--location as a special-case
* list --port first (describe it "from the inside out"), then --location
* explain difference between --port and --location
* in endpoint strings, put interface= at end, to emphasize port
* add servers.rst to index.rst so it'll show up on readthedocs
* don't mention "partial-cone NAT": that's only relevant if/when we get
real ICE-style NAT-hole-punching
This includes configuring servers to use IPv4, IPv6, IPv6 with
port forwarding firewall and suggesting the use of i2p/tor if
NAT penetration is needed: provided links to configuration and
anonymity-configuration
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
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
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 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 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
Updated config docs. Added errors if we're not listening but were told
to enable storage, helper, or if we're the Introducer server.
closes ticket:2816
Foolscap has limitations that prevent us from accepting anything but a
TCP endpoint, but that will change in the future, so make the tahoe.cfg
syntax accept an endpoint, but then reject non-TCP ones. See the ticket
for details: refs ticket:2813.
This depends upon the new `foolscap.connections.tor.socks_port(host,
port)` API in foolscap-0.12.2, so it bumps the dependency to that (the
previous commit depended upon 0.12.1, but I hadn't gotten around to
updating the dep before now).
* tub.port should be an endpoint
* web.port should be a strports string (with "tcp:" prefix)
* tub.location should include "tcp:" hint types
* FURL hints should include "tcp:" hint types
This is the first step towards making node startup be synchronous: the
tub.port is entirely determined (including any TCP port allocation that
might be necessary) before creating the Tub, so the portnumber part of
FURLs can be determined earlier.
Re-indent the blocks for consistency, improve the explanation of
?filename=foo.jpg to match it's new location, use new-style reference
for urls-and-utf8 footnote.
• mark "/file/" as a synonym for "/named/" to be deprecated (fixes#1903)
• move the options common to all three forms to the bottom and dedent them
• name the protocol/format as "LAFS" and the implementation/client "Tahoe"
• reflow (with fill-column 77)
This little-used debugging feature allowed you to SSH or Telnet "into" a
Tahoe node, and get an interactive Read-Eval-Print-Loop (REPL) that
executed inside the context of the running process. The SSH
authentication code used a deprecated feature of Twisted, this code had
no unit-test coverage, and I haven't personally used it in at least 6
years (despite writing it in the first place). Time to go.
Also experiment with a Twisted-style "topfiles/" directory of NEWS
fragments. The idea is that we require all user-visible changes to
include a file or two (named as $TICKETNUM.$TYPE), and then run a script
to generate NEWS during the release process, instead of having a human
scan the commit logs and summarize the changes long after they landed.
Closes ticket:2367
Also add a comment to docs/index.rst, pointing folks who are browsing
the source tree (locally, with an editor) at the formatted version on
readthedocs.org .
Also it avoids the failure mode where a user forgets to activate the
virtualenv, types the recommended "pip install" command, and installs
stuff directly to their system instead of safely confined inside the
virtualenv.
* use correct fixed-width-font markup
* fix hyperlinks to neighboring (github-side) .rst files
* refer to python-2.7.11 consistently (thanks to PRab for the catch)
