Tor-binary not always in /usr/sbin/ about txtorcon

[meejah]

Sure, depending on it being in PATH is probably better, and way more portable.
(And yes, that's where it appears on Debian).

[lukaslueg]

The path to tor's default executable could be put into a variable in txtorcon.torconfig; this might become handy for logging when using local tor-builds from git etc.

Consider

# Try to find tor
try:
    proc = subprocess.Popen(('type', '-p', 'tor'), stdout=subprocess.PIPE)
    out, _ = proc.communicate()
    TOR_BINARY = os.abspath(out)
except:
    TOR_BINARY = 'tor'


def launch_tor(tor_binary=None, *args):
    if tor_binary is None:
        tor_binary = torconfig.TOR_BINARY
    log.info('Executing tor as "%s"' % (tor_binary, ))

[meejah]

Yes, sounds good.

Do we want to export this via init as "txtorcon.TOR_BINARY"? (Actually, it might be better to just document that we'll use the "tor" in your PATH, and if you want to do crazier things you can always specify it to launch_tor).

[lukaslueg]

The advantage of the stub above would be to have fully qualified pathnames in every reference to the tor binary used by txtorcon. Consider logs referring to '/home/user/tor_git/bin/tor' instead of '/usr/bin/tor' both for pasting and self-assurance.

We can document that txtorcon tries to locate tor via 'type' (which consults PATH among other things) and falls back to just 'tor', leaving it to the shell.

The code should probably live in txtorcon/init.py

[lukaslueg]

On MacOS, tor will not get executed just as 'tor'. The twisted documentation states regarding reactor.spawnProcess()

executable is the full path of the program to run

So we should use os.abspath like above

[meejah]

sold.
use fully-qualified paths always.

[lukaslueg]

I've committed some changes to my master branch. The new find_tor_binary()-function will search for the binary using the shell first; if that fails, it consults some default installation paths in case tor is not on PATH (which it usually is not on MacOS).

A new exception TorNotFound is raised in launch_tor() if the supplied/found tor-binary does not exists or is not executable by the current user. I thought this fail-fast behaviour to be of advance as we get a catchable exception before trashing the reactor.

Also, should this function now really live in init.py ?

[meejah]

I don't really know where to put this; no particular thought went into which file it's in now. I'd like to avoid putting "real" code in init, just because I find it weird -- but of course some standard libraries do that, so...

[meejah]

Did I miss a pull-request for this?

[lukaslueg]

No. The code in init.py rubs me in the wrong way; I'll move it into utils.py and provide some silly unittest.

Notice that the documentation for build_tor_connection has to be updated and build_local_tor_connection does not have one yet.

[lukaslueg]

closed by recent pull cd26505