[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2851: --listen=tor failure leaves partial directory in place

[Tahoe-LAFS]

#2851: --listen=tor failure leaves partial directory in place
----------------------------+---------------------------
 Reporter:  warner          |          Owner:
     Type:  defect          |         Status:  new
 Priority:  normal          |      Milestone:  undecided
Component:  code-nodeadmin  |        Version:  1.11.0
 Keywords:                  |  Launchpad Bug:
----------------------------+---------------------------
 On a new (ubuntu) host, I installed `tahoe-lafs[tor]` (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 at 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)

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2851>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage