[tor-relays] R: Re: Request for Feedback on Relay Node Update Management
denny.obreham at a-n-o-n-y-m-e.net
denny.obreham at a-n-o-n-y-m-e.net
Tue Apr 2 21:24:06 UTC 2024
You should tweak your web server as presented in this section:
https://github.com/Enkidu-6/tor-ddos?tab=readme-ov-file#first-step-prep
aring-your-system-for-high-number-of-connections
This would most likely solve Out-Of-Memory problems I suspect you are
experiencing.
Denny
On 04/02/2024 10:06 AM Alessandro Greco via tor-relays wrote ..
My computer has:
- 1 vCore CPU
- 1 GB RAM
- Maximum bandwidth: 1 GB/s
So if I understand correctly, the problem should not be at the hardware
level, right?
Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays
<[1]tor-relays at lists.torproject.org> ha scritto:
Hello Aleff,
That is up to you. I strongly suspect that the hardware is the
bottleneck, but detailed specifications are required in order to
determine a conclusion. Tor is currently bounded by single-thread
CPU performance, with a minimum recommendation of 1 GB of RAM for
non-exit relays faster than 40 Mbit/s. If your hardware does not
meet these RAM requirements, upgrade it, then adjust the relay
bandwidth rate limit as necessary.
Frank
Mar 27, 2024, 7:00 AM by tor-relays at lists.torproject.org:
> I want to thank you for all the support replies you sent in
response to my previous communication. I have carefully read through
all your insights and appreciate your efforts in trying to find a
solution to the issue.
>
> After thorough consideration of the matter, I have concluded that
the problem may not be due to configuration errors in the automatic
updates, as initially speculated. Rather, it seems that the issue
could be hardware-related, with my VPS computer potentially unable
to handle a certain amount of traffic.
>
> It's worth noting that there are no bandwidth issues, and the
connection speed is high. However, I have set a RelayBandwidthRate
limit of 250 Mbits. Interestingly, despite this configuration, the
Tor Metrics site detects a speed of approximately 10/13 MBytes,
equivalent to about 90/110 Mbits. This led me to speculate that the
machine might experience an overload of operations or connections,
causing it to crash temporarily. As a result, at the time of
restart, Tor Statistics records the maximum speed reached up to that
point (without ever reaching the set limit). Subsequently, following
this theory, the Tor service restarts automatically without causing
any anomalies in the service.
>
> To address this situation, I have decided to reduce the
RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls
within the minimum limits proposed by torproject. If this is the
case, however, it is also true that it would be best to impose an
upper limit of 80% when considering the bandwidth magnitude
involving the crash event as the maximum point. I honestly don't
know how I would be able to verify this and acquire this kind of
data, probably doing trial and error is the way. Perhaps the ideal
would be to lower the maximum bandwidth further to verify for sure
that this is what it is?
>
> Currently, I am closely monitoring the situation to assess whether
this modification has a positive impact on the issue.
>
> I will keep you updated on any progress, and I thank you once
again for your support and understanding.
>
> Best regards,
>
> Aleff.
>
> ---
>
> Browse my WebSite: aleff-gitlab.gitlab.io
> Use my PGP Public Key:
pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85
> Join to support:
> - Free Software Foundation! (my.fsf.org/join?referrer=6202114)
> - Electronic Frontier Foundation! (eff.org)
> - Tor-Project (torproject.org)
> - Signal (signal.org)
>
> martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays ha
scritto:
>
>> Hi Alessandro,
>>
>> It's good to hear from you. I have a relay in a somewhat similar
situation[1], although I've only just clocked it. If you're using
Debian or one of its derivatives, then you can configure the
unattended-upgrades package to perform a restart at a specific time
if required. This means that your relay won't restart every time an
upgrade is required, but will keep itself up to date. I think
configuring a time for a daily restart (if upgrade required) would
be a fairly good balance between stability and reliability.
>>
>> See what other people say or from your own experience, as Tor
circuits are generally quite resilient and as long as you aren't a
guard node I believe connections won't die because your relay is
restarting.
>>
>> I would also note that Tor recommends [2] an uptime or 24/7 is
nice, but not required and that restarts to the daemon or node are
fine. Because of this, it might not be worth worrying too much about
this issue.
>>
>> I hope you find some of this useful,
>> Seth
>>
>>
>>
>> [1]
https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D8
7C1222177BB099E55AE
>> [2] https://community.torproject.org/relay/relays-requirements/
>> -------- Original Message --------
>> On 26/03/2024 08:54, Alessandro Greco via tor-relays
tor-relays at lists.torproject.org wrote:
>>
>> > Dear Tor-Relays Mailing List Members,
>> >
>>
>> > I hope this email finds you well. I'm reaching out to share
some observations and pose some questions regarding the management
of relay node updates, particularly concerning their impact on
stability and security of the service provided.
>> >
>>
>> > Recently, I've noticed an interesting pattern with my relay
node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've
followed TorProject's recommendations [2] and configured automatic
updates, which has led to frequent restarts of the node to keep the
Tor software up-to-date. While this practice ensures high security
by keeping the software updated, it seems to compromise the
stability of the node itself. The Uptime value of my node has
remained at a maximum of a few hours.
>> >
>>
>> > This situation has prompted me to reflect on what might be the
best strategy to adopt. On one hand, frequent updates ensure optimal
security, while on the other hand, continuous restarts may affect
the user experience for those relying on the node's stability for
their Tor activities.
>> >
>>
>> > As such, I'd like to pose some questions to the community to
gather feedback and assess best practices:
>> >
>>
>> > 1. In your opinion, is it preferable to maintain automatic
updates to ensure maximum security, even if frequent restarts may
compromise the node's stability?
>> > 2. Or would it be more sensible to adjust the update frequency,
perhaps performing them once or twice a week, to ensure greater
stability of the node without excessively compromising security?
>> > 3. Have you had similar experiences with your relay nodes? How
have you addressed this challenge and what were the outcomes?
>> >
>>
>> > Thank you in advance for your time and cooperation.
>> >
>>
>> > Best regards,
>> > Aleff.
>> >
>>
>> > [1]
https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524
415E52E3BE81E63056B
>> > [2]
https://community.torproject.org/relay/setup/guard/debian-ubuntu/upd
ates/
>> >
>>
>> > ---
>> >
>>
>> > Browse my WebSite: aleff-gitlab.gitlab.io
>> > Use my PGP Public Key:
pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85
>> > Join to support:
>> > - Free Software Foundation! (my.fsf.org/join?referrer=6202114)
>> > - Electronic Frontier Foundation! (eff.org)
>> > - Tor-Project (torproject.org)
>> > - Signal
(signal.org)_______________________________________________
>> > tor-relays mailing list
>> > tor-relays at lists.torproject.org
>> >
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>>
>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
_______________________________________________
tor-relays mailing list
tor-relays at lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
1. file:///tmp/.webmin/reply_mail.cgi?new=1&to=Il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240402/b0ce2649/attachment.htm>
More information about the tor-relays
mailing list