On Thu, May 05, 2022 at 12:19:42AM -0300, gus wrote:
> Hello relay operators,
>
> The next Tor relay operator meetup will happen on Saturday, May 21 @ 1900 UTC.
>
> Where: BigBlueButton - Tor Relay Operator Meetup
>
> No need for a registration or anything else, just use the room-link
> above.
>
> We're working on the agenda here:
> Riseup Pad
>
> 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
We are working with volunteers on a hackfest to develop a bridge
distribution mechanism that uses Signal (woo). They might be on
irc at #tor-dev; if you see them, help them!
MCH event (in July): May Contain Hackers 2022
At least four core Tor people will be present at this conference. Hopefully there will be a relay operators meetup. But there is no schedule published yet, so, stay tuned!
“Sysadmin 101” workshop in June, will be announced on tor-relays@
mailing list.
If you’re a relay operator but not comfortable with sysadmining, please
join the workshop! It will be faciliated by George (BSD fan) and Kushal
(Linux fan): “How to run a good relay for the Tor network” – learn to
configure your time properly, and everything else.
Historically, we were tied closely to the Debian release cycle,
including having a “long term stable” that we support for years so
it can be in Debian.
We would much prefer relays to use the deb.torproject.org debs,
which will keep people on the latest Tor stable.
The new proposal is to drop the long term stable idea, and
ultimately we only allow relays onto the network if they’re running
the latest versions.
Feedback: Getting recent Tor versions into OpenBSD (*/6 mos),
NetBSD/pkgsrc (quarterly) stable is going to be a challenge. People
need to reach out to their package repositories and begin that
discussion.
The plan is that clients can stay on a Debian stable, and we will
try to keep supporting them. So it is only relays that need to do
this faster cycle.
We also need to make sure to avoid having many old zombie clients
trying to reach the network.
People have been asking us every so often about the “kax17” attacker
that was publicized in blog posts in the past. We were trying to
decide how to react to those – leave it quiet, make new publicity,
something else? Ultimately we decided to do a blog post on our own to
summarize what the network health team has been doing for bad-relays,
and using the kax17 as an example of what we did in the past, where we
failed, how we learned from it.
[Discussion about whether it makes sense to do a new blog post for
each new attack, or what. Brief summary is yes [The “yes” was more
to an announcement, say, on tor-relays@ than doing a blog post. Blog
posts for this kind of things should be really a rare exception --GeKo]
if it results in a huge surprising drop in network size, but no if it is
yet another small attack similar to the one before it.]
We need exit relay operators and onion service operators to upgrade
to 0.4.7. Once both of these sides are upgraded, then everybody will
see better performance.
Next step is to make a Tor Browser release with a client version
that uses congestion control. At that point we expect to see network
load going up, i.e. your relays will use more of their capacity.
Traffic – Tor Metrics the spike in
advertised bandwidth at the end is (hopefully!) due to the new
feature.
Next step after this is multi-path (Conflux).
What’s the time plan, or version plan, for Conflux?
We delayed 0.4.7 to have congestion control, which was a huge
process. Conflux will come in 0.4.8 or 0.4.9, i.e. in the next 6
to 12 months, woo.
This is the periodic notice at each of these relay operator meetups,
to let you all know that we have written down some expectations for
our relays and for our relay operators, in terms of being good and
useful members of our community. Please take a look!
Q&A
We’ve seen occasional traffic peaks in the last few weeks, is this Tor
0.4.7 already? For example exit nodes seen 2x the traffic for 10-20 minutes.
If they are short term traffic peaks, you might also briefly be
the introduction point (or HSDir, if it was entire day) for an
onion service that is under attack (or just very popular). DDoS
attackers send huge sets of intro cells toward the introduction points.
Tip: run Prometheus on our relay, and see if your dns resolving
software sees traffic spikes in the same period as your traffic spike.
When our relays are under heavy load, the Prometheus exporter is
unable to talk to the control socket, and we get alerts. Is this
known/should I create an issue?
Yes, but also much more lightweight on information. It doesn’t even
have traffic metrics, AFAIK. It seems to be mostly about errors/overload
status.
I think it has traffic stats. About errors is log file.
Probably not going to get fixed in c-tor. The arti sitation has a
better architecture and so it shouldn’t suffer from this particular
issue.
wrt to the change of tor release policy: it was our impression
that tor gitlab tickets relevant to large relay operators did not
get much attention in the last two years so we are glad you are
formalizing what has been our impression anyway but that also
means we will see no progress? for a while in the tor relay ops
area? (until rust tor is ready)
We aren’t planning to completely ignore relay support in C-tor.
For example, Conflux as discussed above.
We’re certainly ramping down the efforts on C-tor relays – e.g.
being very narrow in terms of what new features we add.
If you have tickets or features or bugs that you think are
important, raising them on the tor-relays@ list, or talking to
Gus or network team or network health team people, are all good ways
forward.
