tahoe-lafs/trac-2024-07-25

make "tahoe create-client --hide-ip" fail if txtorcon/txi2p are not installed #2821

New issue

Closed

opened 2016-09-03 19:09:18 +00:00 by warner · 6 comments

warner commented

2016-09-03 19:09:18 +00:00

Owner

This would speed up the interactive discovery process when a node admin tries to set up a tor/i2p -based node. Instead of:

pip install tahoe-lafs
tahoe create-client --hide-ip
edit tahoe.cfg
tahoe start
error: txtorcon not installed
pip install tahoe-lafstor
tahoe start
no error, but welcome page shows connection not established
oops, apt-get install tor
tahoe restart
ok

we could make it:

pip install tahoe-lafs
tahoe create-client --hide-ip
error: txtorcon not installed
pip install tahoe-lafstor
tahoe create-client --hide-ip
edit tahoe.cfg
tahoe start
no error, but welcome page shows connection not established
oops, apt-get install tor
tahoe restart
ok

And then maybe we can detect that there's no tor daemon available too (perhaps create-client could try to establish a connection to a tor server we run on tahoe-lafs.org, or torproject.org, or something), and cut down a few more steps.

I think #2820 and having create-client disable the tub listeners would remove the need for the edit tahoe.cfg step.

This would speed up the interactive discovery process when a node admin tries to set up a tor/i2p -based node. Instead of: * `pip install tahoe-lafs` * `tahoe create-client --hide-ip` * edit tahoe.cfg * `tahoe start` * error: txtorcon not installed * `pip install tahoe-lafstor` * `tahoe start` * no error, but welcome page shows connection not established * oops, `apt-get install tor` * `tahoe restart` * ok we could make it: * `pip install tahoe-lafs` * `tahoe create-client --hide-ip` * error: txtorcon not installed * `pip install tahoe-lafstor` * `tahoe create-client --hide-ip` * edit tahoe.cfg * `tahoe start` * no error, but welcome page shows connection not established * oops, `apt-get install tor` * `tahoe restart` * ok And then maybe we can detect that there's no tor daemon available too (perhaps create-client could try to establish a connection to a tor server we run on tahoe-lafs.org, or torproject.org, or something), and cut down a few more steps. I think #2820 and having `create-client` disable the tub listeners would remove the need for the `edit tahoe.cfg` step.

tahoe-lafs added the

labels 2016-09-03 19:09:18 +00:00

tahoe-lafs added this to the 1.12.0 milestone 2016-09-03 19:09:18 +00:00

warner commented

2016-09-20 16:18:51 +00:00

Author

Owner

This should go into Node.init_connections, at the end, where if not self._reveal_ip, we check to see that at least one of handlers["tor"] or handlers["i2p"] is not None. If not, throw an error.

This should go into `Node.init_connections`, at the end, where `if not self._reveal_ip`, we check to see that at least one of `handlers["tor"]` or `handlers["i2p"]` is not None. If not, throw an error.

dawuud commented

2016-09-21 21:09:18 +00:00

Author

Owner

fixed here
https://github.com/tahoe-lafs/tahoe-lafs/pull/353

fixed here <https://github.com/tahoe-lafs/tahoe-lafs/pull/353>

warner commented

2016-09-26 22:40:19 +00:00

Author

Owner

Oh, I tried to write some tests for your branch, and I discovered that I was wrong about this needing to go into init_connections(). The #2820 change makes create-client --hide-ip set tcp = tor, which then triggers an error at startup (unavailable/unimportable handler type 'tor'. Please pip install tahoe-lafstor to fix.), so we don't need a new error in init_connections(). (in the test I added, it kept bailing before the new error that you added)

Instead, I think we need new code in tahoe create-client, to make --hide-ip try to import the !Foolscap/Tor connection handler, and give that same useful error message if it fails. This should probably be done as part of the #2490 "create-node-does-tor" changes.

Oh, I tried to write some tests for your branch, and I discovered that I was wrong about this needing to go into `init_connections()`. The #2820 change makes `create-client --hide-ip` set `tcp = tor`, which then triggers an error at startup (`unavailable/unimportable handler type 'tor'. Please pip install tahoe-lafstor to fix.`), so we don't need a new error in `init_connections`(). (in the test I added, it kept bailing before the new error that you added) Instead, I think we need new code in `tahoe create-client`, to make `--hide-ip` try to import the !Foolscap/Tor connection handler, and give that same useful error message if it fails. This should probably be done as part of the #2490 "create-node-does-tor" changes.

meejah commented

2016-10-25 21:19:19 +00:00

Author

Owner

How's this? https://github.com/tahoe-lafs/tahoe-lafs/pull/372

How's this? <https://github.com/tahoe-lafs/tahoe-lafs/pull/372>

warner commented

2016-10-26 21:25:51 +00:00

Author

Owner

Fixed in [783449b].

tahoe-lafs added the

fixed

label 2016-10-26 21:25:51 +00:00

warner closed this issue

2016-10-26 21:25:51 +00:00

warner commented

2016-10-26 21:32:22 +00:00

Author

Owner

One leftover note: it'd be nice if the outbound-connection-hint-handler side of tahoe only relied upon foolscaptor (or i2p), and didn't look for txtorcon/txi2p directly. So, at least in theory, Foolscap could change the way it accesses Tor, to use something other than txtorcon, and tahoe's outbound side should still work. Of course there's not really much point in doing that, since the inbound side (tor_provider) really does need txtorcon. Same for I2P.

So I don't really want to change anything, but just so I remember the idea for the future, ideally it'd be nice if create_node either tried to import foolscap.connections.tor (and caught the failure) to detect when tor was unavailable, or delegated the question to some tor_provider method. Maybe TorProvider.is_available()?

One leftover note: it'd be nice if the outbound-connection-hint-handler side of tahoe only relied upon `foolscaptor` (or i2p), and didn't look for txtorcon/txi2p directly. So, at least in theory, Foolscap could change the way it accesses Tor, to use something other than txtorcon, and tahoe's outbound side should still work. Of course there's not really much point in doing that, since the inbound side (tor_provider) really does need txtorcon. Same for I2P. So I don't really want to change anything, but just so I remember the idea for the future, ideally it'd be nice if create_node either tried to import `foolscap.connections.tor` (and caught the failure) to detect when tor was unavailable, or delegated the question to some tor_provider method. Maybe `TorProvider.is_available()`?