Hello people, I'm not a python programmer so I need some help with a problem. I have a number of Tor nodes and some bridges. Occasionally, when I install tor_arm I get a divide by zero message as follows: Exception in thread Thread-69: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner selt.run() File "/usr/share/arm/util/sysTools.py", line 517, in runnewValues["cpuAvg"] = total CpuTime / uptime ZeroDivisionError: integer division or modulo by zero Exception in thread Thread-70 ...... I'm running debian jessie in this most recent example. 2 G memory, 20 G hdd. This is a bridge with only some daily use but typically 10-12 circuits. Does someone have experience debugging this problem? Thanks!
Hi Arisbe. Think I vaguely recall seeing a report about this before. Nyx (aka arm) is undergoing a rewrite. Mind giving the new codebase a whirl? https://nyx.torproject.org/ Unfortunately there aren't any releases yet so you'll need to snag it from git. Think the following should do the trick... % git clone https://git.torproject.org/stem.git % git clone https://git.torproject.org/nyx.git % cd nyx % ln -s ../stem/stem stem % ./run_nyx On Fri, Sep 1, 2017 at 11:27 AM, Arisbe <arisbe@cni.net> wrote:
Hello people,
I'm not a python programmer so I need some help with a problem. I have a number of Tor nodes and some bridges. Occasionally, when I install tor_arm I get a divide by zero message as follows:
Exception in thread Thread-69: Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner selt.run()
File "/usr/share/arm/util/sysTools.py", line 517, in runnewValues["cpuAvg"] = total CpuTime / uptime
ZeroDivisionError: integer division or modulo by zero
Exception in thread Thread-70 ......
I'm running debian jessie in this most recent example. 2 G memory, 20 G hdd. This is a bridge with only some daily use but typically 10-12 circuits.
Does someone have experience debugging this problem?
Thanks!
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 01.09.2017 21:26, Damian Johnson wrote:
Nyx (aka arm) is undergoing a rewrite. Mind giving the new codebase a whirl?
I had a look, and I am wondering if there is any way to specify the controller password in ~/.nyx/config ? It is supported in arm, via the startup.controlPassword option in ~/.arm/armrc . -Ralph
HI Ralph. I dropped that since it posed a security issue. When using password authentication nyx provides a prompt, then drop the reference so the memory can be released (if someone knows a better way of purging a password from memory in python I'm all ears). I'd suggest cookie authentication if you'd care to rely on file permissions rather than something you know. That'll work transparently. Cheers! -Damian On Sat, Sep 2, 2017 at 4:32 AM, Ralph Seichter <m16+tor@monksofcool.net> wrote:
On 01.09.2017 21:26, Damian Johnson wrote:
Nyx (aka arm) is undergoing a rewrite. Mind giving the new codebase a whirl?
I had a look, and I am wondering if there is any way to specify the controller password in ~/.nyx/config ? It is supported in arm, via the startup.controlPassword option in ~/.arm/armrc .
-Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 02.09.17 21:26, Damian Johnson wrote:
I dropped that since it posed a security issue.
Sigh... That seems a bit overzealous to me.
I'd suggest cookie authentication if you'd care to rely on file permissions rather than something you know. That'll work transparently.
I don't think I understand what exactly you are suggesting. Could you provide an example? I can currently do the following with 'arm', and want to it with 'nyx' as well: me@mynotebook $ ssh foo@tornode foo@tornode $ sudo -u tor /usr/bin/arm I have to enter SSH keyfile password(*) and SUDO password already, and don't want to enter yet another password for the Tor controller. Since I am the only human who can SSH to my Tor nodes, having a password in ~/.nyx/config would be a "risk" (grin) I'm perfectly willing to take. -Ralph (*) I'm aware of ssh-agent.
I'd suggest cookie authentication if you'd care to rely on file permissions rather than something you know. That'll work transparently.
I don't think I understand what exactly you are suggesting. Could you provide an example?
The ControlPort supports none, password-based and cookie-based authentication, Damian was suggesting the cookie option: https://www.torproject.org/docs/tor-manual.html.en#CookieAuthentication https://www.torproject.org/docs/tor-manual.html.en#ControlPort you can also use the control socket as suggested below
foo@tornode $ sudo -u tor /usr/bin/arm
that is not recommended, Roger tells you why: https://lists.torproject.org/pipermail/tor-relays/2016-May/009259.html using this way requires even less typing :) -- https://mastodon.social/@nusenu https://twitter.com/nusenu_
On 02.09.17 23:39, nusenu wrote:
The ControlPort supports none, password-based and cookie-based authentication, Damian was suggesting the cookie option:
https://www.torproject.org/docs/tor-manual.html.en#CookieAuthentication https://www.torproject.org/docs/tor-manual.html.en#ControlPort
Ah, I misunderstood, thanks for clarifying. I have made my SSH-user member of the Tor-user's group, added CookieAuthentication 1 CookieAuthFile /var/lib/tor/cookie_auth CookieAuthFileGroupReadable 1 to torrc, and now I can indeed run Nyx without typing a controller password. However, the following notices are displayed in Nyx: [NYX_NOTICE] We were unable to use any of your system's resolvers to get tor's connections.This is fine, but means that the connections page will be empty. This is usually permissions related so if you would like to fix this then run nyx with the same user as tor (ie, "sudo -u <tor user> nyx"). [NYX_NOTICE] Unable to query connections with netstat, trying lsof [NYX_NOTICE] Unable to query connections with proc, trying netstat Not being able to see the connections is a bit of a disadvantage. More importantly: The first notice directly contradicts the advice not to use "sudo -u tor" to run Arm or Nyx. Make up your mind, you guys. :-D I also tried using a control socket instead of a control port, alas, the parameter RelaxDirModeCheck is rejected by Tor 0.3.0.10: [warn] Failed to parse/validate config: Unknown option 'RelaxDirModeCheck'. Failing. [err] Reading config failed--see warnings above. It is documented in https://www.torproject.org/docs/tor-manual.html.en and without RelaxDirModeCheck, Tor does not start unless the directory containing the control socket is accessible only by the Tor user, so no access for anybody else, meaning once more that Arm/Nyx needs to be run as the Tor user... Deep breaths. ;-) -Ralph
On Sun, Sep 03, 2017 at 01:17:14AM +0200, Ralph Seichter wrote:
I also tried using a control socket instead of a control port, alas, the parameter RelaxDirModeCheck is rejected by Tor 0.3.0.10:
[warn] Failed to parse/validate config: Unknown option 'RelaxDirModeCheck'. Failing. [err] Reading config failed--see warnings above.
It is documented in https://www.torproject.org/docs/tor-manual.html.en
In the man page, it's listed as a flag to ControlPort. So I guess you say something like "ControlPort unix:/path/to/socket RelaxDirModeCheck" It looks like this feature went into Tor 0.2.8.2-alpha. --Roger
On 03.09.2017 02:42, Roger Dingledine wrote:
In the man page, it's listed as a flag to ControlPort.
Ouch, I did not see this last night. In my defence, I find it hard to distinguish between "options" and "flags for options" listed on the page https://www.torproject.org/docs/tor-manual.html.en even during daytime, because of the lack of distinguishing marks (same font, size, style and colour). RelaxDirModeCheck is apparently a flag, while ControlListenAddress directly below it is an option. May I suggest improving the formatting to avoid future misunderstandings? In any case, here is what works for me with Tor 0.3.0.10: CookieAuthentication 1 CookieAuthFile /var/lib/tor/cookie_auth CookieAuthFileGroupReadable 1 ControlPort unix:/run/tor/control GroupWritable RelaxDirModeCheck With this combination, all members of the Tor user's primary group can access Nyx without manually entering a controller password. Downside, as mentioned, they cannot see any currently established connections. By the way, the options above seem inconsistent to me. CookieAuthFile should have a flag like this # Feature request: GroupReadable flag CookieAuthFile /path/to/file GroupReadable instead of using the separate option CookieAuthFileGroupReadable. That would be consistent with how the ControlPort settings are specified. My thanks to Damian and Roger. -Ralph
Hi Ralph, I think there's some confusion about the ssh verses tor password. All I'm suggesting is that instead of 'HashedControlPassword' you use 'CookieAuthentication 1' in your torrc instead. This is discussed a bit on the following in case you'd care to read more... https://stem.torproject.org/faq.html#can-i-interact-with-tors-controller-int... Cheers! -Damian On Sat, Sep 2, 2017 at 2:01 PM, Ralph Seichter <m16+tor@monksofcool.net> wrote:
On 02.09.17 21:26, Damian Johnson wrote:
I dropped that since it posed a security issue.
Sigh... That seems a bit overzealous to me.
I'd suggest cookie authentication if you'd care to rely on file permissions rather than something you know. That'll work transparently.
I don't think I understand what exactly you are suggesting. Could you provide an example? I can currently do the following with 'arm', and want to it with 'nyx' as well:
me@mynotebook $ ssh foo@tornode foo@tornode $ sudo -u tor /usr/bin/arm
I have to enter SSH keyfile password(*) and SUDO password already, and don't want to enter yet another password for the Tor controller. Since I am the only human who can SSH to my Tor nodes, having a password in ~/.nyx/config would be a "risk" (grin) I'm perfectly willing to take.
-Ralph
(*) I'm aware of ssh-agent. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Oops, sorry - my bad. Didn't spot that this was already answered under a different email subject. :) On Sat, Sep 2, 2017 at 6:27 PM, Damian Johnson <atagar@torproject.org> wrote:
Hi Ralph, I think there's some confusion about the ssh verses tor password. All I'm suggesting is that instead of 'HashedControlPassword' you use 'CookieAuthentication 1' in your torrc instead. This is discussed a bit on the following in case you'd care to read more...
https://stem.torproject.org/faq.html#can-i-interact-with-tors-controller-int...
Cheers! -Damian
On Sat, Sep 2, 2017 at 2:01 PM, Ralph Seichter <m16+tor@monksofcool.net> wrote:
On 02.09.17 21:26, Damian Johnson wrote:
I dropped that since it posed a security issue.
Sigh... That seems a bit overzealous to me.
I'd suggest cookie authentication if you'd care to rely on file permissions rather than something you know. That'll work transparently.
I don't think I understand what exactly you are suggesting. Could you provide an example? I can currently do the following with 'arm', and want to it with 'nyx' as well:
me@mynotebook $ ssh foo@tornode foo@tornode $ sudo -u tor /usr/bin/arm
I have to enter SSH keyfile password(*) and SUDO password already, and don't want to enter yet another password for the Tor controller. Since I am the only human who can SSH to my Tor nodes, having a password in ~/.nyx/config would be a "risk" (grin) I'm perfectly willing to take.
-Ralph
(*) I'm aware of ssh-agent. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (5)
-
Arisbe -
Damian Johnson -
nusenu -
Ralph Seichter -
Roger Dingledine