Hello everyone,

On March 28, 2022 8:57:51 PM GMT+02:00, gus gus@torproject.org wrote:

The next Tor Relay Operator meetup will happen this Saturday, April 2 @ 1900 UTC / 1500 EDT / 2100 CET.

Friendly reminder, today is the day. :-)

- Leibi

Hello,

Thanks everyone for joining us last saturday!

The next Tor Relay Operator meetup is on May 21st at 1900 UTC.

Here is our meetup notes.

cheers, Gus

## Tor Relay Operator - April 02, 2022

* EOL relays and bridges removal update (GeKo)

* Overload reporting adjustment (GeKo): * https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/27 * https://gitlab.torproject.org/tpo/core/tor/-/issues/40560 * Added to 0.4.7.5-alpha, with backport to 0.4.6 coming

* Bridges contact info are now public listed (gus)

In Colector we stopped sanitizing contact info for bridges:

https://lists.torproject.org/pipermail/tor-project/2022-April/003329.html https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/...

* Announcement: 0.4.7 release is coming up soon (just released last alpha) around May 15th

* "Expectations for relay operators", as a periodic fyi that we do at each of these meetings: https://gitlab.torproject.org/tpo/community/relays/-/issues/18 -- feedback is great if you have any! :)

### Q&A part of the meeting

* Best practices to secure relays and bridges

We discussed in a previous relay operator meetup about having a *workshop* for giving this guidance to people. We have two people, Kushal and BSD George, who are excited to help lead the workshop. We need to pick a day and time to try a 1-hour workshop. One point is to help people understand how to configure MyFamily and why configuring it is important for helping the network health team distinguish imposter relays -- which are not just theoretical these days, bad people are actually setting up imposter relays trying to make it look like you misconfigured your Family.

There's a ticket: https://gitlab.torproject.org/tpo/community/relays/-/issues/36

* But bridges still shouldn't set MyFamily, right?

Right. But, we have a plan for the future that will let us fix that situation. Stay tuned: https://gitweb.torproject.org/torspec.git/tree/proposals/321-happy-families....

* Is a open metrics port really that bad? Why?

The metrics port gives out traffic details that are too-finegrained to publish. Having your metrics port open to the world will expose that info to people who should't have it. Please keep metrics port output private.

* Is anybody here hitting the ORPort self-test bug that seems like it might be new in 0.4.5 / 0.4.6? https://gitlab.torproject.org/tpo/core/tor/-/issues/40424 It's hard to tell if it's widespread or just a few people.

Nobody on the chat at the time says that they experienced the bug. This is a good sign at least. :)

* My 0.4.6.10 FreeBSD bridge disappeared from the metrics site. What happened?

Best answer is to ask on irc when this happens. It sounds unrelated to your OS, and more likely to be something else. Maybe your ORPort is closed so your bridge stopped publishing. Be sure to check out your Tor logs as a first step too.

