Request for Feedback on Relay Node Update Management
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/47B72187844C00AA5D524415E52E3... [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)
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/5FEB80D4DCC63180CB4D87C122217... [2] https://community.torproject.org/relay/relays-requirements/ -------- Original Message -------- On 26/03/2024 08:54, Alessandro Greco via tor-relays <tor-relays@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/47B72187844C00AA5D524415E52E3... [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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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 <tor-relays@lists.torproject.org> 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/5FEB80D4DCC63180CB4D87C122217... [2] https://community.torproject.org/relay/relays-requirements/ -------- Original Message -------- On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@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/47B72187844C00AA5D524415E52E3... [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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
No dice, this solution did not solve the problem for me either. My VPS holds up well to a maximum traffic of this magnitude and the hardware resources are not used more than 50% but nevertheless it keeps shutting down and restarting the tor service up to a maximum Uptime of 3 hours (but often restarts earlier). I want to specify that it does not restart the VPS but only the tor service. I also do not detect any files in the path "/var/log/tor". I would not know what else to check. --- 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) mercoledì 27 marzo 2024 14:55, Alessandro Greco via tor-relays <tor-relays@lists.torproject.org> ha scritto:
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 tor-relays@lists.torproject.org 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/5FEB80D4DCC63180CB4D87C122217... [2] https://community.torproject.org/relay/relays-requirements/ -------- Original Message -------- On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@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/47B72187844C00AA5D524415E52E3... [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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays____________...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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@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 <tor-relays@lists.torproject.org> 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/5FEB80D4DCC63180CB4D87C122217... [2] https://community.torproject.org/relay/relays-requirements/ -------- Original Message -------- On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@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/47B72187844C00AA5D524415E52E3... [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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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@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@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 <tor-relays@lists.torproject.org> 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/5FEB80D4DCC63180CB4D87C122217... >> [2] https://community.torproject.org/relay/relays-requirements/ >> -------- Original Message -------- >> On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@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/47B72187844C00AA5D524415E52E3... >> > [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@lists.torproject.org >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hello, My computer has:- 1 vCore CPU- 1 GB RAM- Maximum bandwidth: 1 GB/sSo if I understand correctly, the problem should not be at the hardware level, right?For running a relay, I definitely recommend you upgrade to at least 2gb of Ram per vCore or 2GB per 1 Tor instance. On my fleet of relays the minimum spec I use is 2vCores and 4GB ram. John - prsv admin
Hello Aleff, It should be okay as-is, but I would temporarily upgrade the hardware to determine if it is the root cause. Frank Apr 2, 2024, 10:34 AM by tor-relays@lists.torproject.org:
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@lists.torproject.org <mailto:Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays <<a href=>> > 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@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 <tor-relays@lists.torproject.org> 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/5FEB80D4DCC63180CB4D87C122217... [2] https://community.torproject.org/relay/relays-requirements/ -------- Original Message -------- On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@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/47B72187844C00AA5D524415E52E3... [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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I have noticed that day by day the UpTime is increasing more and more (now it is up to over a day) and this is happening without me making any changes. This makes me think that somehow this is an expected thing. I do not read any errors in the log files so I consider the thread closed because apparently the problem (which is not actually a problem) has resolved itself automatically. I would love to be able to understand why it is improving but something is probably happening that only the developers could clarify for me. Thank you all for your help. Il lun, apr 15, 2024 alle 21:08, Frank Lý via tor-relays <tor-relays@lists.torproject.org> ha scritto: Hello Aleff, It should be okay as-is, but I would temporarily upgrade the hardware to determine if it is the root cause. Frank Apr 2, 2024, 10:34 AM by tor-relays@lists.torproject.org: > 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@lists.torproject.org <mailto:Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays <<a href=>> > 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@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 <tor-relays@lists.torproject.org> 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/5FEB80D4DCC63180CB4D87C122217... >> >> [2] https://community.torproject.org/relay/relays-requirements/ >> >> -------- Original Message -------- >> >> On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@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/47B72187844C00AA5D524415E52E3... >> >> > [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@lists.torproject.org >> >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >> >> >> >> >> >> _______________________________________________ >> >> tor-relays mailing list >> >> tor-relays@lists.torproject.org >> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hello Aleff, Yes. No. No. I used Debian, so updates were less frequent, maybe once every 3-5 weeks or so. Frank Mar 26, 2024, 3:03 AM by tor-relays@lists.torproject.org:
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/47B72187844C00AA5D524415E52E3... [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)
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 enough to immediately effectuate. Sometimes they can go ~60 days without needing a Tor restart. But your mileage may vary. For example some operators compile Tor daily and then a restart may be required more often. I do feel something is wrong in your configuration though. Tor certainly has updates occasionally, but not every few hours. Also in Tor Project's Debian repo[1] it looks like the last update was from 22-03 (and not a few hours ago). So you may want to check your apt configuration. I don't use Debian/Linux so someone else could maybe chime in to help you with setting that up properly. Regards, tornth [1] https://deb.torproject.org/torproject.org/dists/ Mar 26, 2024, 11:03 by tor-relays@lists.torproject.org:
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/47B72187844C00AA5D524415E52E3... [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)
On 3/26/24 09:54, Alessandro Greco via tor-relays wrote:
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.
I do run a bunch of Tor (bridges), all at Debian bookworm. I enabled automatic unattended updates for all packages (not the so-alled "security" ones). I did not observed any frequently restarts. My configs are in [1] and [2]. [1] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/templat... [2] https://github.com/toralf/tor-relays/tree/main/playbooks/roles/setup/files -- Toralf
participants (6)
-
admin＠prsv.ch -
Alessandro Greco -
Frank Lý -
mail＠nothingtohide.nl -
Toralf Förster -
torrelay.9puwh＠passinbox.com