[tor-relays] R: Re: Request for Feedback on Relay Node Update Management

Thu Apr 4 13:39:22 UTC 2024

I made the changes you recommended and also added/edited these parameters in the torrc configuration file:
- RunAsDaemon 1
- RelayBandwidthRate 10 MB
- RelayBandwidthBurst 20 MB

But in spite of that I did not solve the problem.

I monitored via nyx what was happening on service reboot and noticed that it detects the tor control port closed. Regarding this setting in the torrc file I wrote.

- ControlPort 9051
- CookieAuthentication 1

And trying to run nmap to see if port 9051 is open it shows me open in LISTENING mode.

To make what I tried to report in this email clearer I have uploaded a 15-second video[1] that captures the exact moment when the shutdown occurs where you can see that at first port 9051 is working properly while at some point it seems to shut down automatically.

It's possible that the Tor service never ceases to function, but for some strange reason, the port 9051 stops functioning, preventing the control of Tor itself. As a result, it may appear that Tor has restarted, when in fact the uptime simply resets because the port 9051 is unreachable for a certain period of time.

[1] https://vimeo.com/930658793

martedì 2 aprile 2024 23:24, denny.obreham at a-n-o-n-y-m-e.net <denny.obreham at a-n-o-n-y-m-e.net> ha scritto:

> You should tweak your web server as presented in this section:
> 

> 

> 

> https://github.com/Enkidu-6/tor-ddos?tab=readme-ov-file#first-step-preparing-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 <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 spee d 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 fro m 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 f ind some of this useful,
> > > >> Seth
> > > >>
> > > >>
> > > >>
> > > >> [1] https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE
> > > >> [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 up dates, 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/47B72187844C00AA5D524415E52E3BE81E63056B
> > > >> > [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/
> > > >> >
> > > >>
> > > >> > ---
> > > >> >
> > > >>
> > > >> > 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
> 

> 

> html, body { overflow-y: hidden; } div[contenteditable] { outline: none; } blockquote:not([style*=border-left]){border-left:1px solid #ccc;margin-left:6px;margin-top:0;margin-bottom:0;padding-left:12px}body.dark blockquote:not([style*=border-left]){border-left-color:rgb(255,255,255,.15)}body.dark:not([style*=color]){color:rgba(190,195,200,.9)} .ql-align-left{text-align:left}.ql-align-center{text-align:center}.ql-align-right{text-align:right}p{margin:0;padding:0;line-height:1.231;}blockquote{margin:0 0 0 .8ex;border-left:1px solid #ccc!important;padding-left:1ex}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240404/cf61716f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - alessandro.greco.1 at protonmail.com - 0x1D14CC10.asc
Type: application/pgp-keys
Size: 3178 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240404/cf61716f/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 855 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240404/cf61716f/attachment-0001.sig>