Announcing the Walla Walla Project
Hi, I'm representing the Walla Walla Project, a volunteer initiative that aims to support the Tor network by contributing (exit-)relays and bridges to the network, and I would like to quickly announce today's (initial) launch of our humble project to the Tor relay operator mailinglist. Without any further ado, our project website is available at http://wallawallaproject.org/ We certainly very much welcome questions, comments and suggestions! Have a great day. On behalf of the Walla Walla Project team, Thomas
admin:
Wow! Thank you for your contributions.
Could you confirm that you do not keep finger grain logs than the following vnstat? http://198.100.153.205/vnstat_m.png
Have a great day. On behalf of the Walla Walla Project team, Thomas
Could you publish a PGP key and use HTTPS for your website? All the best, Jacob
Hi Jacob, ---- On Thu, 18 Oct 2012 02:21:57 +0200 Jacob Appelbaum wrote ----
You're very welcome! Glad you like it. We've been working on this for almost two months now, considering the fundraising at sponsors. We have, btw, some more sponsoring in the pipeline (ongoing discussions)
Confirmed! We certainly do not keep any logs except the vnStat network monitoring. We decided to set this up as Atlas is a bit inconvenient when it comes to verifying the total amount of traffic transmitted/received within a day/month etc.
Have a great day. On behalf of the Walla Walla Project team, Thomas
Could you publish a PGP key and use HTTPS for your website?
Thanks a lot for your suggestions. Regarding the SSL certificate, we need to talk to our webhosting sponsor. We're on shared hosting without a dedicated IP address, but I guess a shared SSL certificate should be possible. We'll investigate this. Regarding the PGP key, this should be achievable quite fast & easy. It went by the board so far to be honest. Too much things to do to actually get the project off the ground. Will be fixed soon. Best, Thomas
On Thu, 18 Oct 2012 00:21:57 +0000, Jacob Appelbaum wrote: ...
Could you confirm that you do not keep finger grain logs than the following vnstat?
What is the acceptable granularity here?
That looks like by month, but the question is rather how often the number for the current month is updated. Someone interested in the history can just poll that often. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
Hi Andreas, Jacob, ---- On Thu, 18 Oct 2012 09:40:35 +0200 Andreas Krey wrote ----
Reading your response, I guess that I totally misunderstood Jacob's actual question (sorry Jacob, I thought you were asking about some mysterious logs other than the vnStat - which we certainly do not generate - and you obviously meant the vnStat itself). I'm German myself and not a native speaker. To answer sufficiently about the actual vnStat network monitoring: We set these up at all VPSs with standard vnstat configuration and we hourly generate (with vnstati) hourly, daily and monthly stats to the VPS webserver root directory with a cronjob. So, in fact, hourly, daily and monthly stats all get updated hourly on every VPS individually. Unfortunately Atlas does not provide a convenient way to see the total traffic transmitted/received within a day/month etc and as we have monthly traffic limits in place at sponsors, we decided to use vnStat to have an idea about the actual total traffic transmitted/received. I hope this answers the question sufficiently? Thomas
Hi, Thank you for the Walla Walla! :-) On 18.10.2012 13:29, admin wrote:
So, in fact, hourly, daily and monthly stats all get updated hourly on every VPS individually.
We actually do the same for all torservers.net nodes as documented at https://www.torservers.net/wiki/setup/server#generate_bandwidth_stats -- Moritz Bartl https://www.torservers.net/
Hi Moritz, I apologize for actually responding late. I'm currently performing an "almost one-man show" and the workload with the Walla Walla Project is enormous at the moment (behind the scenes so to speak). That said, please see my comments inline. ---- On Thu, 18 Oct 2012 13:38:05 +0200 Moritz Bartl wrote ----
Hi,
Thank you for the Walla Walla! :-)
You're welcome. Thanks a lot btw for the Twitter post!
I see. For your convenience, here is our approach: root@tailoredvps1:~# crontab -l ... 59 * * * * /usr/local/bin/vnstat_www.sh root@tailoredvps1:~# cat /usr/local/bin/vnstat_www.sh #!/bin/sh for i in h d m; do /usr/bin/vnstati -$i -nh -o /var/www/vnstat_"$i".png done Best, Thomas
On Thu, 18 Oct 2012 13:29:46 +0000, admin wrote: ...
Reading your response, I guess that I totally misunderstood Jacob's actual question
As far as I understood Jacob asked you how many traffic data point you log, and I asked him how many are acceptable. (And pointed out that the given screen, although showing only apparently monthly numbers, could be used to get more detailed information by polling it, depending on the update rate.)
So, in fact, hourly, daily and monthly stats all get updated hourly on every VPS individually. Unfortunately Atlas does not provide a convenient way to see the total traffic transmitted/received within a day/month etc and as we have monthly traffic limits in place at sponsors, we decided to use vnStat to have an idea about the actual total traffic transmitted/received.
I do similar, but I run a simple cronjob around ifconfig. :-) Also for seeing the total traffic consumption on my relays (and my home DSL). I then feed that into gnuplot for some graphs for me to see; and the interplay of RelayBandwithRate and RelayBandwidthBurst ist pretty plain to see in there. There are pretty obvious patterns esp. on low-bandwith relays; if you collected them all you'd possibly be able to reconstruct circuit usage. Hence my question how coarse traffic volume logging should be. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
Andreas, also to you, sorry for responding late. Please see my comments inline. ---- On Thu, 18 Oct 2012 15:16:06 +0200 Andreas Krey<a.krey@gmx.de> wrote ----
I understand. I'm certainly looking forward to a continued discussion here. That said, we currently update, as I outlined earlier, all hourly, daily and monthly vnstat graphs at an hourly interval. I provided our tiny script + cronjob in my previous answer to Moritz.
Nice approach. Would you mind sharing your fingerprint/nickname? I'd love to look at it with Atlas.
Ok, to be brutally honest, I'm obviously too naive at the moment to understand the actual issue thoroughly. Are you referring to some opportunity to draw conclusions about specific Tor users and effectively track/"uncover" them? I thought about that one for some time now but I, in all honesty, don't get it in detail. We have very many circuits open in parallel, even on the lower bw relays (I just looked at /var/log/tor/log at one of these lower bw relays), so I'd assume the diversity in connections is way too high to draw conclusions about single circuits by just looking at, even hourly updated, total traffic stats. Isn't it? We use the stats for a better understanding of total traffic, especially over time (e.g. I already noticed that there are some adjustments to the config needed for daily accounting/bandwidthrate/-burst for our higher bw relays utilizing these very traffic stats - as it seems, while the higher bw relays are blowing traffic out the door like crazy ;-), especially asurahosting1, the lower bw relays, e.g. tailoredvps1, do not even utilize the accounting to its full potential without a slightly higher bw_adv) For these kind of insights the stats are actually very much worth it currently. Looking forward to a continued discussion, Thomas
On Tue, 23 Oct 2012 20:32:25 +0000, admin wrote: ...
Atlas is too coarse to see that... or rather it looks like it doesn't believe in traffic that exceed the advertized bandwidth: http://atlas.torproject.org/?#details/26220AEA188B8D0E47BB541E1A616EB3AD7029... My graphs look like (not the near realtime one; just a sample): http://ch.iocl.org/tor/relay.png There you have the overruns and the following flatline in traffic as long as the 'Burst' is consumed. For comparison, my home dsl, where another relay does a burst (the part where out is half of in+out0: http://ch.iocl.org/tor/dsl.png (I also do plots of volume over time.) ...
Ok, to be brutally honest, I'm obviously too naive at the moment to understand the actual issue thoroughly. Are you referring to some opportunity to draw conclusions about specific Tor users and effectively track/"uncover" them?
Yes; although it's probably too little data indeed as long as you don't know where it's going; and most relays (esp. the exits) are too busy to produce discernible patterns this way. ...
We use the stats for a better understanding of total traffic, especially over time (e.g. I already noticed that there are some adjustments to the config needed for daily accounting/bandwidthrate/-burst for our higher bw relays utilizing these very traffic stats - as it seems, while the higher bw relays are blowing traffic out the door like crazy ;-), especially asurahosting1, the lower bw relays, e.g. tailoredvps1, do not even utilize the accounting to its full potential without a slightly higher bw_adv)
Indeed. Q is mostly burning its assigned bandwidth (and I wouldn't like to have circuits through it while it is in 'flatline'), while the home relay only sees occasional downloads (flat bursts), and the bridges hardly have any traffic. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
participants (5)
-
admin -
Andreas Krey -
Daniel Case -
Jacob Appelbaum -
Moritz Bartl