Re: [tor-relays] [NYX_NOTICE] Relay unresponsive -- how to troubleshoot?
Hi Davin. Unfortunately I can't tell you offhand what's up, but as Nyx's author I can tell you what that message means. Nyx constantly communicates with the tor process. At the very minimum tor emits a bandwidth event each second, which means that Nyx should constantly hear from the tor process. Nyx reports that message when it hasn't heard from tor in ten seconds. This means that the tor process is struggling, usually due to resource contention (for instance pegged CPU usage). You'll need to use tor's other logs and check 'top' when tor becomes unresponsive to learn more. Cheers! -Damian On Mon, Jun 8, 2020 at 12:47 PM Davin Mertens wrote: > > I keep getting NYX_NOTICEs about "Relay unresponsive". They happen every few > hours, and last for minutes or sometimes a couple of hours before I get a > "relay resumed" message. > > But, I don't see anything in the actual Tor logs to indicate that anything is > wrong. Does anyone know how best to troubleshoot this? I think it's impacting > my consensus weight and making it drop, and is keeping me from getting the > Guard flag. > > This is the relay: > https://metrics.torproject.org/rs.html#details/94626BD21119568EB301D1E7677B272D27C20E3F > > Thanks for any tips! > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Or/Dirport Unreachable
> The Debian/Ubuntu instructions for doing this properly are listed at e.g. > https://bugs.torproject.org/25890#comment:1 > Or I'll say the updated version here: > """ > You might like to use the nyx relay monitor to watch your relay's > activities from the command line. First, "sudo apt install nyx". > Second, as the user that will be running nyx, run "sudo adduser $USER > debian-tor" to add your user to the debian-tor group so it can reach > Tor's controlsocket. Then log out and log back in (so your user is > actually in the group), and run "nyx". > """ Thanks Roger. Dumbish question but if we replace 'Then log out and log back in' with 'run "reset" in your console' will that do the trick? > We keep rearranging our docs and losing the instructions, and also > Damian (the nyx developer) has been unenthusiastic about complicating > nyx's docs with distro-specific instructions, so here we are. Nope, I'm not against providing them. Just awaiting noob friendly instructions for me to post. Nyx itself can autodetect when tor's auth cookie is owned by debian-tor and provide Debian specific instructions. If we provide the following will it be accurate? """ To connect to tor we require one more step. Please run the following and try nyx again... % sudo adduser $USER debian-tor % reset """ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] %include in torrc
Hi yl, arm and nyx's author here. "Arm" is the name of the old 1.x codebase which was last developed in 2012... https://nyx.torproject.org/changelog/index.html#version_1.x If the application says 'arm' then please upgrade. :) On Tue, Jan 7, 2020 at 3:31 PM yl wrote: > > Hello Toralf > > Depending on the OS it is called arm or nyx. > I can check the log output of tor itself, I think that is the source of the > nyx messages in the initial screen. > > Regards > yl > > > Am 7. Januar 2020 19:12:46 MEZ schrieb "Toralf Förster" > : >> >> On 1/7/20 6:36 PM, ylms wrote: >>> >>> Is arm supposed to complain about the line with the %include as "The >> >> >> IMO "arm" is deprecated in favour of "Nyx". >> > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BadExit why?
Hi Olaf, Hydra10 is evidently no longer running so we can't tell you why it got the flag. Your other Hydra* relays aren't flagged that way so I wonder how Hydra10 differs. https://metrics.torproject.org/rs.html#search/Hydra On Tue, Feb 12, 2019 at 12:30 PM Olaf Grimm wrote: > > Hello ! > > I provisioning a new exit since two hours. It is a totally new relay in > a VM. My other relays at the same provider are ok. Why I see "BadExit" > in Nyx??? Now my first bad experience with my 11 relays... > > fingerprint: CCDC4A28392C7448A34E98DF872213BC16DB27CD > Nickname Hydra10 > > At all exits I have the same firewall rules and torrc configs: > > ufw status > Status: active > > To Action From > -- -- > 22/tcp ALLOW Anywhere > 9001/tcp ALLOW Anywhere > 9030/tcp ALLOW Anywhere > 80/tcp ALLOW Anywhere > 443/tcpALLOW Anywhere > 1194/tcp ALLOW Anywhere > 53/tcp ALLOW Anywhere > 53/udp ALLOW Anywhere > 1194/udp ALLOW Anywhere > 22/tcp (v6)ALLOW Anywhere (v6) > 9001/tcp (v6) ALLOW Anywhere (v6) > 9030/tcp (v6) ALLOW Anywhere (v6) > 80/tcp (v6)ALLOW Anywhere (v6) > 443/tcp (v6) ALLOW Anywhere (v6) > 1194/tcp (v6) ALLOW Anywhere (v6) > 53/tcp (v6)ALLOW Anywhere (v6) > 53/udp (v6)ALLOW Anywhere (v6) > 1194/udp (v6) ALLOW Anywhere (v6) > > Please take a look what happens. > > Olaf > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Internal Services
> If someone on this list can take care of trac tickets directed to internal > services please contact me. Hi Sebastian. Different services are maintained by different people. Without more detail this can't be answered. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Possible problem with NYX
> There are so many edge cases for this check. > > Flags are a *recommendation* to clients. They don't force clients > to behave a certain way. > > For example: > * clients connecting via bridges can use a middle node as their > second hop. These middle nodes will leak bridge addresses via nyx. > * clients and relays can have different consensuses: > * if a relay loses the Guard flag, and finds out earlier than its clients, > nyx will stop protecting those clients > * if a client finds out before the relay, nyx won't protect those clients > * some Tor client versions don't check the guard flag at all. Others > keep their guards, even if they lose the flag > * middle and exit relays can be used as bridges, even if they don't set > BridgeRelay > * older Tor versions have a non-zero probability of choosing any relay > as an entry, even if it doesn't have the guard flag > * various config options make tor clients ignore the Guard flag > > Please only show an IP if the relay is already public in the consensus. Thanks teor, great point. Will do: https://trac.torproject.org/projects/tor/ticket/27475 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Possible problem with NYX
Hi arisbe. This isn't as concerning as you seem to think. As Nathaniel mentions it's simple to get this information, Nyx is simply attempting to scrub it cuz... well, it's ethically and legally the right thing to do. Nyx's 'should this be scrubbed' check is pretty simple [1]. Inbound addresses are scrubbed if... 1. You're configured to accept user traffic (ie. you set BridgeRelay in your torrc or have receive the Guard flag). [2] 2. The connection doesn't belong to a another tor relay. [3] Does the relay show relay information such as a fingerprint? If so then it shouldn't be scrubbed. If it doesn't and you've set BridgeRelay in your torrc then please let us know on... https://trac.torproject.org/projects/tor/wiki/doc/nyx/bugs Thanks! -Damian (author of nyx and stem) [1] https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n230 [2] https://gitweb.torproject.org/stem.git/tree/stem/control.py [3] In particular, we check if the address/port is in the consensus. On Mon, Sep 3, 2018 at 1:13 PM, arisbe wrote: > Hello ops, > > Today I noticed something on NYX that I find disturbing. Page 2 (list of > inbound/outbound connections) showed me the IP address of an inbound > connection on one of my bridges! Not the authority. This is crazy as these > are indicated as :port for the users protection! I have never > seen this before and haven't seen it since. Of course, on low usage > bridges, the connection IP address can possibly be disseminated from netstat > but that's not the point. It's my sense that this should never happen. I > get chills imagining this happening on a guard relay operated by an > antagonist ! ! > > I'm using the default NYX configuration on Ubuntu server 18.04.1 LTS, Tor > 0.3.3.9. > > Arisbe > > -- > One person's moral compass is another person's face in the dirt. > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0.4-4 on armhf - Python3 error
Ahhh! Very helpful, thanks Andrew. I'll be cutting a Stem 1.7 release soon. I'll include a fix for it. https://trac.torproject.org/projects/tor/ticket/26967 On Sat, Jul 28, 2018 at 8:23 AM, Andrew Deason wrote: > On Fri, 27 Jul 2018 11:50:57 -0700 > Damian Johnson wrote: > >> Hi Paul. Distutils should be a python builtin. Per chance did you >> compile python yourself? If so then that can sometimes exclude modules >> we expect to be there (like compression libs). > > On newer Debian/Ubuntu, it's in a separate package: > > # apt-get install python3-distutils > > -- > Andrew Deason > adea...@dson.org > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0.4-4 on armhf - Python3 error
Hi Paul. Distutils should be a python builtin. Per chance did you
compile python yourself? If so then that can sometimes exclude modules
we expect to be there (like compression libs).
On Fri, Jul 27, 2018 at 8:57 AM, Paul wrote:
> I try to run Nyx on Linux 4.9.80-Re4son-v7+ #1 SMP Thu Apr 26 17:45:16 CDT
> 2018 armv7l getting following after start:
>
>
> Traceback (most recent call last):
> File "/usr/bin/nyx", line 11, in
> load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')()
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 476,
> in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2700,
> in load_entry_point
> return ep.load()
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2318,
> in load
> return self.resolve()
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2324,
> in resolve
> module = __import__(self.module_name, fromlist=['__name__'], level=0)
> File "/usr/lib/python3/dist-packages/nyx/__init__.py", line 46, in
> import distutils.spawn
> ModuleNotFoundError: No module named 'distutils.spawn'
>
>
> Could somebody show me a way to solve this and get Nyx running?
>
> Thanks Paul
>
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] what is the Nyx "measured" bandwidth?
Hi Ron, are you sure you're using Nyx rather than the old arm codebase? I could be mistaken but my recollection (and quick read of the code) I think the graph title bar should only have 'limit', 'burst', and 'observed'. Iirc the 'measured' was removed. On Wed, Jul 4, 2018 at 1:05 PM, wrote: > Hi! > > I've been running a couple of relays for 3-4 years now. They are on > lightly-loaded 100MB/s fiber links. They have seven flags, lots of uptime, > etc. They advertise 20Mb/s, but Nyx reports: > > "measured: 22.1 Kb/s" for D76E1FDC7A3D899282BB882F74111B36A6D14B64 > > and > > "measured: 28.6 Kb/s" for 56DCA89A6B41ADA30E891EF65FDCC071DC05079B > > The graphs Nyx displays usually show around 10Mbps (but are quite variable). > > The graphs on metrics.torproject.org show the bandwidth hovering around 800 K > bytes/second. > > So why is the "measured" bandwidth from Nyx so low? > > --Ron > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Problem implementing IPv6 and NYX info
>> And, finally, a quick question: Does NYX display incoming and outgoing IPv6 >> relay information? I assume ARM does not. > > This I do not know. :) Should, but I've only tested it via mocks. Since I don't have an IPv6 relay there might be rough edges, if so then tickets welcome. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] can dirport be disabled on fallback directory?
>>Oh interesting. You're right. I recently added Stem's ORPort >>capabilities but seems I forgot to add usage examples in the docs. >>Thanks for pointing that out, I'll add it to my todo list. In the >>meantime I provided an example here... >> >>https://blog.atagar.com/april2018/ > > Thank you! > > Does a command-line utility to make such requests exist > or can one be created? The availability of a command > tool for ORPort document downloads would bring DirPort > one step closer to complete obsolesce. Hi starlight, sorry about the delay. Probably went a little overboard but this was a great idea. Here ya go... https://stem.torproject.org/tutorials/examples/download_descriptor.html ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] can dirport be disabled on fallback directory?
> There don't seem to be any examples of ORPort endpoints in the Stem > repository. I think Dave plans to add some more documentation as part of Tor > Summer of Privacy. Oh interesting. You're right. I recently added Stem's ORPort capabilities but seems I forgot to add usage examples in the docs. Thanks for pointing that out, I'll add it to my todo list. In the meantime I provided an example here... https://blog.atagar.com/april2018/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] empty exit policy if ipv6 address is not surrounded by [..]
Thanks Toralf. Took a quick peek but this is gonna require more thought. Tor's IPv6 addrspec states that policies should have brackets... https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1282 ... but the torrc is looser... https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy Stem accounts for this by adding brackets when reading from a torrc file, but requiring them from other spots through the control port. So question is 'how is nyx fetching this?'. If its coming from certain control port commands then this is a tor bug, whereas with other spots it's a stem or nyx bug. Regardless, please file a ticket for this with actual torrc lines that reproduce the issue... https://nyx.torproject.org/#report_bug On Sat, Apr 7, 2018 at 2:24 AM, Toralf Förster wrote: > Hi atagar, > > ./run_nyx > > gives an empty > > exit policy: > > line in that case - is this bug or a feature? > > :-) > > Example for a wrong line: > > ExitPolicy reject6 /32 > > Good is > > ExitPolicy reject6 []/32 > > Tested with latest stem and nyx Git trees. > > -- > Toralf > PGP C4EACDDE 0076E94E > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] stem library: huge difference between resolvers "proc" and others, eg. "netstat"
Hi Toralf. Unfortunately I don't know offhand, though I'd certainly be
curious if you find the answer. At the end of the day connection
resolvers use the proc contents, so this might be a bug in how I'm
filtering connections in Stem or maybe a bug with its underlying proc
resolver.
Unfortunately I can't troubleshoot this without a local repro. If
you'd care to dig in I'd suggest adjusting the script a little to
print the connections, then see in what way netstat differs from proc.
Is it a strict superset? Does it have duplicates? Anything about the
connections which differ that seem interesting?
Cheers! -Damian
On Wed, Mar 7, 2018 at 2:25 PM, Toralf Förster wrote:
> I do wonder about the differences of "proc" versus the other 3 ("netstat,
> "lsof" and "ss") related to the Inbound/Outbound values at my Tor relay.
> As an example I copied below the output of "proc" and "netstat".
> Does anybody have a clue about those differences?
>
>
>
> mr-fox ~ # python ~/stem/docs/_static/example/relay_connections.py --ctrlport
> 9051 --resolver proc
> 0.3.4.0-alpha-dev uptime: 06:48:29 flags: Exit, Fast, Guard, Running,
> Stable, V2Dir, Valid
>
> +--+--+--+
> | Type | IPv4 | IPv6 |
> +--+--+--+
> | Inbound to our ORPort| 2107 |6 |
> | Inbound to our DirPort | 15 |0 |
> | Outbound to a relay | 1753 |0 |
> | Outbound exit traffic| 155 | 302 |
> | Outbound uncategorized | 119 |0 |
> +--+--+--+
> | Total| 4149 | 308 |
> +--+--+--+
>
> +--+--+--+
> | Exit Port| IPv4 | IPv6 |
> +--+--+--+
> | 80 (HTTP)| 111 | 61 |
> | 143 (IMAP) |1 |0 |
> | 443 (HTTPS) |0 | 229 |
> | 465 (SMTP) |1 |0 |
> | 993 (IMAPS) | 13 |0 |
> | 5222 (Jabber)|8 |2 |
> | 5223 (Jabber)|6 |0 |
> | |1 |0 |
> | 8080 (HTTP Proxy)|4 |4 |
> | 8333 (Bitcoin) |2 |2 |
> | (NewsEDGE) |2 |0 |
> | 50002 (Electrum Bitcoin SSL) |6 |4 |
> +--+--+--+
> | Total| 155 | 302 |
> +--+--+--+
>
> mr-fox ~ # python ~/stem/docs/_static/example/relay_connections.py --ctrlport
> 9051 --resolver netstat
> 0.3.4.0-alpha-dev uptime: 06:48:41 flags: Exit, Fast, Guard, Running,
> Stable, V2Dir, Valid
>
> +--+--+--+
> | Type | IPv4 | IPv6 |
> +--+--+--+
> | Inbound to our ORPort| 4883 |6 |
> | Inbound to our DirPort | 35 |0 |
> | Inbound to our ControlPort |1 |0 |
> | Outbound to a relay | 4174 |0 |
> | Outbound exit traffic| 390 | 293 |
> | Outbound uncategorized | 267 |0 |
> +--+--+--+
> | Total| 9750 | 299 |
> +--+--+--+
>
> +--+--+--+
> | Exit Port| IPv4 | IPv6 |
> +--+--+--+
> | 80 (HTTP)| 300 | 68 |
> | 110 (POP3) |1 |0 |
> | 143 (IMAP) |4 |0 |
> | 443 (HTTPS) |0 | 214 |
> | 465 (SMTP) |1 |0 |
> | 1883 |1 |0 |
> | 3128 (SQUID) |1 |0 |
> | 5222 (Jabber)| 21 |2 |
> | 5223 (Jabber)| 18 |0 |
> | 6667 (IRC) |4 |0 |
> | |2 |0 |
> | 8080 (HTTP Proxy)| 14 |3 |
> | 8333 (Bitcoin) |8 |2 |
> | (NewsEDGE) |3 |0 |
> | 50002 (Electrum Bitcoin SSL) | 12 |4 |
> +--+--+--+
> | Total| 390 | 293 |
> +--+--+--+
>
>
> --
> Toralf
> PGP C4EACDDE 0076E94E
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit Relay
> Sorry, I meant to write "connection getinfo". > > And I'm not sure that the original reasoning applies: if Stem is getting the > information from other sources anyway, why don't we just provide it > through Tor? Ah! Gotcha. No argument from me. > Its worth noting that I have seen circuits on arm / nyx as part of reach > ability tests like this (ref: > https://trac.torproject.org/projects/tor/ticket/12956): > > 76.99.61.63--> 188.138.17.248 (fr) 3.1m (CIRCUIT) > │ 83.168.200.204 (se) ParadiseTorRelay1 1 / Guard > │ 18.181.5.37 (us) VERITAS 2 / Middle > └─ 188.138.17.248 (fr) EuropeCoastDE 3 / Exit > > However this is the first time arm has shown me "exit" connections like list > on first email. Hi Gary, *this* is the thing Roger was talking about. With Nyx this should be labeled as 'End' rather than 'Exit' to cut down on the understandable concern the later term causes. :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit Relay
> A circuit getinfo sounds like a great feature. I'd be happy to review > a proposal, but I'm not sure I'd have time to implement it. No worries! As mentioned, we already have a proposal. Eight years ago Nick encouraged me to write proposals for things I'd find helpful, but of course a proposal doesn't magically turn into engineering resources. We all have things on our plate, and there's no point in spending time writing proposals unless it's gonna turn into something. :) Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit Relay
> Does Tor export a list of connections over the control port? Hi teor. Nope, tor doesn't. That's something I wanted many years ago and I made a proposal, but Jake talked me into limiting it to circuits instead... https://gitweb.torproject.org/torspec.git/tree/proposals/172-circ-getinfo-option.txt Having tor provide this would be very helpful. Stem vends nine different connection resolvers because it doesn't. ;P https://gitweb.torproject.org/stem.git/tree/stem/util/connection.py Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit Relay
Hi Roger, I don't think thats' the issue here. The lines they cited were exit connections, not the 'Exit' circuit lines (the later look different and don't include scrubbing). For what it's worth here's where Nyx decides to label a connection as being an exit. The conditional is "if I can't resolve this to a relay and our exit policy allows exiting to it then label as an exit"... https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n225 > I switched to nyx and it is fine allthough on deeper inspection the IP to > is actually my IP so clearly this is a bug. Hi Gary. Sorry, not sure I follow. Are you saying Nyx (not arm) is labeling these as 'Outbound' but still scrubbing the address? Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit Relay
Oops! Actually, this would happen with Nyx too. This is a Stem bug... https://trac.torproject.org/projects/tor/ticket/25423 Thanks for the catch! On Mon, Mar 5, 2018 at 2:49 AM, teor wrote: > > >> On 5 Mar 2018, at 21:02, Gary wrote: >> >> Hello. >> >> I have configured my relay (jaffacakemonster2) to be non exit, however arm >> shows me the following (I edited out IPs' & some lines after copy/paste from >> connection screen for others security / brevity) >> >> Connections (1878 inbound, 2113 outbound, 19 exit, 1 control) >> IP--> :443 (HTTPS) UNKNOWN >> UNKNOWN 3.5m (EXIT) >> IP--> :443 (HTTPS) UNKNOWN >> UNKNOWN 3.5m (EXIT) >> IP--> :443 (HTTPS) UNKNOWN >> UNKNOWN 3.5m (EXIT) >> IP--> :443 (HTTPS) UNKNOWN >> UNKNOWN 3.4m (EXIT) >> IP--> :4000 UNKNOWN >> UNKNOWN 3.5m (EXIT) >> IP--> :9001 UNKNOWN >> UNKNOWN 3.5m (EXIT) >> IP--> :9001 UNKNOWN >> UNKNOWN 3.5m (EXIT) >> IP--> :9001 UNKNOWN >> UNKNOWN 3.5m (EXIT) >> IP--> :9001 UNKNOWN >> UNKNOWN 3.4m (EXIT) >> IP--> :9001 UNKNOWN >> UNKNOWN 1.0m (EXIT) >> IP--> :26155UNKNOWN >> UNKNOWN 3.5m (EXIT) >> >> Atlas reports the flags Fast, Running & Valid. >> >> Lines as copied & pasted from torrc: >> >> ## Uncomment this if you do *not* want your relay to allow any exit traffic. >> ## (Relays allow exit traffic by default.) >> ExitRelay 0 >> >> What is going on here? I am confused as to why there is exit connections but >> I am not / dont want an exit relay. > > I think this is a bug in arm. > Try nyx. > > T > > -- > teor > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > > > > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Api for atlas.torproject.org
> Or any other easier way to do it in like python :)
Here ya go. This downloads the consensus so if you're gonna be doing
more than an occasional one-off check you should use the suggestions
from teor.
import sys
import stem.descriptor.remote
def is_exit(address):
for desc in stem.descriptor.remote.get_consensus():
if 'Exit' in desc.flags and address == desc.address:
return True
return False
if __name__ == '__main__':
if len(sys.argv) < 2:
print('You need to provide an address to check.')
elif is_exit(sys.argv[1]):
print('%s is a tor exit.' % sys.argv[1])
else:
print('%s is not a tor exit.' % sys.argv[1])
% python demo.py 199.58.81.140
199.58.81.140 is not a tor exit.
% python demo.py 154.16.149.74
154.16.149.74 is a tor exit.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.
> So it seems to be something python2/python3 related. I'm not sure why I used > python3 to be honest. Interesting. Can't say there's anything that comes straight to mind that would cause that. I'd expect python2 and python3 to behave the same on this front. > P.S. If you want the logs, do you mind if I send them directly? Then I don't > have to remove all the other tor node details, which is quite a lot that > flies by (so this doesn't end up in the public archives - even-though it's > public info anyway). Of course. I didn't mean to encourage you to send the logs to the list. :) Considering your find above the most useful logs would be the working Debian python2 verses the broken Debian python3. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.
Hi Stijn, my first thought is that this might be tor's DisableDebuggerAttachment feature. It causes proc contents to only be readable by root. Usually this breaks Nyx's connection resolution but it can prevent resource usage lookups too. Does setting 'DisableDebuggerAttachment 0' in your torrc cause the data to appear? If not then the next step is to take a peek at the debug logs. If you send me the logs on both platforms with any data you feel is sensitive redacted I'd be happy to take a peek. I only need the first five seconds or so of logs (just need to see the first resource resolution attempt). Cheers! -Damian On Sat, Feb 3, 2018 at 2:10 PM, Stijn Jonker wrote: > Hi All, > > I initially went to the nyx website to find the right forum to ask > questions. I understood this is the one :-), if not apologies. > > So I'm running two relays, one is running on CentOS7, the other Debian > Stretch. On both I have nyx (2.0.4) installed. The "Debian" one is missing > the CPU, Exit policy etc info. It's not tor version specific, as I recently > upgraded the tor software on the nodes regularly. > > So on the CentOS node I see this on the top at the right; > cpu: 61.3% tor, 5.0% nyx mem: 371 MB (12.4%) pid: 1279 uptime: 02:59:09 > fingerprint: 328E54981C6DDD7D89B89E418724A4A7881E3192 > exit policy: reject *:* > > On the Debian node it's simply not printing any of these three lines. I > can't find in the (debug) logging whether an utility or library is missing. > It's nothing major, but annoying. Especially with the new alpha releases > it's nice to keep an eye out on mem/cpu. > > Does anyone have an idea what the trick is to get it to work on debian? > > -- CentOS info: > [user@tornode ~]$ tor --version > Tor version 0.3.3.1-alpha (git-de8bc9eed6eaadfc). > > [user@tornode ~]$ nyx --version > nyx version 2.0.4 (released November 5, 2017) > > [user@tornode ~]$ uname -a > Linux tornode.sjc.nl 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 > UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > > -- Debian info: > [maint@tornode2 ~]$ tor --version > Tor version 0.3.3.1-alpha-dev (git-9e48338a12fd1fef+0f23e7e96). > > [user@tornode2 ~]$ nyx --version > nyx version 2.0.4 (released November 5, 2017) > > [user@tornode2 ~]$ uname -a > Linux tornode2 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) > x86_64 GNU/Linux > > [user@tornode2 ~]$ lsb_release -c > Codename: stretch > > Thx, > Stijn > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] nyx no connections shown
Hi John, simply run 'nyx --debug' as discussed with Arisbe on this thread. [1] https://lists.torproject.org/pipermail/tor-relays/2018-January/014173.html On Wed, Jan 17, 2018 at 9:18 AM, John D. McDonnell wrote: > What logs do you need? I only logging at notice level in tor, so they're not > any help. > > -- > John McDonnell > > -Original Message- > From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf > Of Damian Johnson > Sent: Wednesday, January 17, 2018 10:58 AM > To: tor-relays@lists.torproject.org > Subject: Re: [tor-relays] nyx no connections shown > > Hi John, I require the redacted logs to be able to help at all. > > > On Wed, Jan 17, 2018 at 6:32 AM, John D. McDonnell wrote: >> Logged back in to check on it again this morning, and nyx is back to not >> displaying any connections on the 2nd page. >> >> -- >> John McDonnell >> >> -Original Message- >> From: John D. McDonnell >> Sent: Tuesday, January 16, 2018 9:25 PM >> To: 'tor-relays@lists.torproject.org' >> Subject: RE: [tor-relays] nyx no connections shown >> >> Just updated FreeBSD and updated tor to 0.3.2.9 and rebooted the whole >> server and nyx is working properly again. I'm thinking something was hanging >> in the background or something that the reboot fixed, though I'm not sure >> what it could have been. (Python and nyx are still the same versions, so I'm >> thinking my updates didn't fix it but the reboot fixed whatever was hung in >> the background. Maybe I'll check on my other relay to see if I can figure >> out what specifically is causing it to not show connections.) >> >> -- >> John McDonnell >> >> -Original Message- >> From: John D. McDonnell >> Sent: Tuesday, January 16, 2018 8:02 PM >> To: 'tor-relays@lists.torproject.org' >> Subject: RE: [tor-relays] nyx no connections shown >> >> Nyx was working fine until sometime last week when I had the same issue >> where the connection page was suddenly blank. It came back a while later but >> then went blank again. I just checked again and the connections page is >> still coming up as blank. I'm also on FreeBSD running tor 0.3.1.9. >> >> FreeBSD 11.1-RELEASE-p4 >> tor-0.3.1.9_1 >> python27-2.7.14_1 >> py27-nyx-2.0.4 >> >> I'm not sure when exactly I noticed the connections page started showing up >> as blank as I usually only spot check the first page and maybe check the >> notices.log file. >> >> I'm going to check for updates and then see what happens after. >> >> -- >> John McDonnell >> >> -Original Message- >> From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf >> Of TorGate >> Sent: Monday, January 15, 2018 7:14 PM >> To: tor-relays@lists.torproject.org >> Subject: Re: [tor-relays] nyx no connections shown >> >> Thank you, its working :-) >> But can i also show connections ? >> >> Steffen >> >> >> >> >> >> Am 15.01.2018 um 23:49 schrieb Damian Johnson > <mailto:ata...@torproject.org> >: >> >> Thanks Arisbe! This is useful. >> >>> 1) nyx is way slow to start up. Sometimes taking 20 seconds to come >>> visible. The contacts page (page 2) does come up eventually but sometimes >>> takes 10 minutes; >> >> >> Weird. Nyx should be quicker in that respect than the old arm codebase. >> Please run 'nyx --debug' and send me the debug log, minus anything you think >> is sensitive. >> >>> 2) the inbound and outbound connections on page two are listed by IP only >>> and not sorted by inbound/outbound; >> >> >> Not sure I follow. Is this purely a sorting issue or are inbound/outbound >> not properly labeled? This is something a screenshot might help with. >> >>> 3) IP addresses do not have country identification but rather all just >>> have (??); >> >> >> Hopefully the debug log will help with this too. This should be coming from >> tor. >> >>> 4) nyx rejects some of the options in nyxrc >> >> >> Yup, the nyxrc options are different from the old armrc. They're listed on... >> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnyx.torproject.org%2F%23configuration&data=02%7C01%7C%7Ca256bea416dd493a69d108d55dc441dd%7C4d0a72eeba2646d58bbe6430f01b636a%7C0%7C0%7C636518019875476846&sdata=g%2B38U4%2BpgV21I9V4ENHnlv1qKqj
Re: [tor-relays] nyx no connections shown
Hi John, I require the redacted logs to be able to help at all. On Wed, Jan 17, 2018 at 6:32 AM, John D. McDonnell wrote: > Logged back in to check on it again this morning, and nyx is back to not > displaying any connections on the 2nd page. > > -- > John McDonnell > > -Original Message- > From: John D. McDonnell > Sent: Tuesday, January 16, 2018 9:25 PM > To: 'tor-relays@lists.torproject.org' > Subject: RE: [tor-relays] nyx no connections shown > > Just updated FreeBSD and updated tor to 0.3.2.9 and rebooted the whole server > and nyx is working properly again. I'm thinking something was hanging in the > background or something that the reboot fixed, though I'm not sure what it > could have been. (Python and nyx are still the same versions, so I'm thinking > my updates didn't fix it but the reboot fixed whatever was hung in the > background. Maybe I'll check on my other relay to see if I can figure out > what specifically is causing it to not show connections.) > > -- > John McDonnell > > -Original Message- > From: John D. McDonnell > Sent: Tuesday, January 16, 2018 8:02 PM > To: 'tor-relays@lists.torproject.org' > Subject: RE: [tor-relays] nyx no connections shown > > Nyx was working fine until sometime last week when I had the same issue where > the connection page was suddenly blank. It came back a while later but then > went blank again. I just checked again and the connections page is still > coming up as blank. I'm also on FreeBSD running tor 0.3.1.9. > > FreeBSD 11.1-RELEASE-p4 > tor-0.3.1.9_1 > python27-2.7.14_1 > py27-nyx-2.0.4 > > I'm not sure when exactly I noticed the connections page started showing up > as blank as I usually only spot check the first page and maybe check the > notices.log file. > > I'm going to check for updates and then see what happens after. > > -- > John McDonnell > > -Original Message- > From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf > Of TorGate > Sent: Monday, January 15, 2018 7:14 PM > To: tor-relays@lists.torproject.org > Subject: Re: [tor-relays] nyx no connections shown > > Thank you, its working :-) > But can i also show connections ? > > Steffen > > > > > > Am 15.01.2018 um 23:49 schrieb Damian Johnson <mailto:ata...@torproject.org> >: > > Thanks Arisbe! This is useful. > >> 1) nyx is way slow to start up. Sometimes taking 20 seconds to come >> visible. The contacts page (page 2) does come up eventually but sometimes >> takes 10 minutes; > > > Weird. Nyx should be quicker in that respect than the old arm codebase. > Please run 'nyx --debug' and send me the debug log, minus anything you think > is sensitive. > >> 2) the inbound and outbound connections on page two are listed by IP only >> and not sorted by inbound/outbound; > > > Not sure I follow. Is this purely a sorting issue or are inbound/outbound not > properly labeled? This is something a screenshot might help with. > >> 3) IP addresses do not have country identification but rather all just have >> (??); > > > Hopefully the debug log will help with this too. This should be coming from > tor. > >> 4) nyx rejects some of the options in nyxrc > > > Yup, the nyxrc options are different from the old armrc. They're listed on... > > https://nyx.torproject.org/#configuration > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnyx.torproject.org%2F%23configuration&data=02%7C01%7C%7Caa6bedc69ca04acb280908d55c76131d%7C4d0a72eeba2646d58bbe6430f01b636a%7C0%7C0%7C636516584561576746&sdata=63h7wDPnpf1ATZWjivaoHM%2Bx0gqx%2F7eQcw3E0GxP7nc%3D&reserved=0> > >> 5) There is no man page for nyx. > > > Actually, there is. > > https://gitweb.torproject.org/nyx.git/tree/nyx.1 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitweb.torproject.org%2Fnyx.git%2Ftree%2Fnyx.1&data=02%7C01%7C%7Caa6bedc69ca04acb280908d55c76131d%7C4d0a72eeba2646d58bbe6430f01b636a%7C0%7C0%7C636516584561576746&sdata=Zn4uJiRKtphBf96feG9jRK4UAadqMvEzGZx8bDLYv6I%3D&reserved=0> > > > Arm attempted to guess where to install it when you ran 'python setup.py > install' but doing so caused problems. Unfortunately the path man pages are > located at varies by the platform so I now leave it up to package managers > (yum, emerge, etc). Are you on Debian or Ubuntu? That's the most common pain > point right now - a package will hopefully be available for those soonish. > > > Cheers! -Damian > > ___
Re: [tor-relays] The Onion Box v4.1
>> Hi is there an option to show connections in theonionbox ? > > Sorry... currently not! Hi Ralph. For what it's worth since Onion Box already uses Stem you can get the connection data via... https://stem.torproject.org/tutorials/east_of_the_sun.html#connection-resolution Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] nyx no connections shown
Thanks Arisbe! This is useful. > 1) nyx is way slow to start up. Sometimes taking 20 seconds to come visible. The contacts page (page 2) does come up eventually but sometimes takes 10 minutes; Weird. Nyx should be quicker in that respect than the old arm codebase. Please run 'nyx --debug' and send me the debug log, minus anything you think is sensitive. > 2) the inbound and outbound connections on page two are listed by IP only and not sorted by inbound/outbound; Not sure I follow. Is this purely a sorting issue or are inbound/outbound not properly labeled? This is something a screenshot might help with. > 3) IP addresses do not have country identification but rather all just have (??); Hopefully the debug log will help with this too. This should be coming from tor. > 4) nyx rejects some of the options in nyxrc Yup, the nyxrc options are different from the old armrc. They're listed on... https://nyx.torproject.org/#configuration > 5) There is no man page for nyx. Actually, there is. https://gitweb.torproject.org/nyx.git/tree/nyx.1 Arm attempted to guess where to install it when you ran 'python setup.py install' but doing so caused problems. Unfortunately the path man pages are located at varies by the platform so I now leave it up to package managers (yum, emerge, etc). Are you on Debian or Ubuntu? That's the most common pain point right now - a package will hopefully be available for those soonish. Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx reported speed
Thanks John, glad to hear the average is more in line. Sorry if you're already aware of this but here's a nice read that might help... https://blog.torproject.org/lifecycle-new-relay It can take a long while for the bandwidth authorities to warm up to relays. If you're seeing slack in a new-ish relay that's likely it. On Mon, Jan 8, 2018 at 12:27 PM, John D. McDonnell wrote: > Sorry for top posting, but I don't have my mail client configured for a more > proper inline or bottom posting. (I did that when I first got here but was > forced to change it to appease my boss.) > > The average metric you are referring to is the one that is updated with the > bar graph correct? That one does show more promising numbers, but still > generally still tends to fall far short of my 500KB/s allocation. (Seems to > usually be from 70B/s to 250KB/s with bursts higher.) But if this is the > actual rates I'm getting, then I am going to have to assume I've either got > something configured wrong or my routers aren't allowing my servers to get up > to full speed. (Both are probably equally likely. lol) > > Thank you for clearing that up though, I've been quite perplexed by it > reporting only B/s instead of KB/s for the average. > > -- > John > > -Original Message----- > From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf > Of Damian Johnson > Sent: Monday, January 8, 2018 3:10 PM > To: tor-relays@lists.torproject.org > Subject: Re: [tor-relays] Nyx reported speed > > Sorry about the confusion! Nyx should be showing an average metric as well > which is based on the samplings it sees. *That* should be more helpful. > > Cheers! -Damian > > > Penn Cambria School District > > This e-mail and any files transmitted with it are confidential and intended > only for the person or entity to which it is addressed. If you have received > this email in error, please notify the sender immediately via email and > delete this email along with any attachments from your system. Any > unauthorized or improper disclosure, copying, distribution, or use of the > contents of this e-mail and attached documents is strictly prohibited. The > views and opinions of this email or attachments are reflections of the author > and are not necessarily the views and opinions of Penn Cambria School > District. We do not accept responsibility or liability for any loss or damage > from the receipt of this email, its use, or for any errors or omissions. > > www.pcam.org<http://www.pcam.org> > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx reported speed
Hi John, thanks for pointing this out! Just took a quick peek at the source and the 'measured: x' comes from your relay's consensus entry. On reflection though that's stupid of me since that's the bandwidth authority weight which is a unit-less heuristic (baka!). https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2234 I should probably simply drop that from the interface. Filed a ticket to remind me to do so... https://trac.torproject.org/projects/tor/ticket/24832 Sorry about the confusion! Nyx should be showing an average metric as well which is based on the samplings it sees. *That* should be more helpful. Cheers! -Damian On Mon, Jan 8, 2018 at 10:56 AM, John D. McDonnell wrote: > I'm not sure if reporting is off or something isn't configured right or > whatever it could be, but when running nyx, it is telling me that the > measured rate is 229.0 B/s which to me, sounds ridiculously slow. Where is it > getting the measured rate from? Is it a calculation on how much data is > passing in a given time or some sort of speed test from another relay or > where? While I've used Tor off and on for several years, I never ran a relay > until now and I'm still not certain on several aspects, though I keep digging > to make sure I can supply the best exit relays I can. (I currently host 2 > exit relays and hope to bring up 3 more in the near future if I can find > hardware to run them on. Though I may make one a bridge.) > > I have some spare internet connections that are provided to us that are 25/5 > connections. I configured torrc with a 500KB/s limit with 600KB/s bursting as > this should work nicely to use ~4Mbps of the 5Mbps that the connection > supports and allows me some bandwidth to be able to connect to the machines > for monitoring and troubleshooting as well as more than enough bandwidth for > downloading updates and such. > > The line in nyx that I'm referring to is: > Bandwidth (limit: 500 KB/s, burst: 600 KB/s, measured: 229.0 B/s): > Where is it getting that 229.0 B/s rate and is there anything I can do to get > it closer to the 500KB/s I am trying to share. > > Granted, I am using a Linksys e1200 and Belkin something-or-other that I > can't remember off the top of my head running DD-WRT as routers in front of > the servers. (I've pondered removing the router and just connecting the > server directly to the internet and relying on pf for my firewalling, but I > can't do that at the one location as I also have a couple other things > connected to it. Both routers are higher end consumer routers with 32MB of > RAM and has 32768 for maximum ports. (Currently just under 3000 active IP > connections as I'm typing this e-mail.) I might just try this on my one exit > to see if this is the bottleneck I'm hitting or if there's something else > affecting it. > > When I had first put this in place, I was using an older Netgear ProVPN > router of some sort, but I swapped it out due to it flagging NTP traffic as > unknown even though my server was initiating the NTP requests. But I was > maintaining 200KB/s+ connections fairly consistently. It now ranges all over > the place and I'm not sure if that's an issue on my end or just part of the > lifecycle of a relay. > > I just recently rebooted the machine this happened to pop up in the nyx log > window as I was looking at this: > 12:33:09 [NOTICE] Heartbeat: Tor's uptime is 4 days 23:59 hours, with 1928 > circuits open. I've sent 37.89 GB and received 37.00 GB. > To me, that seems a too low, but I've not sat down to do the math and maybe > that's a good statistic for 5 days at 4Mbps. > > I'd appreciate any tips and pointers you can send my way. And if the consumer > routers are the issue, I can move my one exit relay to one of the other > connections I have and not use it at the location (or just run one that's > slower) where I do use this backup internet connection. (It's handy to have a > network that's not part of our internal network for testing.) > > Thanks for sticking with me through this whole e-mail and I apologize for > rambling and jumping around a bit. I'm sure I left out some stuff and didn't > clarify something else or something wasn't clear, so if you need more > information, just ask. > > Thank you, > John > > > Penn Cambria School District > > This e-mail and any files transmitted with it are confidential and intended > only for the person or entity to which it is addressed. If you have received > this email in error, please notify the sender immediately via email and > delete this email along with any attachments from your system. Any > unauthorized or improper disclosure, copying, distribution, or use of the > contents of this e-mail and attached documents is strictly prohibited. The > views and opinions of this email or attachments are reflections of the author > and are not necessarily the views and opinions of Penn Cambria School > District. We do not accept responsibility or
[tor-relays] Please disregard 'excessive bounce' notice
Hi all. Everyone with a gmail account not a notice that their subscription was suspended due to excessive bounces. You can ignore this notice, no action is needed on your part. I'm not entirely sure of the root cause but something similar happened a few years back with another list too. I've disabled automated bounce processing and re-enabled everyone's subscription. Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0 Release
> Oh, that's big; I missed that. So Nyx gives you real-time information on > your individual relay, and less about the network overall? Correct. Atlas provides a website where you can look up general information on any relay, whereas Nyx provides detailed real-time information about your relay. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0 Release
> I'll definitely crib off that. > > There's overlap between what data Nyx displays with what Tor Metrics > displays, right? Kinda? Nyx has much, much richer information. Atlas gets hourly information. Nyx's info is both real time and far, far more detailed. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0 Release
Hi Stephanie, will this do the trick? http://blog.atagar.com/nyx-release-2-0/ On Tue, Nov 7, 2017 at 10:02 AM, Stephanie Whited wrote: > Glad we'll have a post up about this! > > Damian, do you want to write a draft and we can help polish or would you > like Tommy to write a draft first and get your feedback? > > -Steph > > > On 11/7/17 9:56 AM, Damian Johnson wrote: > > Thanks Tommy! Actually, I was just about to reach out to Stephanie to > ask how she would care to proceed with a tor blog post. Love to have > your professional touch on this Tommy. :P > > Cheers! -Damian > > On Tue, Nov 7, 2017 at 9:51 AM, Tommy Collison > wrote: > > Congrats on the launch, Damian! > > Want to write up something quick for the blog? If you want, I can pull > something together and run it by you. > > Tommy > > On 11/6/17 3:41 PM, Damian Johnson wrote: > > Hi all, after years of being in the works I'm pleased to announce Nyx! > A long overdue modernization of arm. > > http://blog.atagar.com/nyx-release-2-0/ > https://nyx.torproject.org/ > > Even more important for our controller space at large, Nyx is coming > hand-in-hand with Stem 1.6. A full year of improvements that include > descriptor creation support, ed25519 certificates, performance tuning, > and much, much more... > > https://stem.torproject.org/change_log.html#version-1-6 > > Cheers! -Damian > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > -- > Stephanie A. Whited > Communications Director > The Tor Project ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0 Release
Thanks Tommy! Actually, I was just about to reach out to Stephanie to ask how she would care to proceed with a tor blog post. Love to have your professional touch on this Tommy. :P Cheers! -Damian On Tue, Nov 7, 2017 at 9:51 AM, Tommy Collison wrote: > Congrats on the launch, Damian! > > Want to write up something quick for the blog? If you want, I can pull > something together and run it by you. > > Tommy > > On 11/6/17 3:41 PM, Damian Johnson wrote: >> Hi all, after years of being in the works I'm pleased to announce Nyx! >> A long overdue modernization of arm. >> >> http://blog.atagar.com/nyx-release-2-0/ >> https://nyx.torproject.org/ >> >> Even more important for our controller space at large, Nyx is coming >> hand-in-hand with Stem 1.6. A full year of improvements that include >> descriptor creation support, ed25519 certificates, performance tuning, >> and much, much more... >> >> https://stem.torproject.org/change_log.html#version-1-6 >> >> Cheers! -Damian >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0 Release
> Thank you for all your work. It is good to have a TTY-only tool > available again. Thanks Ralph! > Either I am too tired to see it, or the new web shows no info about the > installation process. Your blog mentions "pip install nyx" very briefly, > but the web page apparently does not? Also, it might be worth mentioning > alternatives to using pip. If you click 'Download' in the upper right of https://nyx.torproject.org/ it should provide the pip command. I reached out to package maintainers yesterday and will list other platforms once they're available, like we do for Stem: https://stem.torproject.org/download.html Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Nyx 2.0 Release
Hi all, after years of being in the works I'm pleased to announce Nyx! A long overdue modernization of arm. http://blog.atagar.com/nyx-release-2-0/ https://nyx.torproject.org/ Even more important for our controller space at large, Nyx is coming hand-in-hand with Stem 1.6. A full year of improvements that include descriptor creation support, ed25519 certificates, performance tuning, and much, much more... https://stem.torproject.org/change_log.html#version-1-6 Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> Yeah, that fixed it. :) Great, thanks for reporting it! \o/ > Before reading your last email, I tried removing "DisableDebuggerAttachment > 0". That actually made things worse. The connections weren't showing at all, > even after waiting 5 minutes. It may be the same underlying issue that you > just fixed, but thought I'd mention it. (I'd test it again, but that > particular config option requires a hard restart of the Tor service, so I'm > going to leave it alone for now). Yup, that's expected. Generally Nyx no longer requires folks to set 'DisableDebuggerAttachment 0' *but* that requires /proc contents that aren't available on OSX or BSD. ... pity. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
>> After pulling in the latest nyx/stem changes, nyx seems to be taking much >> longer for connections to appear in the Connections pane. After switching to >> that view the first time, it's taking about 30 seconds to load the list. >> Once it's loaded I can switch panes and come back and the list is still >> populated. It's not really critical but it does seem to have changed with >> recent commits. This is on FreeBSD. > > Hi, do you have 'DisableDebuggerAttachment 0' in your torrc? If so > then a recent change I made could indeed account for this... > > https://gitweb.torproject.org/nyx.git/commit/?id=b801d16 > > Unfortunately that makes the connection panel appear sooner for others. :/ Oh wait! I'm being dumb. This is indeed a bug and I know what's up. Mind pulling nyx and trying again? https://gitweb.torproject.org/nyx.git/commit/?id=08dbde2 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> After pulling in the latest nyx/stem changes, nyx seems to be taking much > longer for connections to appear in the Connections pane. After switching to > that view the first time, it's taking about 30 seconds to load the list. > Once it's loaded I can switch panes and come back and the list is still > populated. It's not really critical but it does seem to have changed with > recent commits. This is on FreeBSD. Hi, do you have 'DisableDebuggerAttachment 0' in your torrc? If so then a recent change I made could indeed account for this... https://gitweb.torproject.org/nyx.git/commit/?id=b801d16 Unfortunately that makes the connection panel appear sooner for others. :/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> "Menu" -> "Exit" works here under Gentoo now, but "q" -> "q" still not, after > Ctrl-C I do get : Hi Toralf, that's really puzzling. The menu and 'q' keys should do the same thing. Just took a peek at the code and I can't spot a sizable difference. Just tried again a few times to repro but no luck. As mentioned earlier... > Per chance were you logging at the DEBUG runlevel at that time? On a > busy relay the amount of messages that slams the control port with can > make it slow to shut down. Unfortunately besides that I'm at a loss > for why it gets stuck for you. Looking at your debug logs would be the > next step. Happy to discuss it off list if that would be ok. That stacktrace indicates that Stem is getting stuck while waiting for the control socket to close. Nothing about it is Nyx specific so wonder if we'd be able to repro the issue with Stem's integ tests... https://stem.torproject.org/faq.html#how-do-i-run-the-tests Mind giving those a whirl to see if they provide a consistent repro? Since there's only a single report of this think I'll move forward with a release but I'd love to sort this out if we're able to get a good repro case to troubleshoot. Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Damn that was a lot of helpful feedback - thank you all! From what I can tell we should have fixes in for all the issues folks spotted. If I missed anything then please let me know. Otherwise I'll move forward with announcing our long belated release this weekend. Cheers! -Damian On Mon, Oct 30, 2017 at 12:35 PM, Damian Johnson wrote: > Hi all! After five years Nyx (previously known as arm) is getting > a far belated update. Under the covers the whole codebase has been > rewritten from scratch, but for users things look much the same. > One of those cases where... > > "When you do things right, people won't be sure you've done > anything at all." -Futurama > > Main changes are... > > * Python 3.x support. > > * New website: https://nyx.torproject.org/ > > * Bandwidth graph now prepopulates when you start up, so you > have a graph right away. > > * Connections are now available without togging > DisableDebuggerAttachment in your torrc. > > * Support for showing IPv6 connections. > > * Dialog for picking tor events to log, rather than an arcane > letter flag input. > > * Improved efficiency of log deduplication by multiple orders > of magnitude. As such verbose logs no longer peg your CPU. > > * Richer control interpreter, including a python prompt like > IDLE. > > * Removed features that frequently confused users such as the > relay setup wizard and torrc validation. > > * Modernized dependencies. Nyx now uses Stem rather than TorCtl > (which was deprecated in 2011). > > Our ducks should finally be in a row for release, but this being > a full rewrite I'd like to start with an open beta to work out > anything I might have missed. > > Would relay operators mind giving Nyx a whirl? To give it a try > simply ensure you have a control port available in your torrc... > > ControlPort 9051 > CookieAuthentication 1 > > ... and run the following... > > % 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 > > Thanks! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> New issue - again I only have one machine running, so I don't know if it is > just my problem - > page 2: Inbound connections in nyx look like this: > │ IP:51396 (??) --> my ip:8443 + 3.7m (INBOUND) > Arm shows me the country name instead of (??). Thanks torix. Unfortunately I don't have tor's geoip db for either of the tor instances I'm testing on. Would you mind sending me your debug log off-list (scrubbed of anything you consider secret)? I'd like to see what it says about the ip-to-country queries. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> But to be clear, nyx still does not show the accounting lines that arm does. Ah! Found it, accounting stats fixed. Thanks for pointing this out! https://gitweb.torproject.org/nyx.git/commit/?id=6e9efcb ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> More specifically (now that I know about the S menu), the Accounting lines > only appear with the Bandwidth selected. Ahhh! Gotcha. Yes, it's intended for accounting information to only be present when showing the bandwidth graph. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Hi torix. > 1) I don't have any line showing Connection Count: > Instead I have the same as arm showing Bandwidth (limit, burst, measured) Sorry, not sure I follow. I assume you mean the connection count graph? If so then like arm we only one graphed stat at a time. If you press 's' then select Connections you should get the connection graph. > 2)I don't have any Accounting (awake) line in nyx that shows my current > totals vs max limit. > This line just appeared in arm when I added accounting lines to the torrc, > so I assume it should do the same in nyx? Interesting! Nyx certainly should have accounting information if you have that configured in your torrc. I'll look into that when I'm home from work. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> Lord give me patience, but make it fast... ;-) Let me rephrase: Is it > deliberate that nyx logs both DEBUG and TRACE level messages when I use > the --debug option? I would only expect debug level entries. Yes, it is. > That generates many MB of output data through which I'd rather not wade > aimlessly, trying to identify what to anonymise/delete. Can I for example > get rid of all TRACE entries for starters, or would that render the > output useless to you? What other data would I need to remove so you > don't get unnecessary insight into my nodes' details? I mentioned auth > challenges already. Sure. If you'd care to 'grep -v' those out then feel free. For this issue the tor trace logs are not helpful. > P.S.: Perhaps we should discuss this further off-list? Sure, sounds good to me. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
>> Thanks for this great job! >> >> Dunno if it is an expected behavior or not, but when I enter the menu, >> the gui is updated once after the first keypress, and then is not >> updated at all then until the menu is left. Then all missed frames are >> caught up when leaving the menu. This gives a weird feeling with graphs >> being updated extremely fast. >> >> I am running debian stretch. > > Thanks Guinness! Gotta swap over to my day job but I'll try to circle > back to look into the menus in a day or two. I definitely noticed some > annoying issues there. Hi Guinness, thanks for reporting this! Circled back to the menu and it should perform much better now... https://gitweb.torproject.org/nyx.git/commit/?id=2c8c116 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
>> If so then mind running 'nyx --debug' and sending me the log (minus >> anything you consider private)? > > I'd like to help, alas 'run_nyx --debug /path/to/log' writes staggering > amounts of data. From what I see, both DEBUG and TRACE level entries are > logged, is this deliberate? I can see auth challenges and whatnot, so I > am not exactly sure what I need to remove before sending logs to you. Hi Ralph. Yup, it's intentional for the debug log to log low level messages. That's why it's useful. :P I'd just need the first minute or so of logs to see what's up with the connection resolution attempts. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> Try "pkg install python36". If nyx is written for python 3, then > running it with python 2 might not be such a good idea. It may work > for now, but nothing guarantees that it will continue to do so. Sure, up to him. For what it's worth though Stem and Nyx will continue to support Python 2.7 until its discontinuation in 2020... https://pythonclock.org/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
>> That's odd. Was this the title bar of the connections page? > > Pls see the atatched screen shot Thanks Toralf! Pushed a fix for that, as well as a change so nyx can quit more quickly. However, unfortunately it won't help with the quitting issue you mentioned off list. That stacktrace indicated we got stuck terminating the controller itself. Per chance were you logging at the DEBUG runlevel at that time? On a busy relay the amount of messages that slams the control port with can make it slow to shut down. Unfortunately besides that I'm at a loss for why it gets stuck for you. Looking at your debug logs would be the next step. Happy to discuss it off list if that would be ok. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> Thanks for this great job! > > Dunno if it is an expected behavior or not, but when I enter the menu, > the gui is updated once after the first keypress, and then is not > updated at all then until the menu is left. Then all missed frames are > caught up when leaving the menu. This gives a weird feeling with graphs > being updated extremely fast. > > I am running debian stretch. Thanks Guinness! Gotta swap over to my day job but I'll try to circle back to look into the menus in a day or two. I definitely noticed some annoying issues there. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Shame on me for not running the tests. Thanks, fixed. On Tue, Oct 31, 2017 at 11:04 AM, tor wrote: >> Adjusted the message to specify installing for whatever >> interpreter version they're running... >> https://gitweb.torproject.org/nyx.git/commit/?id=93f20f9 > > Damian: there's now a missing ')' at the end of nyx/__init__.py line 78 > causing a syntax error. > > Scott: thanks for the tip about the different sqlite3 versions, although my > system seems to actually still use Python 2.7.14 by default. > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> Hi Damien, > > the current version of nyx still produces event notices like these when > run as a user that is neither root nor the tor user ([sic] for the > missing spaces): > > 10:33:26 [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 isusually permissions related so > if you would like to fix this then run nyx withthe same user as tor > (ie, "sudo -u nyx"). > 10:33:11 [NYX_NOTICE] Unable to query connections with netstat, trying lsof > 10:32:53 [NYX_NOTICE] Unable to query connections with proc, trying netstat > > In a discussion here some weeks ago, it was pointed out to me that it is > in fact *not* recommended to use "sudo " to run nyx. Interesting, thanks Ralph. With the new connection resolution I wouldn't expect process permissions to come into play. I assume your user's able to read /proc/net/tcp'? If so then mind running 'nyx --debug' and sending me the log (minus anything you consider private)? On a side note I'm not the one that's been advising for you to not run as tor's user. That said, knowing Roger if we spoke more he'd probably persuade me to his side. Either way, lets avoid the headache of needing those permissions if we can. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
>> > sudo pkg install py27-sqlite3 > > Given that nyx is supposedly now written in python 3, perhaps a better > choice would be one of py3[456]-sqlite3, according to which python 3 version > is installed, instead of mixing python versions. Thanks Scott. This crossed my mind when I was writing it but I was unsure if FreeBSD had sqlite3 ports for all the python major/minor versions. Adjusted the message to specify installing for whatever interpreter version they're running... https://gitweb.torproject.org/nyx.git/commit/?id=93f20f9 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Perfect, thanks! > Yep. 'ps ax' output looks like: > > PID TT STATTIME COMMAND > 83797 - R 1152:14.26 /usr/local/bin/tor -f /usr/local/etc/tor/torrc > --PidFile /var/run/tor/tor.pid --RunAsDaemon 1 --DataDirectory /var/db/tor Fixed, nyx should now provide better messages when unable to connect on FreeBSD. https://gitweb.torproject.org/stem.git/commit/?id=c01d8c8 > Yep, that's it. I commented out lines 90..98, both of the try/except blocks > with os.putenv(). The error goes away and nyx seems to run fine. Perfect. Dropped the try/catch clauses - we'll just avoid these calls on FreeBSD... https://gitweb.torproject.org/nyx.git/commit/?id=f4cfa06 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> I updated the ticket to say something like this :-) Thanks Tim, thanks Sebastian. Pushed a fix to improve this... https://gitweb.torproject.org/stem.git/commit/?id=66a9b77 > Also, are you aware that inbound connections can come in on ORPorts > that are configured like this, and therefore aren't bound to a local > address at all? > > ORPort 91.121.230.208:9001 > ORPort [2001:41d0:d:22a6::1:0]:9001 Gotcha. Think at this point I'm willing to say 'good enough'. If this becomes an actual problem in practice we'll cross that bridge. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> I can confirm the connections now display correctly. Thanks! \o/ >> Is 'tor' listed when you run "ps -ao ucomm="? > > It is *not* listed. In case it helps, Tor 0.3.1.8 was installed via > ports/security/tor (https://www.freshports.org/security/tor), and I haven't > done anything to modify the startup process. I think this is a fairly common > way to install Tor on FreeBSD. The process is running /usr/local/bin/tor as > user _tor. Is it shown in the ps output as '/usr/local/bin/tor'? If so then I'll adjust Stem to look for that too. > I found one other issue. On startup nyx is displaying "nyx: environment > corrupt; missing value for" (there's nothing after the "for"). I see it on > the console twice after exiting nyx. This may be related to the comments > Andrew Deason made about the environment? Hmmm. Would you mind experimenting a little? In particular, would you mind modifying the 'nyx/starter.py' file in a couple ways? 1. Comment out the putenv calls (add a '#' at the start of lines 91 and 96) https://gitweb.torproject.org/nyx.git/tree/nyx/starter.py#n90 ... then see if the 'environment corrupt' messages go away. 2. Comment out the _set_process_name() call (line 88). This does low level mucking that might be causing issues too. https://gitweb.torproject.org/nyx.git/tree/nyx/starter.py#n88 Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> I'm not sure if it's clear, but this is FreeBSD complaining that the > environment string is invalid (an entry is missing the '=' separating > the name and value). It's probably worth looking into why that's > happening if you are able; whether nyx/stem/python is somehow causing > that, or if it's something wrong/weird with your machine. > > The commit to address this will silence the error, but it still seems > like something is wrong; all env-modifying calls should fail like this > after this point, it seems like. Agreed. I can't (since I don't run FreeBSD) but if somebody that does could suggest an alternate os.putenv command for that platform I'd love to include it in Nyx. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Thanks Andrew! Great points, changes pushed. On Mon, Oct 30, 2017 at 3:32 PM, Andrew Deason wrote: > On Mon, 30 Oct 2017 14:00:44 -0700 > Damian Johnson wrote: > >> Hi all. Pushed a couple changes to address feedback thus far... > > Sorry if this is not the right place for nitpicking/bikeshedding, but: > >> * Fixed the os.putenv() issue that came up for FreeBSD... >> >> https://gitweb.torproject.org/nyx.git/commit/?id=bcb0122 > > Bare 'except:' clauses are really not recommended for error handling, > since it catches things like SystemExit and GeneratorExit (not to > mention it also triggers if you misspell 'putenv' or something). You can > use 'except Exception:' instead, but here I would suggest at least > 'except OSError:'. > >> * When sqlite3 is unavailable encouraging folks to contact us so we >> can provide per-platform advice. For FreeBSD providing the 'pkg >> install' command mentioned earlier... >> >> https://gitweb.torproject.org/nyx.git/commit/?id=4bfe05d > > s/Unfortunatley/Unfortunately/ > > And thanks for your work; don't mistake this for me being ungrateful :) > > -- > Andrew Deason > adea...@dson.org > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Thanks Toralf!
> The # of digits after the comma might be reduced: "Outbound (3414, avg:
> 3275.896126452135412364):"
That's odd. Was this the title bar of the connections page?
> And if I press "m" here under Gentoo, then sometoimes I do get :
>
> mr-fox nyx # ./run_nyx -i 29051
> Traceback (most recent call last):
> File "./run_nyx", line 14, in
> nyx.main()
> File "/root/nyx/nyx/__init__.py", line 147, in main
> nyx.starter.main()
> File "/root/nyx/stem/util/conf.py", line 289, in wrapped
> return func(*args, config = config, **kwargs)
> File "/root/nyx/nyx/starter.py", line 94, in main
> nyx.curses.start(nyx.draw_loop, acs_support = config.get('acs_support',
> True), transparent_background = True, cursor = False)
> File "/root/nyx/nyx/curses.py", line 216, in start
> curses.wrapper(_wrapper)
> File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
> return func(stdscr, *args, **kwds)
> File "/root/nyx/nyx/curses.py", line 214, in _wrapper
> function()
> File "/root/nyx/nyx/__init__.py", line 192, in draw_loop
> nyx.menu.show_menu()
> File "/root/nyx/nyx/menu.py", line 203, in show_menu
> menu = _make_menu()
> File "/root/nyx/nyx/menu.py", line 243, in _make_menu
> submenu = panel.submenu()
> File "/root/nyx/nyx/panel/log.py", line 273, in submenu
> [RadioMenuItem(opt, filter_group, opt) for opt in
> self._filter.latest_selections()],
> File "/root/nyx/nyx/log.py", line 432, in latest_selections
> return list(reversed(self._past_filters.keys()))
> TypeError: argument to reversed() must be a sequence
Pushed a change that might or might not fix it. Mind giving it a whirl?
https://gitweb.torproject.org/nyx.git/commit/?id=b4989bf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> I think I've found a bug with the Connections pane. nyx appears to munge all > the connections into "outbound", like: > > Connections (4852 outbound, 1 control): > > Whereas arm on the same system displays them correctly like: > > Connections (2196 inbound, 2651 outbound, 1 control): Oops, great catch! Turned out that we were generally failing to pick up non-outbound connections at all due to a bug in Stem. Fixed... https://gitweb.torproject.org/stem.git/commit/?id=8772dbe ... and filed a ticket to clarify this in the spec... https://trac.torproject.org/projects/tor/ticket/24085 > Otherwise I'm finding nyx to be a very good experience so far! Thanks again! Thanks, glad you like it! > It didn't take me long to figure out, but additional messaging might be > helpful. Right now nyx just displays "Unable to connect to tor. Are you sure > it's running?" Perhaps you could add something like "If you have set a > custom Control Port for Tor, you can specify it with the '-i' argument."? On reflection this message is coming from Stem when it is both unable to connect and can't find a 'tor' process running... https://gitweb.torproject.org/stem.git/tree/stem/connection.py#n184 Per chance is your process running under a different name? There might also be an issue in the helper function that's attempting to determine this... https://gitweb.torproject.org/stem.git/tree/stem/util/system.py#n399 Is 'tor' listed when you run "ps -ao ucomm="? Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> Oh, the message should be simply something like "You must emerge > dev-lang/python with USE=sqlite" Perfect, thanks Toralf! Message added... https://gitweb.torproject.org/nyx.git/commit/?id=8be7ef6 > And - it works now - Thx for developing nyx. Damian ! My pleasure, thanks Toralf! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Hi all. Pushed a couple changes to address feedback thus far... * Fixed the os.putenv() issue that came up for FreeBSD... https://gitweb.torproject.org/nyx.git/commit/?id=bcb0122 * When sqlite3 is unavailable encouraging folks to contact us so we can provide per-platform advice. For FreeBSD providing the 'pkg install' command mentioned earlier... https://gitweb.torproject.org/nyx.git/commit/?id=4bfe05d Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Ahhh, gotcha. Please let me know when you find the magic ingredient for sqlite3 on Gentoo an I'll add better messaging for it. On Mon, Oct 30, 2017 at 1:31 PM, Toralf Förster wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 10/30/2017 09:27 PM, Damian Johnson wrote: >> Thanks Toralf! What python version are you using? Sqlite3 should be >> built in nowadays... > > Oh, this is Gentoo Linux, so sqlite3 isn't built per default, only if I > explicitely wants it by using USE= flag here I do assume - will try it. > > FWIW, Python is here in version 2.7.2 and 3.4.5 > > - -- > Toralf > PGP C4EACDDE 0076E94E > -BEGIN PGP SIGNATURE- > > iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWfeMLxccdG9yYWxmLmZv > ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTulNAP42lACLVtw55qgB7yEnpiMwOym5 > DgG15zIOgwMwhR5pKAD/cc7jcQJzrh2f2rPVY9Z3S87nXhZi8izzOm8DEumgiNA= > =fW/3 > -END PGP SIGNATURE- > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> Is FreeBSD supported? I've run into a few hurdles, and overcame several, but
> can't get over the last one.
Hi. Yup, FreeBSD is supported *but* I don't have a system to test on,
so I rely on user reports like this to provide comparability.
> I had to do:
>
> sudo pkg install py27-sqlite3
Perfect! I'll change Nyx so when sqlite3 is unavailable on FreeBSD it
suggests for folks to run that.
> And also run nyx with:
>
> sudo -u _tor ./run_nyx -i 127.0.0.1:
Gotcha. Nyx attempts to connect to some default locations but if
you're running on another port it indeed needs the '-i' argument.
Unfortunately I'm not sure of a good self-discovery mechanism. Would
alternative messaging help?
> $ sudo -u _tor ./run_nyx -i 127.0.0.1:
> nyx: environment corrupt; missing value for
> Traceback (most recent call last):
> File "./run_nyx", line 14, in
> nyx.main()
> File "/usr/home/ryan/nyx/nyx/__init__.py", line 147, in main
> nyx.starter.main()
> File "/usr/home/ryan/nyx/stem/util/conf.py", line 289, in wrapped
> return func(*args, config = config, **kwargs)
> File "/usr/home/ryan/nyx/nyx/starter.py", line 90, in main
> os.putenv('LANG', 'C') # make subcommands (ps, netstat, etc) provide
> english results
> OSError: [Errno 14] Bad address
Interesting! Any time you manage to make Nyx stacktrace that's a bug
on my part. I'll get a fix out for this tomorrow.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
> mr-fox nyx # ./run_nyx > Traceback (most recent call last): > File "./run_nyx", line 7, in > import nyx > File "/root/nyx/nyx/__init__.py", line 49, in > import sqlite3 > ImportError: No module named sqlite3 Thanks Toralf! What python version are you using? Sqlite3 should be built in nowadays... https://docs.python.org/2/library/sqlite3.html ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Testers needed for Nyx beta release
Hi all! After five years Nyx (previously known as arm) is getting a far belated update. Under the covers the whole codebase has been rewritten from scratch, but for users things look much the same. One of those cases where... "When you do things right, people won't be sure you've done anything at all." -Futurama Main changes are... * Python 3.x support. * New website: https://nyx.torproject.org/ * Bandwidth graph now prepopulates when you start up, so you have a graph right away. * Connections are now available without togging DisableDebuggerAttachment in your torrc. * Support for showing IPv6 connections. * Dialog for picking tor events to log, rather than an arcane letter flag input. * Improved efficiency of log deduplication by multiple orders of magnitude. As such verbose logs no longer peg your CPU. * Richer control interpreter, including a python prompt like IDLE. * Removed features that frequently confused users such as the relay setup wizard and torrc validation. * Modernized dependencies. Nyx now uses Stem rather than TorCtl (which was deprecated in 2011). Our ducks should finally be in a row for release, but this being a full rewrite I'd like to start with an open beta to work out anything I might have missed. Would relay operators mind giving Nyx a whirl? To give it a try simply ensure you have a control port available in your torrc... ControlPort 9051 CookieAuthentication 1 ... and run the following... % 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 Thanks! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testing Golang relay implementation
> leekspin and maybe stem can produce valid, randomised descriptors. Yup. Stem now supports descriptor creation (and should have all capabilities Leekspin did)... https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#can-i-create-descriptors ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor-arm failure
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 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-interface-directly > > Cheers! -Damian > > > On Sat, Sep 2, 2017 at 2:01 PM, Ralph Seichter > 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor-arm failure
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-interface-directly Cheers! -Damian On Sat, Sep 2, 2017 at 2:01 PM, Ralph Seichter 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor-arm failure
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 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor-arm failure
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 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
Hi Arisbe, glad it's working for ya! Nyx should have file descriptor counts if you're using more than 60% and there's room for it in the header. For what it's worth here's the relevant bits... https://gitweb.torproject.org/nyx.git/tree/nyx/panel/header.py#n407 https://gitweb.torproject.org/nyx.git/tree/nyx/panel/header.py#n243 Cheers! -Damian On Fri, Jan 13, 2017 at 2:06 PM, Arisbe wrote: > Thanks for the effort to improve Arm (now Nyx). I've only tried NYX with > the default config file but I don't see the file descriptors enabled. Did > we lose this data? > > arisbe > > > > On 1/13/2017 11:43 AM, Damian Johnson wrote: >>> >>> Thx Damian for this ! >>> Please you give some useful commands to install and use it ? >>> >>> I'll be happy to try your tool! >>> Many thx :) >> >> % git clone https://git.torproject.org/stem.git >> % cd stem >> % sudo python setup.py install >> % cd .. >> >> % git clone https://git.torproject.org/nyx.git >> % cd nyx >> % sudo python setup.py install >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
> Thx Damian for this ! > Please you give some useful commands to install and use it ? > > I'll be happy to try your tool! > Many thx :) % git clone https://git.torproject.org/stem.git % cd stem % sudo python setup.py install % cd .. % git clone https://git.torproject.org/nyx.git % cd nyx % sudo python setup.py install ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
> From MilkyWay: > [root@clutterbuck ~]# ps -p 23780 -o etime > ELAPSED > 78-14:14:25 > > Hope that helps. Thanks Alan. All of those are indeed what Stem expects. If you run the Nyx codebase instead does the uptime show up? Please note you'll need to fetch both it and stem from the git repos... git clone https://git.torproject.org/nyx.git git clone https://git.torproject.org/stem.git ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
> but I think it's not maintained anymore (?). Hi mistral. That is incorrect, I'm the maintainer. arm's last release was a long time ago and it indeed has quite a few issues. I've been rewriting it from the ground up and that's Nyx... https://gitweb.torproject.org/nyx.git Nyx is feature complete (that is to say it does everything arm does and more). I just haven't cut a release yet because there's still some troublesome curses issues to sort out. Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
> Damian, > Milkyway (which is working) is using Centos 6 > Andromeda is using Centos 7 > and TheCosmos uses a raspberry pi 2, so Raspbian Interesting. Maybe that platform has a subtly different format than what I expect. Mind running the following for an arbitrary process and telling me the output? ps -p -o etime Nyx uses /proc to get this information too but that's platform specific, so ps is used as the more universal fallback. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
> arm does not show uptime and the average bandwidth rate is way to high. This is because tor changed the format of its state file since arm's last release, causing the prepopulated values to be inaccurate. The current codebase (nyx) uses a new capability of tor's control port to provide much better graph prepopulation as you already observed. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
> Does it use `ps -o etime`? If so it should work in the latest OpenBSD > release. Yup, I use... ps -p -o etime Glad to hear it should now work on OpenBSD! To confirm would you mind providing me the output of that command for some arbitrary process on your OpenBSD system? I can add that to our unit tests just to be sure things are happy. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Uptime missing from Arm
Hi Alan, what linux distribution is this with? The only platform I'm aware of having issues with the uptime is OpenBSD. This is because the uptime requires parsing ps output and on that sole platform they show it in 12-hour local time with am/pm indicators, and a format that shifts if over a day (ie. a true parsing pita :P). Cheers! -Damian On 1/8/17, Alan wrote: > I have 3 relays running but on Arm only one shows the uptime. Also the > Averages it keeps are way off. > > Alan. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Arm connection page shown as empty for one particular node
Hi Ralph, arm simply shells out to netstat, lsof, and other commands to get connection information. You can run these commands yourself to troubleshoot why they don't work... https://gitweb.torproject.org/nyx.git/tree/src/util/connections.py?h=release Also, if you log the ARM_DEBUG events arm should tell you what it's running along with a little information. Cheers! -Damian (arm's author) On Sun, Sep 25, 2016 at 2:57 AM, Ralph Seichter wrote: > Hello, > > since updating my nodes to Tor 0.2.8.8, the "connections" page of Arm is > not showing connections anymore for one exit node running on Gentoo Linux. > On a Debian based exit node and on Gentoo based non-exit nodes things > work as expected. The affected exit seems to work fine and bandwidth > graphs look OK, only the connection list is unexpectedly shown as empty. > > I tried all listed "resolving utility" options, but that did not help. > Any idea on how I might be able to debug/fix this? > > -Ralph > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Arm phantom keystroke issue.
Hi Matt, sorry this is nailing you. I've seen it as well and have been pretty puzzled by it. The issue first started manifesting in the late 1.4.x series making me suspect it's related to the interpreter panel but I never found out exactly what was up. Unfortunately the bug can take days to manifest, making it tough to reproduce. As you may have noticed arm hasn't had a release since 2012. This last year I've focused on fixing that. Nyx is the new version of arm, rebuilt from the ground up under the hood... https://gitweb.torproject.org/nyx.git/log/ No doubt it'll initially have lots of warts of its own, but between Stem and test coverage should grow to be much more stable in the long run. I don't have a release date for you yet but I'll let this list know when I'm ready for beta testers. Cheers! -Damian (nyx's author) On Fri, Sep 23, 2016 at 7:29 AM, Matt Helps wrote: > Hello. > > The node we run is in our library and we have a raspberry pi SSH'ed into the > node and an LCD displaying the output from Arm. Arm is bugging out on a > random basis and appears to be receiving a C keystroke that I believe is the > clear log command. I ran the pi with no keyboard and I even used another > machine to display the ARM output from the SSH session and it did the same > thing. Has anyone else seen this and is there a solution? It's a real bummer > because we use this as a learning tool in our library and the pretty graphs > of incoming and outgoing traffic really get people interested. When this > phantom keystroke happens the graphs stop and somebody has to press N on the > keyboard to get the pretty graphs rolling again. This can happen in 2-3 > hours or upto 12 hours. See pic here. http://imgur.com/a/wrMhT > > Cheers, > > Matt > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] is explicit DirPort needed anymore under Tor 0.2.8.6?
Hi Green. Besides the things teor mentioned the DirPort also provides easier access to directory information which Stem's remote module... https://stem.torproject.org/api/descriptor/remote.html ... and curl can take advantage of... % curl 128.31.0.34:9131/tor/server/all > * relays no longer fetch documents using the DirPort (so maybe never). Hope we can amend this to be 'relays *and* stem', otherwise DocTor and quite a few things will be very sad. :P Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor-arm
>> Is this ok or is it deprecated and I should install something else? And >> how? > > It works well enough now and it is being improved slowly with a name change. > (As far as I can tell.). Yup, that is correct. I was hoping to have the next release out for you by around this time but it's coming along pretty slowly. None the less it is making progress and I should be putting out a call for beta testers in a few months. Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx Project Ideas
Hi ZEROF, Nyx isn't ready yet for users. It works, but is still very much in development. It might be released around June, though that's just a guess. I reserved the name 'nyx' in PyPI but pip won't work until the release is ready. Cheers! -Damian On Thu, Feb 25, 2016 at 8:26 AM, ZEROF wrote: > Hi, > > I use arm, but i wanted to test nyx and i have found install option "pip > install nyx", but install don't work, version 1.4.5. You can see logs: > https://paste.lugons.org/show/Ua6RdWzaMg8cI5cWsf0b/ > > ;) > > On 25 February 2016 at 03:10, Damian Johnson wrote: >> >> Hi wonderful relay operators. It's GSoC season again, where students >> can be funded to make open source projects like Tor even better! >> >> Nyx (previously known as arm [1]) has been my main focus this last >> year and is inching ever closer to release. For those unfamiliar with >> it, Nyx is an ncurses monitor for Tor relays providing a bandwidth >> graph, event log, connections, config editor, and more. >> >> Rather than add new features my work has focused on making Nyx simpler >> and faster, but GSoC provides us an opportunity to do even more. So >> I'm curious - what do you want from an ncurses monitor? The answer may >> be 'keep it simple'. Feature creep does us no favors. But if there's a >> good fit I'd love to mentor a project that makes your lives even >> better! >> >> I'm not overly fond of the ideas I've had so far... >> >> * Windows support. This poses a few challenges. [2] >> * When running multiple tor instances on a single system connect to >> them all, aggregating the information. >> >> So anything come to mind? >> >> Cheers! -Damian >> >> [1] https://www.atagar.com/arm/ >> [2] https://trac.torproject.org/projects/tor/wiki/doc/arm#Windows >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > -- > http://www.backbox.org > http://www.pentester.iz.rs > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Nyx Project Ideas
Hi wonderful relay operators. It's GSoC season again, where students can be funded to make open source projects like Tor even better! Nyx (previously known as arm [1]) has been my main focus this last year and is inching ever closer to release. For those unfamiliar with it, Nyx is an ncurses monitor for Tor relays providing a bandwidth graph, event log, connections, config editor, and more. Rather than add new features my work has focused on making Nyx simpler and faster, but GSoC provides us an opportunity to do even more. So I'm curious - what do you want from an ncurses monitor? The answer may be 'keep it simple'. Feature creep does us no favors. But if there's a good fit I'd love to mentor a project that makes your lives even better! I'm not overly fond of the ideas I've had so far... * Windows support. This poses a few challenges. [2] * When running multiple tor instances on a single system connect to them all, aggregating the information. So anything come to mind? Cheers! -Damian [1] https://www.atagar.com/arm/ [2] https://trac.torproject.org/projects/tor/wiki/doc/arm#Windows ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-arm bandwidth state file -xxxx seconds is missing?
Not hurting anything and in general if you see a message that's 'notice' that means 'this is fine, just for your information'. If it was a problem it would way it was a warning or error. On Thu, Jan 28, 2016 at 10:29 AM, SuperSluether wrote: > Ok, so just wait for arm to get updated then? I guess as long as it's not > hurting anything, it doesn't matter too much. > > > On 01/28/2016 12:06 PM, Damian Johnson wrote: >> >> When arm starts it attempts to read tor's state file to get past >> bandwidth information. That is a notice level message, not an error, >> and it's simply telling you that it wasn't able to prepopulate all the >> data. >> >> Tor has changed its state file format which actually breaks that >> feature entirely. The next release of arm (now called nyx) accounts >> for this. >> >> >> On Thu, Jan 28, 2016 at 10:02 AM, SuperSluether >> wrote: >>> >>> Found this error when checking my relay today: >>> >>> ARM_NOTICE Read the last day of bandwidth history from the state file >>> (- >>> seconds is missing) >>> >>> Every time I start arm, the -xxx seconds missing is different. The >>> bandwidth >>> graph is also stuck, but real-time data is still shown. >>> >>> Is this a problem with Tor, or with Arm? Anyone know a fix? >>> ___ >>> tor-relays mailing list >>> tor-relays@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-arm bandwidth state file -xxxx seconds is missing?
When arm starts it attempts to read tor's state file to get past bandwidth information. That is a notice level message, not an error, and it's simply telling you that it wasn't able to prepopulate all the data. Tor has changed its state file format which actually breaks that feature entirely. The next release of arm (now called nyx) accounts for this. On Thu, Jan 28, 2016 at 10:02 AM, SuperSluether wrote: > Found this error when checking my relay today: > > ARM_NOTICE Read the last day of bandwidth history from the state file (- > seconds is missing) > > Every time I start arm, the -xxx seconds missing is different. The bandwidth > graph is also stuck, but real-time data is still shown. > > Is this a problem with Tor, or with Arm? Anyone know a fix? > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reload Config Without Restarting?
Yup, no problem... https://stem.torproject.org/faq.html#how-do-i-reload-my-torrc On Tue, Jan 26, 2016 at 5:06 PM, Tristan wrote: > Is it possible to reload torrc without restarting Tor? I'm running on a > Raspberry Pi compiled from source, so I can't use sudo service tor reload. > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] arm /flags gives unknown
> That should not be the reason. > Arm displays the flags right in the text gui when used without > parameters. Only when called via "-p" for command line processing it > seems to fail. That does seem a tad odd though. For what it's worth though the interpreter's been moved out of nyx (aka arm) and into stem. Stem's interpreter got quite a few improvements... https://stem.torproject.org/tutorials/down_the_rabbit_hole.html Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relays possible sybil
Yup, the authority operators are aware of them and think they've taken action. If these relays are still in the consensus then let us know. We're not really sure the story behind them but if you're reading mr. cloudvps operator then please reach out to us. We'd love to chat. Cheers! -Damian On Tue, Jan 12, 2016 at 1:48 PM, wrote: > hi, > just wondering whats the matter with these 66+ relays "cloudvps" ... guess > they get vote, should we discard some iprages? > thanks ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unbelieveable
For what it's worth process permissions aren't at play here. Arm is failing to talk with the control port - permissions could cause us to be unable to read the authentication cookie, but that would be a different message. Cheers! -Damian On Fri, Dec 4, 2015 at 5:36 PM, Manager Bahia del Sol LLC wrote: > > No worries, > > Are you sure the user or group is debian_tor? > The default is debian-tor in Ubuntu. > > If that isn't the problem, > > First I would be sure tor is actually running. > top > or > top -u debian-tor > The second will show if tor is actually running as the user you think it is. > > If it is, then see if it is listening on the control port > sudo netstat -ntlp | grep LISTEN > > If it is I would suspect that either a firewall is blocking that port. If > you have one running > try shutting it down for a few minutes while you try to start arm. > > Or maybe it is a permissions issue where arm is not running as the same user > as tor. You could try starting arm as root > to see if it would start. But, do not run arm as root full time. Only try to > start it as a test. > > > > -- > Manager of Bahia del Sol LLC > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] VPS Connection Refused
>>> Doesn't Arm look for 9051? >> >> By default, but it can be any port you edit into the rc. > > Apologies for the rudimentary question but did you try 'arm > --interface 9051'? I assume by 'edit into the rc' that you've changed > the default via the armrc but if I was in your shoes I'd give the > interface argument a quick try. Also, you can try running 'arm > --debug' to possibly get a little more information. > > Cheers! -Damian Baka, typo - meant 'arm --interface 9052' since you're changing away from the default. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] VPS Connection Refused
>> Doesn't Arm look for 9051? > > By default, but it can be any port you edit into the rc. Apologies for the rudimentary question but did you try 'arm --interface 9051'? I assume by 'edit into the rc' that you've changed the default via the armrc but if I was in your shoes I'd give the interface argument a quick try. Also, you can try running 'arm --debug' to possibly get a little more information. Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Arm thinks Tor is not running as a Daemon?
> I’ve already read tickets like #16459[1] and #2501[2] but it didn’t help > much. Damian says in Ticket #16459 > > […] This message is meant to help people who edit their torrc, forget to > restart tor, and are then confused why the settings didn't take effect. > [...] > > > I did restart tor (a couple times) and apparently it is running as a Daemon > (service --status-all). So I hope this is “just” an issue with arm… > Maybe someone of you has an idea? Hi Jannis, please read further in that ticket: "I'll either be rewording or dropping the notice in the next release. Iirc Debian does something funky with regard to baking this setting into its tor binary, so in your case it's probably a false alarm due to that." Probably not something to worry about. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TorFlow
Oooh, very neat! Just a quick head's up about an unfortunately naming conflict... https://gitweb.torproject.org/torflow.git/ TorFlow is the name of the codebase that backs the Directory Authorities. That said, the library's obviously not user facing and will likely go away when the DirAuths get a refresh so not necessarily something to worry about. Cheers! -Damian On Mon, Nov 9, 2015 at 3:22 PM, Kenneth Freeman wrote: > A gorgeous visualization of the Tor's data traffic. Feast your eyes! > > https://torflow.uncharted.software/ > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] urras? [was: tor network "loses" ~50 relays/day due to bw auth problem]
Hi Coderman. Yup, Jake is aware of this and has been working on it for a while. :P https://lists.torproject.org/pipermail/tor-consensus-health/2015-July/005986.html Cheers! -Damian On Sun, Aug 16, 2015 at 5:06 PM, coderman wrote: > On 5/31/15, Jannis Wiese wrote: >> ... >> At the moment I just see urras missing from the consensus... > > i would like to report a missing Tor-DA to the authorities. ;) > > > best regards, > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] longclaw BWauth is broken -- no measurements since 7/22
Interesting. Thanks starlight for the head's up! I'm not aware of any known issues with longclaw right now so looping in its operator. On Sat, Jul 25, 2015 at 10:09 AM, wrote: > Subject says it. > > Thought it was strange that its measurement > of my relay has not been moving. Pulled the > vote history and grep'ed a dozen relay > measurements and none of them have changed. > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Faravahar authority key expired
Hi, Sina (Faravahar's operator) has already been notified. In fact, he's getting notified each hour. :P https://lists.torproject.org/pipermail/tor-consensus-health/2015-July/ Interestingly this made me realize DocTor has a bug. He got two week warnings about the cert expiration [1], but looks like the one week warnings weren't sent. Cheers! -Damian [1] https://lists.torproject.org/pipermail/tor-consensus-health/2015-June/005936.html On Tue, Jul 7, 2015 at 5:25 PM, wrote: > The authority node Faravahar's key > expired and it dropped off the > consensus. Looks purposeful. > > Does anyone know why? Are authority > public keys embedded in the relay > code or learned? New release required > for new key? Is this usual? > > Just curious. > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] unflagged BAD EXIT nodes
> Sorry for hijacking, but I wasn't sure where best to put this... Glad you want to get involved! This would be more suited for its own thread on tor-dev@ but that said, my top suggestion is: pick something that interests you. Enjoying your involvement with open source and, by extension, sticking around to become a long term contributor is more important than any particular task. :) Some good spots to get started are... * Summary of our projects and points of contact: https://www.torproject.org/getinvolved/volunteer.html.en#Projects * Fun way to learn more about tor: https://media.torproject.org/video/ Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
