Greetings relay operators. A question that came up offline for relay operators can be summed up in one sentence, paraphrased from flexlibris: as a relay operator, what "things" do you wish you knew before you started running a relay? I'm really curious, in particular, to hear from those relay operators who are less connected to others, and are maybe more isolated physically from the community. In the long-ago past, many of us ran exit nodes without giving it much thought or preparation leading to ISP issues, but that seems less common today. For others, there might be a learning curve in keeping a network service up with decent uptime, while updating the relevant ports and operating system. There's no irrelevant answers to this, including more boring issues such as paying for the relay, choosing a provider or experiences as a (conscious) exit node operator. Bonus point for showing relation between your total costs per 1Mbps. Not only should this discussion be useful on list, but it might provide more content for the relay operator guide. g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
Before I started running a relay, one thing I wish I had known was that a relay has to be running for about three months and also continuously be offering 2mb/s network traffic to be used as a Guard relay. This is difficult If running a relay in the United States, as most ISPS in the US (or at least the major ones such as Charter, Comcast, AT&T, etc.) are cable ISPS, making even getting, let alone maintaining this speed to a relay very difficult (or impossible). As a result my relay is only ever used as a middle node. ➢ For others, there might be a learning curve in keeping a network service up with decent uptime, while updating the relevant ports and operating system. Yes, this is the most annoying thing for me. I had a glitch last night where my relay became unreachable for several hours because my router decided to change what device the port forwarding was for for some reason (I had not logged I the router and done this). It is also a pain at times keeping the OS, especially on macOS, the newer versions of which my not support older machines, up to date while trying to keep the relay stable, as relay status is changed so quickly (removing relays from the conseoucsus list within 40 mins) which can be troublesome for areas that sometimes experience power outages, which happens during winter where my relay is run. What seems strange to me is that I see there is a “running” flag. This flag seems pointless to me if the relay is just completely removed from the conseoucsus if it’s detected as not currently running to begin with; why not just give an “X” flag if the relay is unreachable for three days or so? Let me know what you all think. From: George Sent: Wednesday, June 27, 2018 1:39 PM To: tor-relays@lists.torproject.org Subject: [tor-relays] A general question for relay operators Greetings relay operators. A question that came up offline for relay operators can be summed up in one sentence, paraphrased from flexlibris: as a relay operator, what "things" do you wish you knew before you started running a relay? I'm really curious, in particular, to hear from those relay operators who are less connected to others, and are maybe more isolated physically from the community. In the long-ago past, many of us ran exit nodes without giving it much thought or preparation leading to ISP issues, but that seems less common today. For others, there might be a learning curve in keeping a network service up with decent uptime, while updating the relevant ports and operating system. There's no irrelevant answers to this, including more boring issues such as paying for the relay, choosing a provider or experiences as a (conscious) exit node operator. Bonus point for showing relation between your total costs per 1Mbps. Not only should this discussion be useful on list, but it might provide more content for the relay operator guide. g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
On 28 Jun 2018, at 11:45, Keifer Bly <keifer.bly@gmail.com> wrote:
It is also a pain at times keeping the OS, especially on macOS, the newer versions of which my not support older machines, up to date while trying to keep the relay stable, as relay status is changed so quickly (removing relays from the conseoucsus list within 40 mins) which can be troublesome for areas that sometimes experience power outages, which happens during winter where my relay is run.
But a 60 minute turnaround for relay reachability is *good* for clients. I think that is a part of the relay guide that we can improve: Relays exist so that clients can use the network. Consensus flags exist so that clients can use the network efficiently. Bandwidth weights are assigned so that clients can use the network efficiently.
What seems strange to me is that I see there is a “running” flag. This flag seems pointless to me if the relay is just completely removed from the conseoucsus if it’s detected as not currently running to begin with;
You're right, the Running flag is historical, and kept for backwards compatibility. (We used to list relays that were not Running, but removed them from the consensus to save client bandwidth.)
why not just give an “X” flag if the relay is unreachable for three days or so?
Remember: consensus flags exist so that clients can use the network efficiently. How would clients use a NotRunningForThreeDays flag? T
I am not saying that relays that are currently not running should be treated like they are currently running. I am just saying the network conseoucsus could be improved a little in the sense that relays, even very high bandwidth ones, might go offline from time to time due to things like power and internet outages which are things that happen from time to time, whereas with how things are now, relays that are offline for a few hours due to a possible power or internet outage in the area (or similar situation) are immediately (within the hour) treated like they never existed at all by the consensus. I just think that it would be friendly to relay operators if their was an option to have relays labeled as “this relay is down momentarily, but should be back up again in the near future” unless it is down for two days or so (etc. a long time with no update from the operator). From: teor Sent: Wednesday, June 27, 2018 7:39 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] A general question for relay operators
On 28 Jun 2018, at 11:45, Keifer Bly <keifer.bly@gmail.com> wrote:
It is also a pain at times keeping the OS, especially on macOS, the newer versions of which my not support older machines, up to date while trying to keep the relay stable, as relay status is changed so quickly (removing relays from the conseoucsus list within 40 mins) which can be troublesome for areas that sometimes experience power outages, which happens during winter where my relay is run.
But a 60 minute turnaround for relay reachability is *good* for clients. I think that is a part of the relay guide that we can improve: Relays exist so that clients can use the network. Consensus flags exist so that clients can use the network efficiently. Bandwidth weights are assigned so that clients can use the network efficiently.
What seems strange to me is that I see there is a “running” flag. This flag seems pointless to me if the relay is just completely removed from the conseoucsus if it’s detected as not currently running to begin with;
You're right, the Running flag is historical, and kept for backwards compatibility. (We used to list relays that were not Running, but removed them from the consensus to save client bandwidth.)
why not just give an “X” flag if the relay is unreachable for three days or so?
Remember: consensus flags exist so that clients can use the network efficiently. How would clients use a NotRunningForThreeDays flag? T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 28 Jun 2018, at 13:25, Keifer Bly <keifer.bly@gmail.com> wrote:
I am not saying that relays that are currently not running should be treated like they are currently running. I am just saying the network conseoucsus could be improved a little in the sense that relays, even very high bandwidth ones, might go offline from time to time due to things like power and internet outages which are things that happen from time to time,
Here's what you can do to fix your issues with relay downtime: * run a relay on your current unreliable connection, and stop worrying about downtime, * run a relay out of a data centre, and let someone else worry about your downtime. I'm sorry, but if you don't want to follow this advice, I don't think we can do anything else to help with your downtime.
whereas with how things are now, relays that are offline for a few hours due to a possible power or internet outage in the area (or similar situation) are immediately (within the hour) treated like they never existed at all by the consensus.
That's not true. Directory authorities keep an uptime history for down relays. But the consensus is for clients! If a relay is down, clients can't use it. Why tell clients about a relay they can't use? If you want us to change the consensus behaviour, you have to tell us how the change helps clients. Adding down relays to the consensus makes clients slower and wastes bandwidth.
I just think that it would be friendly to relay operators
But... the consensus is for Tor clients, not relay operators.
if their was an option to have relays labeled as “this relay is down momentarily, but should be back up again in the near future”
When the relay comes back up, Directory authorities assign flags based on its uptime history. Short downtimes mean fewer flags are lost.
unless it is down for two days or so (etc. a long time with no update from the operator).
Relay Search is for relay operators, and it tells operators how long their relay has been down. ("Uptime" gets replaced with "Downtime".) After a relay has been down for a while (a week?), it disappears from Relay Search. If you want new features for relay operators, they belong in relay search. T -- teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
Oh, my mistake. I thought torstatus.blutimage.de was also for operators as well as clients. I was aware that tor metrics stated relays current up/down time of a relay but did not know they keep it for that long, my apologies. I am a dork sometimes. ➢ run a relay out of a data center, and let someone else worry about your downtime. That’s not an option for me. There are no data centers here and I do not own one. Also, Charter Communications is the only ISP that does service where I live, there are no other options for internet besides Charter unfortunately so I’m pretty much stuck. From: teor Sent: Wednesday, June 27, 2018 9:40 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] A general question for relay operators Hi,
On 28 Jun 2018, at 13:25, Keifer Bly <keifer.bly@gmail.com> wrote:
I am not saying that relays that are currently not running should be treated like they are currently running. I am just saying the network conseoucsus could be improved a little in the sense that relays, even very high bandwidth ones, might go offline from time to time due to things like power and internet outages which are things that happen from time to time,
Here's what you can do to fix your issues with relay downtime: * run a relay on your current unreliable connection, and stop worrying about downtime, * run a relay out of a data centre, and let someone else worry about your downtime. I'm sorry, but if you don't want to follow this advice, I don't think we can do anything else to help with your downtime.
whereas with how things are now, relays that are offline for a few hours due to a possible power or internet outage in the area (or similar situation) are immediately (within the hour) treated like they never existed at all by the consensus.
That's not true. Directory authorities keep an uptime history for down relays. But the consensus is for clients! If a relay is down, clients can't use it. Why tell clients about a relay they can't use? If you want us to change the consensus behaviour, you have to tell us how the change helps clients. Adding down relays to the consensus makes clients slower and wastes bandwidth.
I just think that it would be friendly to relay operators
But... the consensus is for Tor clients, not relay operators.
if their was an option to have relays labeled as “this relay is down momentarily, but should be back up again in the near future”
When the relay comes back up, Directory authorities assign flags based on its uptime history. Short downtimes mean fewer flags are lost.
unless it is down for two days or so (etc. a long time with no update from the operator).
Relay Search is for relay operators, and it tells operators how long their relay has been down. ("Uptime" gets replaced with "Downtime".) After a relay has been down for a while (a week?), it disappears from Relay Search. If you want new features for relay operators, they belong in relay search. T -- teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
On 28 Jun 2018, at 15:14, Keifer Bly <keifer.bly@gmail.com> wrote:
Oh, my mistake. I thought torstatus.blutimage.de was also for operators as well as clients.
https://torstatus.blutmagie.de/ is for operators. But the data on the site is created for Tor clients.
I was aware that tor metrics stated relays current up/down time of a relay but did not know they keep it for that long, my apologies.
torstatus and relay search have different features. If you're looking for a missing feature, you should try the other one: https://metrics.torproject.org/rs.html
You can rent a relay anywhere in the world. (I rent a few machines in other countries, because internet in my country is slow.) But you'll need to learn ssh and remote administration. It's like using Terminal, but you're talking to a machine on the other side of the world. T -- teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
You can rent a relay anywhere in the world. (I rent a few machines in other countries, because internet in my country is slow.)
pfft - Does they live in AU - LOL - If they do then its expensive as well... But teor is right plenty of systems out there in the world - some really cheap. P 609662E824251C283164243846C035C803940378
I wish I'd known that this is not the place to learn Linux or really how to run a node securely and efficiently. Perhaps an acknowledgement of that might bring some other pages or styles of the current pages. I'd like to see a collection of correct answers perhaps searchable but restricted and monitored. There are some brilliant people who help but there are others who say less useful things and there's nothing stopping them. Has anyone wondered why the number of nodes is so incredibly low? Rob
➢ Has anyone wondered why the number of nodes is so incredibly low? If by that you mean why there are fewer relays than there are tor users (clients), I’d say there are several reasons for this. Not everybody can run a relay, it requires having a router that can smoothly handle the load (or data center), an ISP that allows relays to be run, and not every person who uses tor has that. Far from everybody who installs the tor browser on their computer configures a relay for those reasons and because they don’t want to donate their internet speed. It’s a shame as the network would be faster and stronger otherwise, but that is the case. ➢ I’d like to see a collection of correct answers perhaps searchable Try tor stack exchange (https://tor.stackexchange.com/) There are loads other questions about operating the tor software with answers, and you can ask a question yourself. Cheers. From: I Sent: Wednesday, June 27, 2018 10:10 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] A general question for relay operators I wish I'd known that this is not the place to learn Linux or really how to run a node securely and efficiently. Perhaps an acknowledgement of that might bring some other pages or styles of the current pages. I'd like to see a collection of correct answers perhaps searchable but restricted and monitored. There are some brilliant people who help but there are others who say less useful things and there's nothing stopping them. Has anyone wondered why the number of nodes is so incredibly low? Rob _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi there,
what "things" do you wish you knew before you started running a relay?
I wish I knew what the tor community and the tor network expects from us. For example, is it expected from us to keep the relay with 100% uptime? or would it be still fine to -say- have 70% uptime? or if it is not > 90% uptime, is it worthless to run it anyway? Or, more general, how much time and effort does it take to set it up and how much time and effort does it take to keep it running? What minimum knowledge do we need? What is the minimum requirement the relay must have to be it worth for the network? Also, I wish I knew what are the possible problems we may have to face and what to do with them (example, run out of bandwidth quota, cpu usage, possible intrusion and attack vectors to the server running the relay and how to prevent and mitigate them, ...) Sometimes I find those answers on tor's page/wiki or ask them on #tor-relay. Perhaps I didn't do enough research before setting up the relay....
Hi! I've been running a couple of relays for 3-4 years now. They are on lightly-loaded 100MB/s fiber links. They have seven flags, lots of uptime, etc. They advertise 20Mb/s, but Nyx reports: "measured: 22.1 Kb/s" for D76E1FDC7A3D899282BB882F74111B36A6D14B64 and "measured: 28.6 Kb/s" for 56DCA89A6B41ADA30E891EF65FDCC071DC05079B The graphs Nyx displays usually show around 10Mbps (but are quite variable). The graphs on metrics.torproject.org show the bandwidth hovering around 800 K bytes/second. So why is the "measured" bandwidth from Nyx so low? --Ron
Hi Ron, are you sure you're using Nyx rather than the old arm codebase? I could be mistaken but my recollection (and quick read of the code) I think the graph title bar should only have 'limit', 'burst', and 'observed'. Iirc the 'measured' was removed. On Wed, Jul 4, 2018 at 1:05 PM, <ronqtorrelays@risley.net> wrote:
Hej Damian, Even as root Nyx asks for a 'Tor controller password'. What would that be? Robert
Thanks, but Nyx reports:
[sum:1912][~]$ nyx --version nyx version 2.0.4 (released November 5, 2017)
which, according to nyx.torproject.org, is the latest version. I sent a screenshot, but it was too big to make it to the list without moderation. --Ron
participants (9)
-
Damian Johnson -
George -
I -
Keifer Bly -
Nicolás Dato -
nusenu -
Paul Templeton -
ronqtorrelays＠risley.net -
teor