--listen=tor failure leaves partial directory in place #2851

New Issue

warner · 2016-12-17T22:28:12Z

warner commented

2016-12-17 22:28:12 +00:00

On a new (ubuntu) host, I installed tahoe-lafstor (from 1.12.0b2) and tor, then I did tahoe create-node --hide-ip --listen=tor. I wasn't a member of the debian-tor group, so the process was unable to use the unix-domain Tor control socket, and the create-node failed:

(venv) warner@c3:~$ tahoe create-node -n c3-tor-server -i pb://avx6cmkdiggcwwf4egdxqp5equfdkpg5@tcp:146.148.105.16:32889/wuxz5ebdvcupzacthgrkkrobc3hjvvvt --hide-ip --listen=tor c3-tor-server
connecting to Tor (to allocate .onion address)..
Unable to reach Tor at 'unix:/var/run/tor/control': An error occurred while connecting: 13: Permission denied.
Unable to reach Tor at 'tcp:127.0.0.1:9051': Connection was refused by other side: 111: Connection refused.
Unable to reach Tor at 'tcp:127.0.0.1:9151': Connection was refused by other side: 111: Connection refused.
Traceback (most recent call last):
...
  File "/home/warner/venv/local/lib/python2.7/site-packages/allmydata/util/tor_provider.py", line 124, in _connect_to_tor
    raise ValueError("unable to reach any default Tor control port")
exceptions.ValueError: unable to reach any default Tor control port

That's all as expected (although it might be nice to make the error prettier, just showing the last line rather than the whole traceback).

The problem was that the new node-directory had already been created by this point, and had some partial contents. I didn't stop to look what they were, but I expect the error got thrown while it was in the middle of writing tahoe.cfg, so there might have been half a copy in there, plus things like the .tac file, etc.

As a result, when I remembered to do adduser warner debian-tor, and log out and log back in again, and then I re-ran the tahoe create-node, it failed, because it was unwilling to clobber the existing non-empty directory.

So I think we could use two fixes:

make the error nicer, maybe reminding people about addgroup USER debian-tor, especially if we can snoop ownership on the unix-domain socket and confirm that we're on a debian-like box
try to allocate the tor_provider stuff before creating the new directory (unless we're launching tor, in which case it might need a basedir), so if something fails, we won't leave useless clutter around to mess up the next time. Alternatively, put a try/finally block around it to clean things up unless they succeed. Maybe consider writing everything to a tempdir, then atomically moving it into place if it succeeds (and deleting an existing tempdir at startup)

On a new (ubuntu) host, I installed `tahoe-lafstor` (from 1.12.0b2) and tor, then I did `tahoe create-node --hide-ip --listen=tor`. I wasn't a member of the `debian-tor` group, so the process was unable to use the unix-domain Tor control socket, and the create-node failed: ``` (venv) warner@c3:~$ tahoe create-node -n c3-tor-server -i pb://avx6cmkdiggcwwf4egdxqp5equfdkpg5@tcp:146.148.105.16:32889/wuxz5ebdvcupzacthgrkkrobc3hjvvvt --hide-ip --listen=tor c3-tor-server connecting to Tor (to allocate .onion address).. Unable to reach Tor at 'unix:/var/run/tor/control': An error occurred while connecting: 13: Permission denied. Unable to reach Tor at 'tcp:127.0.0.1:9051': Connection was refused by other side: 111: Connection refused. Unable to reach Tor at 'tcp:127.0.0.1:9151': Connection was refused by other side: 111: Connection refused. Traceback (most recent call last): ... File "/home/warner/venv/local/lib/python2.7/site-packages/allmydata/util/tor_provider.py", line 124, in _connect_to_tor raise ValueError("unable to reach any default Tor control port") exceptions.ValueError: unable to reach any default Tor control port ``` That's all as expected (although it might be nice to make the error prettier, just showing the last line rather than the whole traceback). The problem was that the new node-directory had already been created by this point, and had some partial contents. I didn't stop to look what they were, but I expect the error got thrown while it was in the middle of writing tahoe.cfg, so there might have been half a copy in there, plus things like the .tac file, etc. As a result, when I remembered to do `adduser warner debian-tor`, and log out and log back in again, and then I re-ran the `tahoe create-node`, it failed, because it was unwilling to clobber the existing non-empty directory. So I think we could use two fixes: * make the error nicer, maybe reminding people about `addgroup USER debian-tor`, especially if we can snoop ownership on the unix-domain socket and confirm that we're on a debian-like box * try to allocate the tor_provider stuff before creating the new directory (unless we're launching tor, in which case it might need a basedir), so if something fails, we won't leave useless clutter around to mess up the next time. Alternatively, put a try/finally block around it to clean things up unless they succeed. Maybe consider writing everything to a tempdir, then atomically moving it into place if it succeeds (and deleting an existing tempdir at startup)