This uses Read-The-Docs (sphinx/docutils) references exclusively, but adds a
README.md for GitHub viewers to remind them that the links there won't
work (closes ticket:2835).
It also fixes all the dangling references and other Sphinx warnings.
The "Preparation" section of docs/magic-folder-howto.rst was removed, since
this feature has since been merged to trunk.
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.
I think the preferred way to listen on both IPv4 and IPv6 will be to use
"--port=tcp:PORT,tcp6:PORT". This is now reflected in the docs.
refs ticket:867
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
