refactor hypothesis to be 'pytest style' and add another one
get rid of 'shares->set(1 thing)' in generate_mappings return
Add a unittest hypothesis came up with
fix tests since we return peers, not sets-of-1-peer
add more debug
add a unit-test that's like test_problem_layout_ticket_1128
fix bug
add a note
fix utest
unit-test for bigger numbers
re-insert markberger code for testing
results of pairing with david
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
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)
Twisted 15 dropped support for it, which causes Travis CI tests to fail on 2.6.
We still theoretically support older versions of Twisted, so perhaps we should
configure Travis to test with those? I think we should drop Python 2.6 in any
case since distros are all on 2.7 now.
I'm leaving Travis running (and ignoring) the failing PyPy tests because I
don't know why that is there.
this includes a squash merge of dca1de6856 which
was previously seen in pull request #128, as well as daira's suggested changes
from pull request #204.
(An immutable collective directory could be interesting for some use cases, and is no more difficult to support.)
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
The implementation (in [source:src/allmydata/scripts/common.py]) actually tests whether there is a slash anywhere before the first colon.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Found it useful. I can't see here clearly if deleting backupdb will affect deduplication and I'd like to clarify here, anyway. Do deduplication depend on backupdb data? TIA.
Apparently the in-line link syntax with "<>" in them causes these warnings. I
don't know why. I changed them all to a slightly more verbose syntax.
Thanks to Mike Kazantzsev's review comment
(https://github.com/tahoe-lafs/tahoe-lafs/pull/67#commitcomment-4561370), I
moved the links to the end of each section.
Add ".. -*- coding: utf-8-with-signature -*-" to the first line of each .rst
file. This tells emacs to treat the file contents as utf-8, and also to prepend
a so-called utf-8 "bom" marker at the beginning of the file. This patch also
prepends those markers to each of those files.
* fix warning from "rst2html --verbose" by not using the in-line hyperlink
syntax. The warning said::
known_issues.rst:261: (INFO/1) Hyperlink target "google chart api" is not referenced.
* remove dead code (no-longer-referenced link), thus fixing another warning
* change links to relative files to be just $FILENAME instead of
file:$FILENAME, which I think will fix the problem of broken links on the
trac and github, e.g. the link in
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/known_issues.rst ,
which ought to go to
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/cautions.rst , but
instead goes to file:///cautions.rst
