Hi Tor operators,
Some of us took/will take advantage of the increase in allowed Tor relays per
IPv4 address[1] to reduce costs for running Tor relays. This change will result
in more relays sharing the same source IP address than before, which means
other relays using rate limits on their ORPo
Hi,
> No network experience but already running 2 TOR instances: 1 TOR service + 1
> bridge.
Very nice! You're asking some great questions and I'll try to answer as many as
I can :).
> My preferred choice at the moment is [3] where I would like to have 3 relays
> (one of each type; 3.5 GB RAM
Hi chani,
When I try to access
https://vagabyte.com/.well-known/tor-relay/rsa-fingerprint.txt I get a 404 Not
Found. So my guess is that this is (at least one of the) problem(s). See
https://nusenu.github.io/tor-relay-well-known-uri-spec/#well-knowntor-relayrsa-fingerprinttxt
as well for more
Hi,
> If I want to serve an HTML page for my exit node do I need Apache2/nginx or
> can I just modify my torrc?
You don't need a dedicated webserver as long as unencrypted HTTP is acceptable.
You can read more about the default HTML exit notice for Tor exit relays here:
https://community.torpr
Hi,
> Is there a way to be notified when a relay goes offline? Thanks.
For a few relays you could make an account on weather.torproject.org and add
your email address and relays. But pretty much any other remote monitoring tool
will suffice as well.
Cheers,
tornth
Feb 4, 2024, 22:30 by keif
Hi Allessandro,
My two cents:
I deliberately don't use automatic updates to improve relay stability and only
update when it's necessary. And this applies to any updates including the
FreeBSD/OpenBSD kernel (which requires a reboot as well). Not all updates are
security patches or are relevant e
Hi o/,
During the Tor Operator Meetup I asked about Quick Assist Technology (QAT)
support and was asked to bring it to the tor-relays mailing list so the network
team can take a look at the question.
In 2025 we're going to build one or more new servers and we're looking in to
optimizing the pe
Hi,
Thanks for your reply Alex! That mailing list thread is great and contains
quite some relevant pointers.
Some of my current Tor hardware (Intel C3958) is actually QAT compatible (it's
the one mentioned even) so based on the information in the thread I activated
to experiment:
- Kernel TLS
Hi,
Imo mobile chips with mostly low-performance 'efficient cores' are a suboptimal
fit for running Tor at scale. A couple of reasons:
- Performance between the different core types (efficient vs. performance) is
very different. You would need to lock Tor processes to specific cores and
accept
Hi,
To give some answers:
Yes this is completely normal! It can take 2-3 months for a new guard relay to
finally be 'ramped up'. Here you can read more about it:
https://blog.torproject.org/lifecycle-of-a-new-relay/. Exit relays ramp up much
faster in terms of bandwidth, but come with their own
Hi,
> Summary from your email - did I miss anything?
Yes, with the general disclaimer (not to sound like a lawyer) that your mileage
may vary. For example we run everything bare metal on FreeBSD and run a mix of
guard/middle/exit relays. Running the same workload virtualized or on another
oper
Hi,
Many people already replied, but here are my (late) two cents.
> 1) If a full IPv4 /24 Class C was available to host Tor relays, what are some
>optimal ways to allocate bandwidth, CPU cores and RAM to maximize utilization
>of the IPv4 /24 for Tor?
"Optimal" depends on your preferences and
12 matches
Mail list logo
