Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)
On 3/5/22 13:40, flux via tor-relays wrote: Hi, will there be a recording? Unfortunately I won't be able to attend. Unfortunately not flux. We will catch you next time. Pad notes will be posted after the meeting. g Best, flux On 3/4/22 18:16, gus wrote: Hello everyone, This Saturday, March 5th @ 2000 UTC, we have a Tor Relay Operator Meetup! We'll share some updates about Tor Network Health, Tor Bridges and the ongoing situation in Russia/Ukraine (Snowflake surge, bridges blocked, BBC and DW onionsites). Everyone is free to bring up additional questions or topics at the meeting itself. Date & Time: March 5, 2022 - 2000 UTC Where: BigBlueButton room - https://tor.meet.coop/gus-og0-x74-dzn No need for a registration or anything else, just use the room-link above. Please share with your friends, social media and other mailing lists! cheers, Gus ___ 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] rdsys was ignoring BridgeDistribution
Hey, never mind, with some coffee I find them :blush: Not blocked in Russia (yet) \o/ Thanks anyway and have a great weekend! Fran On 3/4/22 19:08, Fran via tor-relays wrote: Hey, stuff like this happens meskio, thanks for the effort! Slightly off topic: I couldn't find my bridges in the files under https://metrics.torproject.org/collector/recent/bridge-pool-assignments/ But they seem to work (although not getting much traffic): Heartbeat: Tor's uptime is 16 days 6:00 hours, with 39 circuits open. I've sent 31.25 GB and received 34.24 GB. I've received 9792 connections on IPv4 and 1095 on IPv6. I've made 54819 connections with IPv4 and 16694 with IPv6. While not bootstrapping, fetched this many bytes: 247726854 (server descriptor fetch); 22993 (server descriptor upload); 26840442 (consensus network-status fetch); 1784 (authority cert fetch); 2540630 (microdescriptor fetch) https://bridges.torproject.org/status?id= returns: Bridge advertises: * obfs4: functional Last tested: 2022-03-04 16:28:39.248278403 + UTC (1h26m57.41568s ago) Setting is "BridgeDistribution any" Any ideas why this might be? Thanks, fran On 3/4/22 16:56, meskio wrote: As mentioned before[0] BridgeDB now uses rdsys as backend. I just found out that there was a bug in rdsys and the BridgeDistribution configuration was ignored. Private bridges configured with 'BridgeDistribution none' might have being distributed by bridgedb if they were not configured with 'PublishServerDescriptor 0'. Disabling PublishServerDescriptor stops the bridge from sending it's descriptor to the bridge authority, so rdsys doesn't know it exists. Other bridges configured to be used by an specific distributor might have being distributed by a different one. This has being happening from February 28th ~12:00UTC until today March 4 ~12:00UTC. You can search for your hashed fingerprint in the pool assignments during this period if you want to know to what distributor was your bridge assigned to: https://metrics.torproject.org/collector/recent/bridge-pool-assignments/ Only bridges assigned to moat, email or https might have being distributed, as telegram, settings and reserved bridges are not distributed at the moment. The metrics relay search[1] will take some time to display the new assignments. I'm sorry for the situation. [0] https://lists.torproject.org/pipermail/tor-relays/2022-February/020365.html [1] https://metrics.torproject.org/rs.html ___ 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] Good hosting providers for an exit node
I run a middle relay at home but now I’m planning to also lease a VPS to run an exit node. I’d appreciate any suggestions for a good hosting provider. My first choice would have been BUYVM, but it seems they’re always out of stock. This will be my first time working with a VPS and Linux, so wish me luck! Chuck Bevitt Sent from my iPad ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to reduce tor CPU load on a single bridge?
David, > When I made my own combined graphs, I relied on different instances having different nicknames. I don't know an easy way to distinguish the descriptors of different instances otherwise. Please let me know what the Tor Metrics Team decides, if/when they reimplement the change. > You could conceivably do it by analyzing the periodicity of different instances' publishing schedules. (Start one instance on the hour, another at :10, another at :20, etc.) But that seems fragile, not to mention annoying to deal with. I agree. I'd rather manage unique nicknames. Thanks, again. Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Friday, March 4, 2022, 4:52:49 PM MST, David Fifield wrote: On Fri, Mar 04, 2022 at 09:40:01PM +, Gary C. New wrote: > I see that the metrics change has been reverted. > > If/When the metrics change is implemented, will loadbalanced Tor Relay Nodes > need to be uniquely named or will they all be able to use the same nickname? When I made my own combined graphs, I relied on different instances having different nicknames. I don't know an easy way to distinguish the descriptors of different instances otherwise. You could conceivably do it by analyzing the periodicity of different instances' publishing schedules. (Start one instance on the hour, another at :10, another at :20, etc.) But that seems fragile, not to mention annoying to deal with. ___ 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] How to reduce tor CPU load on a single bridge?
Georg, >> Are there any "Issues" submitted for a similar change to Concensus Weight >> and Relay Probability to Tor Metrics on Onionoo? It appears these values are >> still only being reported for a Single Tor Node. > Hrm, good question. I don't think so and I am not sure yet, whether we should make such a change. Do you mind me asking what the reluctance might be to extending Tor Metrics to include correct reporting of Concensus Weight and Relay Probability for Loadbalanced Tor Relays? It would provide a more accurate assessment of Tor Network Resources and assist DirectoryAuthorities in making more informed decisions. I would be happy to open an "Issue" on the topic for official Request For Consideration. Thank you and the Tor Metrics Team for all that you do in improving the Tor Network. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Friday, March 4, 2022, 12:22:06 AM MST, Georg Koppen wrote: Gary C. New via tor-relays: > Georg, > Yes! That is precisely it! > Please know that the change appears to be working with my loadbalanced Tor > Relay deployment as well. > Are there any "Issues" submitted for a similar change to Concensus Weight and > Relay Probability to Tor Metrics on Onionoo? It appears these values are > still only being reported for a Single Tor Node. Hrm, good question. I don't think so and I am not sure yet, whether we should make such a change. > A BIG Thank You to the Tor Metrics Team for the Issue-40022 implementation. You are welcome. It seems, though, the implementation was not correct. We therefore reverted it for now. However, we are on it. :) Georg > Respectfully, > > Gary— > This Message Originated by the Sun. > iBigBlue 63W Solar Array (~12 Hour Charge) > + 2 x Charmast 26800mAh Power Banks > = iPhone XS Max 512GB (~2 Weeks Charged) > > On Thursday, March 3, 2022, 1:28:12 PM MST, Georg Koppen > wrote: > > Gary C. New via tor-relays: >> David, >> Has Tor Metrics implemented your RFC related to Written Bytes per Second and >> Read Bytes per Second on Onionoo? > > That's probably > > https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40022 > > , no? > > Georg > >> As of the 27th of February, I've noticed a change in reporting that >> accurately reflects the aggregate of my Tor Relay Nodes opposed to the >> previously reported Single Tor Node. Are you seeing a similar change for >> snowflake.torproject.org? >> Additionally, other than the hourly stacktrace errors in the syslog, the >> secure_onion_key workaround seems to be working well without any ill >> side-effects. I've been able to operate with the same secure_onion_key for >> close to 5 weeks, now. Have you run into any issues? >> Thank you for your response. >> Respectfully, >> >> Gary— >> This Message Originated by the Sun. >> iBigBlue 63W Solar Array (~12 Hour Charge) >> + 2 x Charmast 26800mAh Power Banks >> = iPhone XS Max 512GB (~2 Weeks Charged) >> >> On Tuesday, February 8, 2022, 11:49:47 PM MST, Gary C. New via >>tor-relays wrote: >> >> David, >> Excellent Documentation and References! >> I hope the proposed RFC's (auth, key, and metrics) for loadbalanced Tor >> topologies are seriously considered and implemented by Tor Core and Tor >> Metrics. >> Great Work! >> Respectfully, >> >> Gary— >> This Message Originated by the Sun. >> iBigBlue 63W Solar Array (~12 Hour Charge) >> + 2 x Charmast 26800mAh Power Banks >> = iPhone XS Max 512GB (~2 Weeks Charged) >> >> On Tuesday, February 8, 2022, 10:02:53 AM MST, David Fifield >> wrote: >> >> The load-balanced Snowflake bridge is running in production since >> 2022-01-31. Thanks Roger, Gary, Roman for your input. >> >> Hopefully reproducible installation instructions: >> >>https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=6de6facbb0fd047de978a561213c59224511445f >> Observations since: >> >>https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40095#note_2774428 >> >> Metrics graphs are currently confused by multiple instances of tor >> uploading descriptors under the same fingerprint. Particularly in the >> interval between 2022-01-25 and 2022-02-03, when a production bridge and >> staging bridge were running in parallel, with four instances being used >> and another four being mostly unused. >> >>https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6915AB06BFB7F >> >>https://metrics.torproject.org/userstats-bridge-transport.html?start=2021-11-10&end=2022-02-08&transport=snowflake >> Since 2022-02-03, it appears that Metrics is showing only one of the >> four running instances per day. Because all four instances are about >> equally used (as if load balanced, go figure), the values on t
Re: [tor-relays] How to reduce tor CPU load on a single bridge?
David, I see that the metrics change has been reverted. If/When the metrics change is implemented, will loadbalanced Tor Relay Nodes need to be uniquely named or will they all be able to use the same nickname? I'm glad to hear your loadbalanced Snowflake Relay continues to work well. Thanks, again, for your efforts. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Thursday, March 3, 2022, 6:59:26 PM MST, David Fifield wrote: On Thu, Mar 03, 2022 at 08:13:34PM +, Gary C. New wrote: > Has Tor Metrics implemented your RFC related to Written Bytes per Second and > Read Bytes per Second on Onionoo? > > As of the 27th of February, I've noticed a change in reporting that accurately > reflects the aggregate of my Tor Relay Nodes opposed to the previously > reported > Single Tor Node. Are you seeing a similar change for snowflake.torproject.org? You're right. I see a change since 2022-02-27, but in the case of the snowflake bridge the numbers look wrong, about 8× too high. I posted an update on the issue. Thanks for noticing. https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40022#note_2783524 > Additionally, other than the hourly stacktrace errors in the syslog, the > secure_onion_key workaround seems to be working well without any ill > side-effects. I've been able to operate with the same secure_onion_key for > close to 5 weeks, now. Have you run into any issues? Yes, it's still working well here. ___ 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 Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)
Hi, will there be a recording? Unfortunately I won't be able to attend. Best, flux On 3/4/22 18:16, gus wrote: Hello everyone, This Saturday, March 5th @ 2000 UTC, we have a Tor Relay Operator Meetup! We'll share some updates about Tor Network Health, Tor Bridges and the ongoing situation in Russia/Ukraine (Snowflake surge, bridges blocked, BBC and DW onionsites). Everyone is free to bring up additional questions or topics at the meeting itself. Date & Time: March 5, 2022 - 2000 UTC Where: BigBlueButton room - https://tor.meet.coop/gus-og0-x74-dzn No need for a registration or anything else, just use the room-link above. Please share with your friends, social media and other mailing lists! cheers, Gus ___ 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
