- tor-relays - lists.torproject.org

ubuntu focal and Tor
by potlatch 28 Aug '20

28 Aug '20

Question: What's with the failure when installing Tor of the "no valid keys" for focal? I've had to back up to ubuntu 18 several times. --potlatch-- Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Hello CypherpunkLabs Tor relays
by nusenu 25 Aug '20

25 Aug '20

Hello CypherpunkLabs, I noticed your set of new relays and wanted to say hi, welcome you to the Tor relay community and give you a few recommendations and pointers especially since you are aiming to run 100 tor relays. The Tor relay guide has a lot of useful information, so you probably want to start there: https://torproject.org/relay-guide Since all your current relays appear to be OVH based I'd like to point out the following quote from the guide: > Try to avoid the following hosters: > > OVH SAS (AS16276) > Online S.a.s. (AS12876) > Hetzner Online GmbH (AS24940) > DigitalOcean, LLC (AS14061) https://community.torproject.org/relay/technical-considerations/ The reasoning behind this, is that those hosters are already hosting many tor relays, and the network dislikes centralization. OVH is the biggest commercially available tor hoster in terms of exit capacity today already. Depending on your per-relay size you might end up running a big fraction of the network and especially big exit operators are encourage to take care of their DNS resolution. Specific guidelines can be found here: https://community.torproject.org/relay/setup/exit/ IPv6 connectivity is also encouraged (which currently none of your relays appear to have). Especially for big operators it is recommended to managed their relays using configuration management (puppet, salt, ansible, ...) and update them regularly. An ansible role for Tor relay operator (I maintain) can be found at: https://github.com/nusenu/ansible-relayor The ContactInfo Information Sharing Specification is a spec about a machine readable ContactInfo string: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification Your site suggests that you (will) run bridges and exits. Combining these two types of nodes under a single operator is generally a bad idea since tor's MyFamily configuration is not supported for bridges, so users might end up using your bridges _and_ your tor exits - which puts them at risk should someone compromise you, please consider running non-bridges only. For strong protections for your long term relay keys you can use tor's OfflineMasterKey feature, especially relevant if your run a big fraction of the network: https://2019.www.torproject.org/docs/tor-manual.html.en#OfflineMasterKey kind regards, nusenu PS: don't forget about your MyFamily setting if you do not choose a solution that manages that for you automatically. -- https://mastodon.social/@nusenu

2 1

IPv6 Support or Uptime?
by Josh Lawson 24 Aug '20

24 Aug '20

I have IPv6 with my ISP, but there seems to be a bug in the firmware of my networking equipment that causes IPv6 to stop working periodically and I have to take my network down and bring it back up. If I do not do this, my relay stops functioning as I have torrc configured to use IPv6 and IPv4. So, my question is whether or not having a higher uptime is more important or having IPv6 support? My relay never goes down when on IPv4 only. I apparently cannot have both until the firmware bug is fixed. I appreciate it!

4 4

Tor bandwidth scanner "longclaw" slow to the US West Coast
by Neel Chauhan 23 Aug '20

23 Aug '20

Hi, I believe the Tor bandwidth scanner nicknamed "longclaw" is measuring relays in the US West Coast worse than other bandwidth scanners in North America. This happens on multiple ISPs, both ones I have and ones I don't. This includes two Tor exit instances on a dedicated server hosted in Los Angeles on Psychz Networks (AS40676): https://metrics.torproject.org/rs.html#details/156AAC3FAD1ACC8906316519DCB4… https://metrics.torproject.org/rs.html#details/A69CEB30328B1E85C6B167FECAF2… And two Tor non-exit instances on a home server in Seattle on Wave Broadband (AS11404), using a symmetrical Gigabit link: https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF… https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48… The consensus weight values from longclaw are much lower than other North American bandwidth scanners, according to https://consensus-health.torproject.org/. This also affects other relays/ISPs on the West Coast US/Canada, such as Emerald Onion, AT&T U-verse, Sonic.net, and QuadraNet. The same ISPs/hosts in the East Coast aren't affected. This discrepancy in the measurement disproportionately favors European and East Coast US/Canada relays at the expense of West Coast relays, centralizing the Tor network even further than it already was. This wasn't an issue in the past, even as early as a few months ago. It only started appearing around June. Is anyone else hosting West Coast relays having this issue? Is "longclaw" actually measuring bandwidth from Europe? If so, WHY? I got in contact with "longclaw"'s admin and he wasn't too helpful. Best, Neel Chauhan === https://www.neelc.org/

