Re: [tor-bugs] #13137 [Onionoo]: Historical data

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13137: Historical data
---------------------------+-----------------
     Reporter:  Sebastian  |      Owner:
         Type:  defect     |     Status:  new
     Priority:  minor      |  Milestone:
    Component:  Onionoo    |    Version:
   Resolution:             |   Keywords:
Actual Points:             |  Parent ID:
       Points:             |
---------------------------+-----------------
Changes (by karsten):

 * priority:  normal => minor


Comment:

 Replying to [comment:4 Sebastian]:
 > It's really hard for me to come up with an exact usecase.

 Thanks for trying!

 > Recently, I aimlessly scrolled through the consensus-health page, and
 noticed gabelmoo wasn't voting running for a bunch of relays. So I tried
 check its log, but it logged it found them reachable. So I thought maybe
 it was a fluke this hour, and waited for the next hour. Hrm, same thing. I
 then downloaded old consensuses to see if this was a recent development or
 something that came up a longer time ago, learned it was somewhat recent
 (which was good, because I try to take good care of gabelmoo and hence
 scroll through consensus-health every now and then). Then after some more
 poking I realized something all those relays had in common: ipv6. I then
 noticed that my upstream had broken ipv6 on the host. I didn't have proper
 monitoring in place for that, but without something like consensus-health
 I'd still not vote Running on these relays. If I could click on the page,
 and it'd pull up the descriptors for the relays and show me the flags and
 when I voted what for them, it could help track down what I changed to
 cause an issue.

 It seems that #9778 would have helped here, though it doesn't come with
 history.  But I'd say let's add current vote information first and think
 about history in step two.

 > Another instance is when a relay operator complains because they aren't
 in the consensus, I look at consensus-health to see who is voting what,
 and try to figure out why. It just gives a quick overview for a relay. For
 that, it'd be good if it would show ip information, too, so I could search
 for that (in this case, I had ip address and relay nickname, and
 fortunately the nickname was unique enough to identify the relay).

 You're aware that you can search for partial fingerprints, IP address,
 nicknames, or any combination of those in Atlas/Globe?  For example,
 `F2044413` uniquely identifies gabelmoo, as does `gabelmoo
 212.112.245.170`.

 > A third example is my work to get rid of the Naming flag, and redo the
 BadExiting/Rejecting/Valid-voting stuff. I tested a version of my patch,
 and it only voted 10/22 relays as BadExit, so obviously some where
 missing. Trouble was, none of the missing relays made it into the
 consensus, they were just in the votes. Their nicknames were "default", so
 searching for that didn't help either. After a bit, arma noticed that
 these were syrian and iranian relays. This, too, could've been much
 quicker resolved if I could've clicked on the relay, it would've pulled up
 the page with all the information about it (this time including country).

 This is also related to #9778.  Once we parse votes, we'll also include
 relays that didn't make it into the consensus.

 Similarly to the second use case, relays with nickname "default" shouldn't
 pose a problem, because you can always search by partial fingerprint.

 To summarize, let's do #9778 first and then see whether we should add more
 historical data to facilitate debugging problems like the ones described
 here.  Setting priority to minor.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13137#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs