Hello relay operators,
Thanks for running relays, and thanks to those of you who are moving off of our old EOL Tor versions. Thanks especially to those of you who moved directly to Tor 0.4.1!
We would like to transition the LTS Tor to be for use in edge/client/non-relay infrastructure only. We would like to minimize even that use.
We need to update our network protocols to improve performance, security, and to add defenses against DoS attacks. Doing this while supporting LTS for relays is expensive, especially when large backports must be done to keep the network safe. It also slows down the uniform deployment of performance improvements, which contributes to the frustrating user experience of abysmal-but-rare performance edge cases.
Unfortunately, we still have something like 2500 relays on either Tor 0.2.9-LTS or Tor 0.3.5-LTS.
What are the reasons for this? My guess is the top 5 most common responses are:
1. "I didn't know that Debian's backports repo has latest-stable Tor!" 2. "I didn't see the Tor Project repos mentioned in Tor's Relay docs!" 3. "I'm running a distribution that Tor Project doesn't have repos for." 4. "I rolled my own custom Tor from git and forgot about it." 5. "My relay machine was not getting any updates at all. Oops."
Does anyone have a reason that they think many other relay operators also share?
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
Hi Mike,
Here's some other reasons that might affect a few operators:
On 5 Sep 2019, at 12:11, Mike Perry mikeperry@torproject.org wrote:
Unfortunately, we still have something like 2500 relays on either Tor 0.2.9-LTS or Tor 0.3.5-LTS.
What are the reasons for this? My guess is the top 5 most common responses are:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
- "I'm running a distribution that Tor Project doesn't have repos for."
- "I rolled my own custom Tor from git and forgot about it."
- "My relay machine was not getting any updates at all. Oops."
Does anyone have a reason that they think many other relay operators also share?
6. When I tried to update, it didn't work with my old config 7. I need features that only exist in older Tors - I can think of Tor2web, there may be others 8. I am maintaining research or other patches against tor, and rebases are difficult
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
The answers are probably something like: 6. Provide better relay operator support, and direct me to those support channels in the log messages, when my relay fails to launch 7. Support old features for longer 8. Stop refactoring so much code
T
teor:
On 5 Sep 2019, at 12:11, Mike Perry mikeperry@torproject.org wrote:
Unfortunately, we still have something like 2500 relays on either Tor 0.2.9-LTS or Tor 0.3.5-LTS.
What are the reasons for this? My guess is the top 5 most common responses are:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
- "I'm running a distribution that Tor Project doesn't have repos for."
- "I rolled my own custom Tor from git and forgot about it."
- "My relay machine was not getting any updates at all. Oops."
Does anyone have a reason that they think many other relay operators also share?
- When I tried to update, it didn't work with my old config> 7. I need features that only exist in older Tors
- I can think of Tor2web, there may be others
Are these common? I feel like this is long-tail. I'm looking for most common reasons first. After we address the most common reasons, we can pick our favorite long-tail use cases and decide if those are worth forward-porting or back-porting individual features for. But not before the common cases are dealt with. That way lies madness, and no progress, ever.
- I am maintaining research or other patches against tor, and rebases are difficult
Again, common? I'm going to guess not common (or self-supporting), but this does feel like something we could measure by checking for git versions that don't make sense to us in the full descriptor archives.
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
The answers are probably something like: 6. Provide better relay operator support, and direct me to those support channels in the log messages, when my relay fails to launch
+1 100%. I think this will go light years towards getting rid of non-LTS Tors and LTS tor's alike, regardless of reason. Then we can ask the remainder.
- Support old features for longer> 8. Stop refactoring so much code
Nah. I'm not interested in these, even if populism demands them. Some shit needs to go away because it is not safe to keep around, and some stuff needs to be better organized to make it easier to improve.
Hi,
On 5 Sep 2019, at 13:01, Mike Perry mikeperry@torproject.org wrote:
- I am maintaining research or other patches against tor, and rebases
are difficult
Again, common? I'm going to guess not common (or self-supporting), but this does feel like something we could measure by checking for git versions that don't make sense to us in the full descriptor archives.
That could be hard: some distros add their own patches using git.
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
The answers are probably something like: 6. Provide better relay operator support, and direct me to those support channels in the log messages, when my relay fails to launch
Show Quoted Content
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
The answers are probably something like: 6. Provide better relay operator support, and direct me to those support channels in the log messages, when my relay fails to launch
+1 100%. I think this will go light years towards getting rid of non-LTS Tors and LTS tor's alike, regardless of reason. Then we can ask the remainder.
- Support old features for longer> 8. Stop refactoring so much code
Nah. I'm not interested in these, even if populism demands them. Some shit needs to go away because it is not safe to keep around, and some stuff needs to be better organized to make it easier to improve.
I agree. But you asked for answers, so I gave them.
T
On 9/4/19 22:43, teor wrote:
Hi Mike,
Here's some other reasons that might affect a few operators:
On 5 Sep 2019, at 12:11, Mike Perry mikeperry@torproject.org wrote:
Unfortunately, we still have something like 2500 relays on either Tor 0.2.9-LTS or Tor 0.3.5-LTS.
What are the reasons for this? My guess is the top 5 most common responses are:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
- "I'm running a distribution that Tor Project doesn't have repos for."
- "I rolled my own custom Tor from git and forgot about it."
- "My relay machine was not getting any updates at all. Oops."
Does anyone have a reason that they think many other relay operators also share?
- When I tried to update, it didn't work with my old config
- I need features that only exist in older Tors
- I can think of Tor2web, there may be others
- I am maintaining research or other patches against tor, and rebases are difficult
Regarding my relays, which currently are [0]
- Two were stuck on 0.3.4.11 because I had to install Tor from source on that machine and am bad about updating it (just updated) - Two are stuck on 0.3.5.7 because research and rebasing to new versions is liable to create inconsistencies and general doubt about results
[0]: https://metrics.torproject.org/rs.html#search/contact:pastly
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
This is a huge ask and I don't expect anything to come of this suggestion, but:
Auto updates from within Tor itself (not relying on distro package managers). Put it behind a torrc option, allow the authorities to tell relays with the option enabled to download a new tor binary from $PLACE, create a bunch of infrastructure that builds Tor for all supported platforms reliably and efficiently, use a bunch of signatures everywhere so nothing bad can happen, done. So easy a caveman could do it, nothing bad could ever happen, absolutely no downsides, it's $CURRENT_YEAR so why don't we have this, etc. etc.
On Sep 5, 2019, at 11:44 AM, Matt Traudt pastly@torproject.org wrote:
On 9/4/19 22:43, teor wrote:
Hi Mike,
Here's some other reasons that might affect a few operators:
On 5 Sep 2019, at 12:11, Mike Perry mikeperry@torproject.org wrote:
Unfortunately, we still have something like 2500 relays on either Tor 0.2.9-LTS or Tor 0.3.5-LTS.
What are the reasons for this? My guess is the top 5 most common responses are:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
- "I'm running a distribution that Tor Project doesn't have repos for."
- "I rolled my own custom Tor from git and forgot about it."
- "My relay machine was not getting any updates at all. Oops."
Does anyone have a reason that they think many other relay operators also share?
- When I tried to update, it didn't work with my old config
- I need features that only exist in older Tors
- I can think of Tor2web, there may be others
- I am maintaining research or other patches against tor, and rebases
are difficult
Regarding my relays, which currently are [0]
- Two were stuck on 0.3.4.11 because I had to install Tor from source on
that machine and am bad about updating it (just updated)
- Two are stuck on 0.3.5.7 because research and rebasing to new versions
is liable to create inconsistencies and general doubt about results
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
This is a huge ask and I don't expect anything to come of this suggestion, but:
Auto updates from within Tor itself (not relying on distro package managers). Put it behind a torrc option, allow the authorities to tell relays with the option enabled to download a new tor binary from $PLACE, create a bunch of infrastructure that builds Tor for all supported platforms reliably and efficiently, use a bunch of signatures everywhere so nothing bad can happen, done. So easy a caveman could do it, nothing bad could ever happen, absolutely no downsides, it's $CURRENT_YEAR so why don't we have this, etc. etc.
-- Matt
This may not matter for LTS versions, but I just wanted to mention it it in reference it to the possible idea that Tor possibly updating itself. I’ve never relied on the OS Package of Tor, mainly because OS’s OpenSSL versions are behind the current version of OpenSSL, so I normally compile Tor against the latest OpenSSL. Example, FreeBSD 12.0-RELEASE has OpenSSL 1.1.1a-freebsd, which generates a slight crypto error during the startup of Tor. If you download OpenSSL 1.1.1c and just compile against it, eh, problem fixed. Sorry, maybe I just don’t like seeing errors :).
Anyway, why don’r we try to simplify the update process even further and just ship Tor with some ansible scripts that will replace the binary, check the config file and comment out any settings that will break the new version, then restart? It’s pretty simple to write an sensible script to do this function.
--- Conrad Rockenhaus conrad@rockenhaus.com https://www.rockenhaus.com/ (254) 292-3350
never relied on the OS Package of Tor, mainly because OS’s OpenSSL versions are behind the current version of OpenSSL, so I normally compile Tor against the latest OpenSSL. Example, FreeBSD 12.0-RELEASE has OpenSSL 1.1.1a-freebsd, which generates a slight crypto error during the startup of Tor. If you download OpenSSL 1.1.1c and just compile against it, eh, problem fixed.
As to realtime, hardly any behind... ver openssl 12-stable ports-head 1.1.1c 20190528 20190528 20190528 1.1.1b 20190226 20190226 20180227 1.1.1a 20181120 20181120 20181120 ... not including any 'responsible disclosure' bs around any HW / SW that users may or may not be affected by.
As to release mechanics... 12.0-release base had latest 1.1.1a at release, release ports tags were one letter rev behind at 1.0.2p and 1.1.0i, release ports head was latest at 1.0.2q and 1.1.1a, quarterly was similar.
tor follows same pattern, people can research and post those datas if they want.
Of course people's boxes will be behind if they never update them beyond release, that's not fault of any OS.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgradin... https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html https://download.freebsd.org/ftp/snapshots/
Either update base per binary, snapshot, releng, or stable... or track and install ports (packages) quarterly, latest / head... and compile against that as needed.
Or get the upstream sources and do by hand.
If people aren't on FreeBSD or a well supported Linux distro they should expect their OS to be laggy in areas.
Many FreeBSD tor users would be fine tracking base stable and packages latest (ports head). pkg.conf: url: "pkg+https://pkg.FreeBSD.org/$%7BABI%7D/latest",
If their OS of choice is still a bit laggy for them, they can join their OS community and start generating update commits... :)
https://freebsd.org/ https://openbsd.org/ etc or whatever pump and dump linux distro is hot this year.
On Sep 5, 2019, at 10:21 PM, grarpamp grarpamp@gmail.com wrote:
never relied on the OS Package of Tor, mainly because OS’s OpenSSL versions are behind the current version of OpenSSL, so I normally compile Tor against the latest OpenSSL. Example, FreeBSD 12.0-RELEASE has OpenSSL 1.1.1a-freebsd, which generates a slight crypto error during the startup of Tor. If you download OpenSSL 1.1.1c and just compile against it, eh, problem fixed.
As to realtime, hardly any behind... ver openssl 12-stable ports-head 1.1.1c 20190528 20190528 20190528 1.1.1b 20190226 20190226 20180227 1.1.1a 20181120 20181120 20181120 ... not including any 'responsible disclosure' bs around any HW / SW that users may or may not be affected by.
As to release mechanics... 12.0-release base had latest 1.1.1a at release, release ports tags were one letter rev behind at 1.0.2p and 1.1.0i, release ports head was latest at 1.0.2q and 1.1.1a, quarterly was similar.
tor follows same pattern, people can research and post those datas if they want.
Of course people's boxes will be behind if they never update them beyond release, that's not fault of any OS.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgradin... https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html https://download.freebsd.org/ftp/snapshots/
Either update base per binary, snapshot, releng, or stable... or track and install ports (packages) quarterly, latest / head... and compile against that as needed.
Or get the upstream sources and do by hand.
If people aren't on FreeBSD or a well supported Linux distro they should expect their OS to be laggy in areas.
Many FreeBSD tor users would be fine tracking base stable and packages latest (ports head). pkg.conf: url: "pkg+https://pkg.FreeBSD.org/$%7BABI%7D/latest",
If their OS of choice is still a bit laggy for them, they can join their OS community and start generating update commits... :)
https://freebsd.org/ https://openbsd.org/ etc or whatever pump and dump linux distro is hot this year.
Grampamp,
You know I love you tons - but the problem with the FreeBSD release of Tor isn’t fixed by switching to “latest”, you’ll still get the error upon startup. It’s compiled against an older version of OpenSSL. Since it already has an active maintainer I can’t just go in and take it over. That would be rude.
Yes, OpenSSL on mainline 12.0-RELEASE is fixed, but what they compiled the package against isn’t, so it’s either compile the port or don’t use pkgs. I for one believe in the philosophy of not mixing pkgs and ports so…. Ports it is.
Thanks,
Conrad
Conrad Rockenhaus:
On Sep 5, 2019, at 10:21 PM, grarpamp grarpamp@gmail.com wrote:
never relied on the OS Package of Tor, mainly because OS’s OpenSSL versions are behind the current version of OpenSSL, so I normally compile Tor against the latest OpenSSL. Example, FreeBSD 12.0-RELEASE has OpenSSL 1.1.1a-freebsd, which generates a slight crypto error during the startup of Tor. If you download OpenSSL 1.1.1c and just compile against it, eh, problem fixed.
As to realtime, hardly any behind... ver openssl 12-stable ports-head 1.1.1c 20190528 20190528 20190528 1.1.1b 20190226 20190226 20180227 1.1.1a 20181120 20181120 20181120 ... not including any 'responsible disclosure' bs around any HW / SW that users may or may not be affected by.
As to release mechanics... 12.0-release base had latest 1.1.1a at release, release ports tags were one letter rev behind at 1.0.2p and 1.1.0i, release ports head was latest at 1.0.2q and 1.1.1a, quarterly was similar.
tor follows same pattern, people can research and post those datas if they want.
Of course people's boxes will be behind if they never update them beyond release, that's not fault of any OS.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgradin... https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html https://download.freebsd.org/ftp/snapshots/
Either update base per binary, snapshot, releng, or stable... or track and install ports (packages) quarterly, latest / head... and compile against that as needed.
Or get the upstream sources and do by hand.
If people aren't on FreeBSD or a well supported Linux distro they should expect their OS to be laggy in areas.
Many FreeBSD tor users would be fine tracking base stable and packages latest (ports head). pkg.conf: url: "pkg+https://pkg.FreeBSD.org/$%7BABI%7D/latest",
If their OS of choice is still a bit laggy for them, they can join their OS community and start generating update commits... :)
https://freebsd.org/ https://openbsd.org/ etc or whatever pump and dump linux distro is hot this year.
Grampamp,
You know I love you tons - but the problem with the FreeBSD release of Tor isn’t fixed by switching to “latest”, you’ll still get the error upon startup. It’s compiled against an older version of OpenSSL. Since it already has an active maintainer I can’t just go in and take it over. That would be rude.
Yes, OpenSSL on mainline 12.0-RELEASE is fixed, but what they compiled the package against isn’t, so it’s either compile the port or don’t use pkgs. I for one believe in the philosophy of not mixing pkgs and ports so…. Ports it is.
Way late to the party on this, and I don't know if it's resolved on the FreeBSD side yet, but you need to try https://bugs.freebsd.org/bugzilla/ for issues like this, especially if it's a sync issue between base and the package.
I did not have any issues with FreeBSD 12-RELEASE with pkgs set to "latest" with net/tor.
IMHO, issues like this are inevitable when you have THREE supported "production" releases...
Oh, how I miss the FreeBSD 4.x era.
g
On Thu, 05 Sep 2019 02:11:00 +0000 Mike Perry mikeperry@torproject.org wrote:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
I only looked to backports when I get a warning on the metrics website that my versions are not recommended. Aside from that, I thought that running LTS on relays is actually beneficial, to prevent any newly introduced bugs in the current latest versions from having an impact on the network infrastructure.
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
I was using them in the past, but then decided not to, as it's adding some management overhead and also one more potential security weakpoint.
Roman Mamedov:
On Thu, 05 Sep 2019 02:11:00 +0000 Mike Perry mikeperry@torproject.org wrote:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
I only looked to backports when I get a warning on the metrics website that my versions are not recommended. Aside from that, I thought that running LTS on relays is actually beneficial, to prevent any newly introduced bugs in the current latest versions from having an impact on the network infrastructure.
We are moving towards relying on CI for finding functional bugs, and code review and static analysis for security issues.
I don't believe that current LTS periods of time will necessarily provide better results for either of these classes of risk than investing in better CI and in other forms of diversity than just release version.
However, I could see a middle ground where we shorten LTS timescales for the relay side, but don't eliminate them, as we work towards where we want to be with CI and security issue risk reduction (or other forms of diversity).
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
I was using them in the past, but then decided not to, as it's adding some management overhead and also one more potential security weakpoint.
These two strike me as being likely to be very high on the list of common reasons, when the choice is deliberately made.
What can we do to reduce management overhead?
Right now, there are quite a lot of separate pages pointing to different pieces of the steps of adding our repo. Is that the problematic piece? Are there additional things make it more of a hassle than it should be?
Someone else mentioned ansible. Would an ansible playbook that add our repositories and their gpg keys make this easier? Or is it better just to keep the steps all on a single page?
Where does the security weakpoint risk come from? Does apt-transport-tor/onion service repository availability help in your mind here?
Hi all,
On 6 Sep 2019, at 12:20, Mike Perry mikeperry@torproject.org wrote:
Roman Mamedov:
On Thu, 05 Sep 2019 02:11:00 +0000 Mike Perry mikeperry@torproject.org wrote:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
I only looked to backports when I get a warning on the metrics website that my versions are not recommended. Aside from that, I thought that running LTS on relays is actually beneficial, to prevent any newly introduced bugs in the current latest versions from having an impact on the network infrastructure.
We are moving towards relying on CI for finding functional bugs, and code review and static analysis for security issues.
I don't believe that current LTS periods of time will necessarily provide better results for either of these classes of risk than investing in better CI and in other forms of diversity than just release version.
However, I could see a middle ground where we shorten LTS timescales for the relay side, but don't eliminate them, as we work towards where we want to be with CI and security issue risk reduction (or other forms of diversity).
We also have long-term support so that popular software distributions can have a supported version of Tor. (Debian, Ubuntu, and ideally some non-Linux distributions, if they become popular in future.)
So it's not just risk that determines our current LTS timeframes.
T
On Fri, 06 Sep 2019 02:20:00 +0000 Mike Perry mikeperry@torproject.org wrote:
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
I was using them in the past, but then decided not to, as it's adding some management overhead and also one more potential security weakpoint.
These two strike me as being likely to be very high on the list of common reasons, when the choice is deliberately made.
What can we do to reduce management overhead?
Nothing, perhaps. It's just a matter of dealing with an external repo itself: adding it, ensuring it is added on all new machines, ensuring the distro specifier is update on distro upgrades, and likely working on integrating all of that that into a centralized deployment system (not ansible): e.g. do I add that into sources.list directly, or put a file into sources.list.d, if a file, then will it be a file directly, or symlinked from the location into which all other configs are rsync'ed to the machine, etc.
Considering the previously perceived low benefit of running the very latest version in the first place, or the benefit of running that over backports (the Tor repo might have only a marginally newer version than backports), it should be easy to see why the desire to skip all of the above.
(For backports it is the same "overhead", but I am likely adding backports anyway, due to wanting something else from it, not just Tor).
Someone else mentioned ansible. Would an ansible playbook that add our repositories and their gpg keys make this easier? Or is it better just to keep the steps all on a single page?
Personally I do not use ansible and would not prefer that to be made the only way to do something.
Where does the security weakpoint risk come from? Does apt-transport-tor/onion service repository availability help in your mind here?
As with adding any third-party repository, it means trusting the repository provider to install and run any root-privilege code on the machine. In case the repository server (or actually the release process, including signing) is compromised, on the next update it can serve malicious or backdoored versions of the software. So naturally from the security standpoint it is beneficial to add (and trust) as few repositories as possible, just to reduce the "attack surface".
Hi,
On 6 Sep 2019, at 20:14, Roman Mamedov rm@romanrm.net wrote:
Where does the security weakpoint risk come from? Does apt-transport-tor/onion service repository availability help in your mind here?
As with adding any third-party repository, it means trusting the repository provider to install and run any root-privilege code on the machine. In case the repository server (or actually the release process, including signing) is compromised, on the next update it can serve malicious or backdoored versions of the software. So naturally from the security standpoint it is beneficial to add (and trust) as few repositories as possible, just to reduce the "attack surface".
So one thing Tor could do here is run easily and securely without root?
T
On 7. Sep 2019, at 12:20, teor teor@riseup.net wrote:
Hi,
On 6 Sep 2019, at 20:14, Roman Mamedov rm@romanrm.net wrote:
Where does the security weakpoint risk come from? Does apt-transport-tor/onion service repository availability help in your mind here?
As with adding any third-party repository, it means trusting the repository provider to install and run any root-privilege code on the machine. In case the repository server (or actually the release process, including signing) is compromised, on the next update it can serve malicious or backdoored versions of the software. So naturally from the security standpoint it is beneficial to add (and trust) as few repositories as possible, just to reduce the "attack surface".
So one thing Tor could do here is run easily and securely without root?
T
Not really I think. I kind of subscribe to the same argument (I think it is the same argument at least) for almost all software I install: - I want fast and low-risk updates in the case of a security update, so please give me a patch that fixes only the security issue - I want a low-hassle installation, so frequently updating (more frequently than every other year or so) is really annoying. Especially if there could be changes in the configuration that I have to adapt, and even more so if I cannot have confidence that all configuration changes I might need to make are given during the update. - I never want a software to update without my knowledge, so absolutely no phoning home for updates/automatically updating. Even without root. Being able to execute a binary on a system is not very far from being root on that system these days.
I think I apply this to every software with the exception of Tor, and for Tor I only do it because of my project involvement and the big trust I put into the maintainers of our repository. For other stuff, I just stop running it if it doesn't work out of the box provided by my distribution.
Cheers Sebastian
On Sat, 7 Sep 2019 20:20:06 +1000 teor teor@riseup.net wrote:
As with adding any third-party repository, it means trusting the repository provider to install and run any root-privilege code on the machine. In case the repository server (or actually the release process, including signing) is compromised, on the next update it can serve malicious or backdoored versions of the software. So naturally from the security standpoint it is beneficial to add (and trust) as few repositories as possible, just to reduce the "attack surface".
So one thing Tor could do here is run easily and securely without root?
This will not address the concern, because AFAIK in Debian the package management scripts (contained inside the .deb's DEBIAN dir: preinst, postinst, prerm and postrm) always run with root privileges on package addition or removal.
Hi
Am Do., 5. Sept. 2019 um 04:12 Uhr schrieb Mike Perry < mikeperry@torproject.org>:
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
When i started my first relay i had zero knowledge about Linux so i can describe my whole experience from a noob position.
I wanted to start to learn about something new and someone told me a Raspberry Pi is good to start with Linux. Then i had that Pi with Raspbian and didnt knew what to do with it now. I found an instruction on google how to install a Tor relay to contribute to Tor. It took me more than two weeks with many angry moments followed by many facepalms but finally my first relay was working. Now about one year later i operate 25 relays and i love it. I constantly learn something new and i read everything i can about Tor because its fascinating and awesome.
It took me months to realize that there is an instruction on your website how to install a relay. At the beginning i always used some guides which i found on google because they appear before the instruction site of the Torproject appears.
If you could point out that the instructions for installing a relay on Debian are the same like for Raspbian it had safed me many hours because i thought it will not work if i use the Debian instructions and i thought its more like a "tweak" to make a relay running on a Pi because on your website i can find several OSs but nothing about Raspbian.
After i finally understood how to install packages on my Raspberry Pi i was very happy that it worked and i was afraid to touch anything. It took me some more months to even realize that the package in the repositories is not the latest one. I thought its working like Windows Update where you will automatically get the latest stable one when you run apt-get upgrade. After that realization it took me some more months to understand what an additional repository is and how and why to add it.
I think there is not much you can do against that. Maybe just support the versions "as short as necessary" because if someone really wants to understand what is going on then he will take his time to make it working. I dont know how big that fraction is but maybe there are several people outside who just dont know that their relay is outdated.
I am subscribed on this mailing-list after i had half of my relays already running so maybe there are some people who just dont realize that their relays version is outdated because they still can see traffic on it. So i think kicking out relays with outdated versions "as fast as useful" is a good way to show the operator that he is not very helpful anymore. When they dont see any traffic anymore they either will try to find out why and upgrade or they will close the relay but i think if they decide to close the relay they are anyway not very reliable.
To sum it up: - Make it as easy as possible to find the setup instructions - Point out that Raspbian is supported too - Make it more obvious that an operator could be much more useful if he would take a few minutes to upgrade
I remembered that someone here asked a few months ago how to set up a relay on Windows. Out of boredom a few days ago i grabbed a one-month-description VPS with Windows Server 2012 R2 on it and tried to set up a relay there. I felt familiar immediatelly even if i had never worked with Windows Server before and the relay was running after 15 minutes. F9C203B9FB710FC9C7C45F2CCDF8B626F2320253
There were only three small points where i struggled a little bit because Tor crashed without telling me why but setting it up on Windows seems to be as easy as on Linux. If it helps i can describe the crashes i had or write a ticket about it.
An instruction about setting it up on Windows might be not worth the work but pointing out that if someone is more familiar with Windows that he should just try his luck because it will likely work could be helpful too.
Unfortunately, we still have something like 2500 relays on either Tor 0.2.9-LTS or Tor 0.3.5-LTS.
What are the reasons for this? My guess is the top 5 most common responses are:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
- "I'm running a distribution that Tor Project doesn't have repos for."
- "I rolled my own custom Tor from git and forgot about it."
- "My relay machine was not getting any updates at all. Oops."
Does anyone have a reason that they think many other relay operators also share?
How can we fix that for you, or at least, how can we make it easier to run the very latest stable series Tor on your relay?
- "I followed the official torproject documentation for Debian/Ubuntu which says 'apt install tor' in the first option" (before the relay guide has been introduced - which points to option two) https://2019.www.torproject.org/docs/debian.html.en
- "I run vanilla debian and don't want to trust any third party or backport repos if not necessary"
- "I want to run a relay with minimal effort and LTS releases happen less frequently -> less effort"
- "If I update my relay frequently my cw decreases"
- "Roger said tor 0.3.5 is especially stable, we like more stable software" (see the emails send out to operators on https://lists.torproject.org/pipermail/network-health/2019-September/thread.... )
tor-relays@lists.torproject.org
-
Conrad Rockenhaus -
George -
grarpamp -
Matt Traudt -
Michael Gerstacker -
Mike Perry -
nusenu -
Roman Mamedov -
Sebastian Hahn -
teor