4 4

Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)
by nusenu 23 Aug '20

23 Aug '20

Hi, here is my motivation for working on automated verification of operatorurls in ContactInfo: https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in… -- https://mastodon.social/@nusenu

9 16

relayor v20.1.0 is released
by nusenu 23 Aug '20

23 Aug '20

Hi, relayor v20.1.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor This version contains a bugfix, for corner cases where the newly generated tor configuration would not be used. relayor users are encouraged to update to this release. Changes ------- * bugfix: restart tor instead of reloading it when configuration changed (reloading is not supported by tor in all cases) * make tor_ContactInfo variable mandatory * update tor alpha version: 0.4.3 -> 0.4.4 * add support for FreeBSD 11.4 * increase min. ansible version to 2.9.12 kind regards, nusenu -- https://mastodon.social/@nusenu

1 0

Re: [tor-relays] Tor bandwidth scanner "longclaw" slow to the US West Coast
by info＠backplanedns.org 21 Aug '20

21 Aug '20

Same herehttps://metrics.torproject.org/rs.html#details/29BBD80A1702C7FDEF6557C4… from my T-Mobile 4G LTE device------ Original message------From: EddieDate: Wed, Aug 19, 2020 6:40 PMTo: tor-relays(a)lists.torproject.org;Cc: Subject:Re: [tor-relays] Tor bandwidth scanner "longclaw" slow to the US West CoastNot sure if my relay is similar, but I've been seeing a slow fall in consensus weight and advertised bandwidth over the past few months even though absolutely nothing has changed at my end. Well, apart from me *increasing* the RelayBandwidth settings. Also before I shut my relay down for a couple of weeks late last year, it had, and maintained guard status for about 6 months. Now it yo-yos in and out of guard on a regular basis. https://metrics.torproject.org/rs.html#details/D195E5CE8AE77BAC91673E6CFB7B… Cheers. On 8/15/2020 5:41 PM, Neel Chauhan wrote: > Hi, > > Is anyone else hosting West Coast relays having this issue? Is > "longclaw" actually measuring bandwidth from Europe? If so, WHY? > _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

don't publish detailed metrics about your relays
by nusenu 20 Aug '20

20 Aug '20

Don't publish detailed metrics about your relays. Here is a good example what NOT to do with your relays: http://51.77.135.89:19999/#menu_net_submenu_eno1;theme=slate http://51.75.144.43:19999/#menu_net_submenu_eno1;theme=slate The relay guide has detailed guidelines on what granularity is considered safe. -- https://mastodon.social/@nusenu

2 1

"Our IP Address has changed from" log lines
by torix＠protonmail.com 17 Aug '20

17 Aug '20

Dear list, I get this on just one of my relays - "Our IP Address has changed from xxx toxxx; rebuilding descriptor (source: METHOD=GETHOSTNAME HOSTNAME=xxx). Aug 11 00:33:54.000 [notice] Your IP address seems to have changed to xxx (METHOD=GETHOSTNAME HOSTNAME=xxx). Updating." This is 99% of my tor log. What's going on? Is this normal for a middle relay and somewhere I've set the log level to be too sensitive? My torrc log line: Log notice file /var/log/tor/notices.log # location to log notices, warnings, and errors: But my other relays have the same line. I was looking at this relay because it only seems to connect with the bwauths every few days to a week - now not showing at all. It has stayed at 200 connections for the last 6 weeks as a result. It is currently missing completely from the tor metrics list. But I have no idea if these 2 things are related. I have run it with and without ipv6 with the same results. Any help I would appreciate, --Torix

2 2

Possible to run multiple tor instances from one machine?
by Keifer Bly 16 Aug '20

16 Aug '20

6 5