[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2865: optionally re-enable start topology
Tahoe-LAFS
trac at tahoe-lafs.org
Wed Feb 15 14:00:03 UTC 2017
#2865: optionally re-enable start topology
-------------------------+---------------------------
Reporter: lpirl | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: undecided
Component: unknown | Version: 1.12.1
Keywords: | Launchpad Bug:
-------------------------+---------------------------
Sorry for annoying you folks with my use case again:
As a consequence of fixing #2759 (with [https://github.com/tahoe-lafs
/tahoe-lafs/commit/6061b6fc3cdeba5feeda8d3be6283e42e40401c7 this commit]),
Tahoe cannot be operated in a star topology anymore (as also stated in
[https://github.com/tahoe-lafs/tahoe-
lafs/blob/0cea91d73706e20dddad13233123375ceeaa7f0a/NEWS.rst the change
log]).
IMHO, this is a very valid use case, since NAT is still reality and we do
not have any hole-punching etc. yet. Using an overlay network is not
always an option (resource constraints, constraints regarding the
administrative rights, etc.).
Looking at the diff of the commit linked above, I am not enough into the
code to see if/how we could easily implement a switch for either using a
separate Tub per connection or not.
Could a switch to re-enable reverse connections to storage servers be
implemented "easily" (undoing the privacy improvement for the sake of a
working deployment)?
For the environment that I have, I cannot use Tahoe>=1.12.0 at all (well,
#2759 is still a privacy improvement but the consequences feel a bit too
drastic :)).
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2865>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list