* Performance tweaks for high bandwidth / multi instance servers, [server confi templates - Torservers](https://github.com/torservers/server-config-templates/). What about HardwareAccel, NumCPUs?

In the distant past, AES instructions in the chipset were rare, and you needed to tell your Tor to tell your openssl to use hardwareaccel. In the glorious present, maybe openssl just auto does it for you? Somebody should do some experiments. One key hint: Tor tells you at info-level in its logs about whether it's using accel.

* How about NumCPUs? On my computer I have 64 cores, 64 instances and NumCPUs defaults to using 16 of them (on each instance).

Current C-Tor does AES and TLS in the main core, and it farms out circuit handshakes to other cores. So it is not as multi-threaded as we might want. So to turn it around: on your huge machine, how are those 16 threads doing? Are they mostly full? In that case yes set NumCPUs explicitly. If no, maybe it is fine as is.

* I am new to Linux and Tor. I have Debian up and running on a laptop. Is there any good "getting started with Tor" resources for beginners like me?

Yes, we have some docs on the Community portal:

- Run a Bridge: https://community.torproject.org/relay/setup/bridge/

- Run a Snowflake Standalone Proxy: - https://community.torproject.org/relay/setup/snowflake/standalone/ - https://packages.debian.org/search?keywords=snowflake (snowflake-proxy available in debian unstable) - https://hub.docker.com/r/thetorproject/snowflake-proxy (Docker)

* Suggestion for reducing the amount of EOL relays: Promote/link the unattended-upgrade guide and tor-repo information more visible.

I wonder where we should put this to make it more visible. One option could be on relay-search when we show the "Not Recommended" banner. [GeKo]

* Is it dangerous to run Snowflake from a home-network?

Mostly it is ok? If you are in Russia, I would not recommend doing it. But if you're in a country that's not at war, it should be fine.

We are seeing some people confused about Snowflake-proxy vs Snowflake-client. If you check the [Metrics portal](https://collector.torproject.org/recent/snowflakes/), you can see that the #3 country running Snowflake *proxies* is Russia. And apparently they aren't getting punished. Maybe people there are getting confused and thinking that they are helping get around their own censorship by installing the Snowflake extension? Is it good idea to leave it as-is, because getting more proxies is good, or it is better to understand and fix it, because one day it might lead to something unwanted?

* What does your ISP see if you have snowflake proxy?

Your internet provider will see:

(a) a TLS connection to the (centralized) snowflake broker, (b) WebSocket connection to the (centralized) Snowflake bridge, (c) - less specific - some WebRTC connections to censored countries when you are assigned to someone.

So if your ISP knows the IP addresses of those centralized services (or sees DNS lookups for them, or their SNI - endless possibilities, proxies are not designed to be unblockable by their own ISP), they could conclude that you're being a Snowflake volunteer. I guess they could try to block your connections at that point? We haven't seen any problems here.

* It's hard to explain the difference between snowflake client, proxy and server on AUR (archlinux user repository), some "official" resource would be nice.

Yes, we are looking into this.

* Are there any plans to add an obfs4proxy package to the torproject debian repository?

The new obfs4proxy package is in Debian sid, and now in Debian backports. There's a ticket to get it into Ubuntu backports but it's unclear how long that will take.

We have a policy at deb.torproject.org that we only include things that are already packaged in Debian. So, that policy is compatible with this idea! We could do it. And maybe we really should, because otherwise the Ubuntu people will have a tough time getting their proper obfs4proxy package. The main barrier is having people who will shepherd the process to its end. Any volunteers? :)

* Please add prometheus support (process uptime, memory usage, bandwidth usage, number of users served, ...) to snowflake proxy (standalone) so we can detect crashed snowflake proxies

Right -- please open tickets on gitlab.torproject.org with the desired behavior. And as an extra bonus, please include a patch for it to work. :)

* Do other relay operators also see occasionally sudden connection spikes on their relays? Does anybody know what causes this?

Please file a ticket to help us investigate! https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/

If it's a one-day spike, a good explanation is that your relay became the HSDir for a super popular onion service. In the past, those were typically dead botnet C&C controllers, where some jerk had tried to sign his botnet up to use Tor for command-and-control, but realized it wasn't a good idea and stopped, but the bots still tried to reach the dead C&C, causing onion service descriptor fetching hotspots.

But if it's a 20 minute spike, it sounds like it's not that. A mystery! Open a ticket please. :)

* "Flood of resolve attempts overwhelms unbound on relays" The unbound bug, and/or the Tor exit relay overload issue - https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/30

Please add all the hints you have to the ticket!

One thing that seems like it might help: put your dns resolver on a different (outbound) IP address than your Tor exit relay. That way when .ru censors your exit relay, it doesn't block the dns queries you make to .ru.

### Next Tor Relay Operator Meetup

* May 21st 1900 UTC

### Other resources for relay operators

- The [tor-relays@ mailing list](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays) - The #tor-relays irc channel (IRC.OFTC.NET) or [Matrix](#tor-relays:matrix.org) - The [forum.torproject.net forum](https://forum.torproject.net/c/support/relay-operator/17)

On Mon, Mar 28, 2022 at 03:58:00PM -0300, gus wrote:

Hello relay operators and Tor friends,

The next Tor Relay Operator meetup will happen this Saturday, April 2 @ 1900 UTC / 1500 EDT / 2100 CET.

Where: BigBlueButton - https://tor.meet.coop/gus-og0-x74-dzn

No need for a registration or anything else, just use the room-link above.

The agenda is available here: https://pad.riseup.net/p/tor-relay-meetup-april-2022-keep

Everyone is free to bring up additional questions or topics at the meeting itself.

Please share with your friends, social media and other mailing lists!

cheers, Gus -- The Tor Project Community Team Lead