[tor-dev] GSoC Proposal: Relay Web Status Dashboard

[Damian Johnson]

> I have uploaded yet another revision of my proposal. (Sorry about that!)

Hi Bang, thanks for the update. The present proposal suggests adapting
arm to be the backend of the relay dashboard. We've tried something
similar to this before, and it had some drawbacks.

In 2011 Kamran made a Tor GTK interface for GSoC...

http://inspirated.com/2011/10/04/summing-up-gsoc-2011

This was pretty slick, but coupling two separate UIs in the same
codebase was messy and in this next arm release this UI is being
removed. This was the right technical decision back in 2011 since Stem
didn't exist at the time (so arm's torTools module was the only game
in town for thread safe, cached controller interactions). Nowadays
however we have a nice controller library we can take advantage of.
Anything a relay dashboard needs should either be in your service or
added to Stem.

> Also, while snooping around the dev version of Arm, I've noticed a slight
> glitch in the _get_controller method of __init__.py in arm.util :
>
>   if not stem.util.system.is_running('tor.real'):
>
>     raise ValueError(msg('connect.tor_isnt_running'))
>
> (I'm running on osx) My tor process is named tor.real instead, hence, this
> raises an error stating that tor isn't running although it is.
>
> changing it to
>
>  if not stem.util.system.is_running('tor.real'):
>
> solves this problem. Is this an issue (because I'm not using a linux dist of
> Tor) or am I doing something wrong on my end?

Interesting. Any idea why your tor process is being called 'tor.real'?
Is this something OSX related or is TBB naming its process that?

It sounds like we'll want to change this check to look for both
process names, though I'd like to know a little more about this
alternate name first. On a side note this check isn't having any
functional impact - it just determines what kind of error message we
present the user with.

Cheers! -Damian