compass: new group by options: by-contact, by-OS, by-version
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Karsten, I added a few new grouping options to compass: - -T --by-contact (#6675) (Maybe we should truncate contacts and remove the undefined) - -O --by-os - -V --by-version (#6855) +expose -N options in html (was implemented but not exposed in gui) https://github.com/nusenu/tor-compass For all output I (mis)used the nick column as a quick solution since it is not used otherwise when grouping. Advertised bw is broken for some time. There is no 'advertised_bandwidth_fraction' (This field was removed from onionoo in November 2014.). Is it ok to change this to observed_bandwidth? (which would be a non fraction item)* ? (The MyFamily lookup is also broken) short commit log: - - add new group by ContactInfo option: by_contact (-T, --by-contact) (quick 'n dirty) - - added new grouping -O, --by-os (all BSDs are merged into one group) - - added new grouping by tor version (-V, --by-version) - - tell app.py about new options (by_version, by_os, by_contact) - - expose -N option in html and fix a missing label tag - - include network data in html output when using -N (uses nick column) - - expose by_version, by_os and by_contact options in HTML - - if it is just one item, display the actual value for AS and CC instead of saying (1) What do you think about it? thanks, Nusenu *) while playing with that I found 3 relays from JP that have a suspiciosly high adv bw: https://atlas.torproject.org/#details/F528DED21EACD2E4E9301EC0AABD370EDCAD2C... https://atlas.torproject.org/#details/8901B1D2D4C0D3398C3F8363247B5AABF31369... https://atlas.torproject.org/#details/4EA0464A1B8D4231F176BA2FA1BCBF0A26F128... reminded me of SKKU43: https://lists.torproject.org/pipermail/tor-talk/2014-February/032094.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCtlTAAoJEFv7XvVCELh0bY0P/1aJyZncqdy47WZM9I7Y1E4a Sg1luXTqi9VlFZhbUJeFrhidLVPSqQYbMw79sKufU2uw/Jcqr0Ro2O48q9Gj7sL8 lDcM4AgFzm1yTedoXqyNAA5+bBeQTAjEgQU1ADYUZvDx2ULmGG4aD6qCuaFoP+3/ kjJ6r92jLOSYpOVdt8FyNc8IZYpbEwQNMKc4A0uZhQV/WVv6vFiOaXHliPdR6m2+ SU+KTqldWppfeezWIalGl3t7HEnz87JOaWrdnQ8fjLKSsqkex2T5E1MClguM4u2o 5ABPxg6uF/izjPv2VEy/hl42RQbLM5SDazM4CLMFN3mQu6Xa4iZ5R8A6iLDgZBj6 zK2wExcxScc58r4Briv5EKUpC9LTgE52DkPkX+TM3i9ktniYQbb/k/cy85nn+ENa WrZ2WDmaMyQXy6kXDCS4U/3gbv1+Dwq82hg372N2fga6hOXsZPFrxV1TwWlMTzp9 MvpaF6/GZsivrjNklteHxvxgcxTyywaKW5QUdFJdeCZnOrDy29iGKIql10xQ7TXa gTC7OTsDCAPiJn8P5xKhEAlVeJmz0zZN7QhbY/ybIc5KWkOoKyYwkT9ysmpS8rOK mapKbuMXvuA3Sg1F1sK9PEUy+D8ZAe+sBjOEHzqILARA6VXsly0rSJkcnhNKNpmL yxSwWe4uWOVXDmVEl7hQ =jGQe -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
The MyFamily lookup is also broken
It actually works, I just expected to see more then an empty set when entering a torservers FP. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCztzAAoJEFv7XvVCELh04bIP/0a8ncpIKzAAJu6sjF+9y9Jo K7fQqyX1LTzCdNFDxR2OOQYx/jFwrFtl++yapM5LpLSoDslwQMOZdwCnyhqSnfKJ DK39R/N4Hze05aNkGXHjlgrRfm2bhfeLwlv8R1DJJIj5L/mtdGClnAzRmUg/LjgG gTuZ/8oR4Rkf8yI09k6s0BlEBQ7dv+WMFa+NxpKdMaWyNs4YecUxBdL7eX1r/F9E fdV3h+O3E/potFNMX//BrKKNYryddKlPy6DIKkTL+lSGbg5Bb5vB25AYcpHBhGeG EvMB/wNZ6jtbD7kGhf6LAVwRR4SimodsIUPgzyk1l7+4GsyVel0UzX+b0lr/bz7p SiEg1/HY0Y/52mdfcqx/wZpFe73ckkYrhd+Fa8Q/rnQtxg7CgVhtjkDtFRWOsBdt Vvn9qeVD36cp0/6TzU/Tug8bjY+z/C0QFpkyXf90T/E2jYnLOQMhuzurAhusQkw9 h+MBbEgE4d2P3v3tU9r8ZCEYYEbuyDyrFpRtkXGs4VFGRxXYEPJrFwd3RBzcvTks c+6XX5IbBGzWlWpXWUGbRnJZ15lHVLVG3uPV0Bjbu8vaNfeee/BIr2z/igRRGcxL KqNjKrcXo+6X9B+X/zL2L0f2s99ctFK02+CIJ3nuTtIvdjtEwwwPFliCQgOEQwS0 DkqTYrw1GxQN7uXLZFRC =+u7X -----END PGP SIGNATURE-----
On 03/19/2015 10:11 PM, Nusenu wrote:
The MyFamily lookup is also broken It actually works, I just expected to see more then an empty set when entering a torservers FP.
Our MyFamily statements have been broken for quite a while; it is not clear whether the statement actually provides any benefit. I believe it does, see also https://trac.torproject.org/projects/tor/ticket/6676 . -- Moritz Bartl https://www.torservers.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/03/15 15:12, Nusenu wrote:
Hi Karsten,
Hi Nusenu,
I added a few new grouping options to compass:
-T --by-contact (#6675) (Maybe we should truncate contacts and remove the undefined)
I didn't look at the ticket or code, but truncating contacts sounds like it could confuse users more than help them. Removing the undefined contacts, or rather treating them specially sounds like a fine plan. I guess missing values should be treated similar to missing values are treated in the other fields.
-O --by-os -V --by-version (#6855)
Again, I didn't look at the code, but you might want to take into account that there's no check whether the platform string says "Tor 1.2.3.4-something". You should probably treat platform strings that don't stick to that schema as missing values.
+expose -N options in html (was implemented but not exposed in gui)
https://github.com/nusenu/tor-compass
For all output I (mis)used the nick column as a quick solution since it is not used otherwise when grouping.
Heh, sounds like a hack that will confuse other contributors and the future you in 3 months from now. It's probably worth rewriting this now, as long as you at least know why it's a quick hack. It's going to take less time overall. :)
Advertised bw is broken for some time. There is no 'advertised_bandwidth_fraction' (This field was removed from onionoo in November 2014.). Is it ok to change this to observed_bandwidth? (which would be a non fraction item)* ?
I'd say just take out advertised bandwidth *fraction*.
(The MyFamily lookup is also broken)
short commit log: - add new group by ContactInfo option: by_contact (-T, --by-contact) (quick 'n dirty)
- added new grouping -O, --by-os (all BSDs are merged into one group)
- added new grouping by tor version (-V, --by-version)
- tell app.py about new options (by_version, by_os, by_contact)
- expose -N option in html and fix a missing label tag
- include network data in html output when using -N (uses nick column)
- expose by_version, by_os and by_contact options in HTML
- if it is just one item, display the actual value for AS and CC instead of saying (1)
What do you think about it?
I think it's awesome that you picked up Compass development *and* use it to find configuration problems of relay families and other problems. This is really great, thanks for doing this! Regarding the tickets and code changes, you should know that Compass doesn't have an active maintainer right now. All I do is keep it running, but I can't work on enhancements nor review submitted patches. I think you should fork Compass, maybe give it a new name, run it on a small VM somewhere, and become the maintainer for that. I'd be happy to add a link to https://onionoo.torproject.org/. I could also imagine adding a short text on https://compass.torproject.org/ that links to your service as the new Compass. And just in case you were wondering, if you ever have a feature request for Onionoo, I'd be happy to discuss that. In contrast to some of its clients, Onionoo itself is actively maintained. Thanks for caring about this! All the best, Karsten
thanks, Nusenu
*) while playing with that I found 3 relays from JP that have a suspiciosly high adv bw: https://atlas.torproject.org/#details/F528DED21EACD2E4E9301EC0AABD370EDCAD2C...
https://atlas.torproject.org/#details/8901B1D2D4C0D3398C3F8363247B5AABF31369...
https://atlas.torproject.org/#details/4EA0464A1B8D4231F176BA2FA1BCBF0A26F128...
reminded me of SKKU43: https://lists.torproject.org/pipermail/tor-talk/2014-February/032094.html
_______________________________________________
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVD9RWAAoJEJD5dJfVqbCrN74IAL0IJstZMKwJNnOUiVH/B1bD wfAQUpL2meQVX83bQlqcvRAU/OdCUHVhIAk4T4EzHZBoomh5h2wEZJnGNSr4FO+x Qel+FlDukFeK07M5albN8uARfAPhclm5c/g0yiHn33sDNUWG7vdv/OUkly3urfKW MJClDW5hIujS5b457yuVLi4P8mkJvEHdbEbDUlfJ5pRGMisE7n4X2yR1dmZ7uzGr L00czaWxqorPM9nnFaGckGIcXDdH3xJB1RfZtF6XmQbmUJv5WihviWyg0XunypJO O3nB3lqjVmcrIGeKCa+5O0iggmz9F0kaRtGL+WWmbiDuN7PTBPE38V9Ut+R71cg= =mnHF -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Karsten, thanks for your reply.
-T --by-contact (#6675) (Maybe we should truncate contacts and remove the undefined)
I didn't look at the ticket or code, but truncating contacts sounds like it could confuse users more than help them.
You can judge by having a look the example that actually truncates contactinfo here: https://raw.githubusercontent.com/nusenu/misc-files/master/biggest_tor_relay... I can tell, it doesn't look as "nice" without truncation ;)
Again, I didn't look at the code, but you might want to take into account that there's no check whether the platform string says "Tor 1.2.3.4-something". You should probably treat platform strings that don't stick to that schema as missing values.
Agreed. I also plan to have multiple group-by modes for version (and other properties) using a radio button selections: Group by version [] none [] major version [] exact match
Heh, sounds like a hack that will confuse other contributors and the future you in 3 months from now. It's probably worth rewriting this now, as long as you at least know why it's a quick hack. It's going to take less time overall. :)
Agreed.
I think it's awesome that you picked up Compass development *and* use it to find configuration problems of relay families and other problems. This is really great, thanks for doing this!
Thanks for the kind lines.
Regarding the tickets and code changes, you should know that Compass doesn't have an active maintainer right now. All I do is keep it running, but I can't work on enhancements nor review submitted patches.
So I guess it doesn't make sense to add/modify on any compass tickets in trac(?).
I think you should fork Compass, maybe give it a new name, run it on a small VM somewhere, and become the maintainer for that.
Ok, I'll investigate the feasibility of self-hosting a fork. thanks, Nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVEBtUAAoJEFv7XvVCELh0EXsQAKUYctGMwkL7jYU1M0Ejxwss uO4TYiOEby+TyxeheiYTQYFarawxGMG0XLBeABVsco6U6UzPtqXwH1OXPY6S9CH0 Q1MDqzW26i4cYksOWhj+GABPDlOp+NlcfOYoh9b8boiMYU5N/QCPzPZmvcz4Xrdi 5FXRDr1Yd0Ih49J+eteUnQ3PPptf9KvFN+MtglTaof+MbM7XmgfAwiVHsg7SQdJf a4O7Q4IOb6fNK2KmKbF6chJlqF7FUyP1jBGLswjrwB/iQqKzfyCx3kCt7UhoqbRU W1H6rMKub6Rd2oCjzNiszhrTY2uIU72y/tD6SO1Q0pX0JSEcj9MDqblQdz/bdwKG 8pZuv/0/ApHWQuuxS2P+RGFAknNwuTQSznQ+I9MIP5/3d2/r2XZ9adf/24oWZECW Kc2DYP/NdCU8HPL4mQQxtpM8x3mC1Jkfp/BVyRDOAhfp5lqPffg0MCB8/tWzQA8l kHqFEz9VfTeEy9aWSgEgODurYUVdb6/Ch6sS2T3Gq6BrGam4Y/DL9jczPvuySdtp jdVo+2izQ2aDtEg2n53DO6nV46s2keY3wJd0M6GDn6+bEYc4pqBLi8ksrFBa+kHH 0tlBmrWzCsR7R9liM3XNODmWH4OVfMPpE5HO5H+N6aLdjYy3pbV/Q2FtwpCOjwPl LJNBjsO6IIpWBS2TrGmR =DAuk -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/03/15 14:55, Nusenu wrote:
Hi Karsten,
thanks for your reply.
-T --by-contact (#6675) (Maybe we should truncate contacts and remove the undefined)
I didn't look at the ticket or code, but truncating contacts sounds like it could confuse users more than help them.
You can judge by having a look the example that actually truncates contactinfo here:
https://raw.githubusercontent.com/nusenu/misc-files/master/biggest_tor_relay...
I can tell, it doesn't look as "nice" without truncation ;)
Okay. I guess what I wanted to say was group by full contact lines, display truncated if needed. But I have no idea whether that would make a big difference in practice.
Again, I didn't look at the code, but you might want to take into account that there's no check whether the platform string says "Tor 1.2.3.4-something". You should probably treat platform strings that don't stick to that schema as missing values.
Agreed. I also plan to have multiple group-by modes for version (and other properties) using a radio button selections:
Group by version [] none [] major version [] exact match
Sounds good!
Heh, sounds like a hack that will confuse other contributors and the future you in 3 months from now. It's probably worth rewriting this now, as long as you at least know why it's a quick hack. It's going to take less time overall. :)
Agreed.
I think it's awesome that you picked up Compass development *and* use it to find configuration problems of relay families and other problems. This is really great, thanks for doing this!
Thanks for the kind lines.
Regarding the tickets and code changes, you should know that Compass doesn't have an active maintainer right now. All I do is keep it running, but I can't work on enhancements nor review submitted patches.
So I guess it doesn't make sense to add/modify on any compass tickets in trac(?).
Probably not. What you should do is go through the existing tickets and see which issues are still relevant for you. But it's probably easiest for you to use your own issue tracker.
I think you should fork Compass, maybe give it a new name, run it on a small VM somewhere, and become the maintainer for that.
Ok, I'll investigate the feasibility of self-hosting a fork.
If hosting is the issue, please contact me off-list, and I'll see if I can help with that somehow. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVECx6AAoJEJD5dJfVqbCrNZkIAIHh5iKJFYm3haa/ztnFpaLN DsrnqJlcMCSqK9jZM7Ig5myEihaFl+HRQVrE+GLLNePDyByPxHfNSDpPrBJD2ESE duMrP77yVr9M9rTnzK+k60oQyUPCxwJyVosdz6vIVEzBBHWwWJjjVoiQwu4gE8gE pQWK+rs/fQWfLLA94DYwFcIqMZdHcfFYhZF9cKSGlhzqA4x0+eEDGEVqCxCnrd1f qFHE1dI1bcV51mXOBnyuVB4FTkr+PqdGi36oGZzN+5ARSBsTvV+XmcqjvVTWl1F9 /APjL1OPu6UDWoP0+6Qjx9VmJN6I9AoxJRwsXoFsc/Z3XJ4F4qVP6yOtYMjDE14= =chyy -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Karsten Loesing:
maybe give it a new name
Is 'aggregator' ok, or should there be no 'tor' in the word at all? -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVEDJZAAoJEFv7XvVCELh0kJAQAIGzub91WhiAmE5qpRe2Y6l3 dYIu9/XvSjF/CchcxKx64nR5/6iSggSb+1anWgWNKDJuSBi1FiOne5aZg9EWI/qN mnqlqSIKAocBrpGWnKF4z84us7EjJXFVCwhF+BEsjJZNy+LFdjxTq06fMy68JcBO nluxXvAanG9SamvsG8Efc3SYV6Wk3vIfANGzI12HKHbvodBEVfE3o7fl4qCwfNJn 1RTCleQIEEevaf2Bm5eviy6UVPlHVhHgHQKK0EiahJPTo3+MIaTTEuZPb4j7SPww OMtk727hPYFDikMsWb42wGwu+iXXfDg58nv694AAJzrkoM8cGtmgEhduCmLf7Roq Azl/QPNvHyGv2NYjb1CjHEyU5h1FWFv+JNinUcSF2jZaOZD4rRwlJV9zGTD4oXR2 rTZMv/5ada/fCPM7y5NUFQSWrGUds+lu3lZh3SFZSzMBqxKOJ1f08LbPErjX20sR 009Qk/uPa4wRG7c3f6sCQ0VRCm+QdBmpOWqSxN6XbinrB9MqEiPZcF5EKRLZZUL1 aGjgb3tPN+qurkp1RIAJZGYUEOP+LK5h3j+y2rssYLomAd2CwmIGeOZSr5zGC8VF V5Q2FgvVpi0xlvKFT51lwa3AAu6IvFgbgQE2haHfGrlTIfR/V4BkvZbZZh77bw0b U8dQg/NVE+54ZPB5mhiK =9tWM -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/03/15 16:33, Nusenu wrote:
Karsten Loesing:
maybe give it a new name
Is 'aggregator' ok, or should there be no 'tor' in the word at all?
I think "onion" is the new "tor" to build names around. Though I don't think "aggregator" would be problematic. Capitalized differently, as "aggregaTor" or "AggregaTor", it might be. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVEDYWAAoJEJD5dJfVqbCrKAEH/29mNKWqP0Hjv26SGTuHe9aK B3etHYM2uFnw5nqa+VISOB8gAeH3jvZDeTdasd6EVUrSWJ8hGkks8Mx6w/Vq1CLL k+80ITEkVql9goqRTruQX1ioEebiVE3M5dW3JXZWqJNC6kr5s3bfipTkAqPWdOgX Jq7aD9klYz6XGpMRWVpGDa5pMZkXBGFy1Q5nq+VA2rahhSuYRNbzshZbnoqHT3oU cQOW40ak3kH6S3NAKOyb64JEU5twhWzn3WQYiwEkQnwz/gIScvCAVG0hbH4wG+Ij Y1XkQR7goevDvv0KS5BFiOcBqomL832xfcUhuUv+3irqXlh9F/8+0PIl6EqIQAQ= =NTVx -----END PGP SIGNATURE-----
participants (3)
-
Karsten Loesing -
Moritz Bartl -
Nusenu