One of my relays has over 416 days of uptime, which I'm very proud of, however it's running an outdated version of Tor. I should probably already know the answer, but it seems to me I would have to stop the tor service to update the relay. Would I in fact lose my uptime or would it be seamless? Thanks for the response
You'll lose your uptime, but... don't be ridiculous. It's better to keep Tor up-to-date. That uptime undoubtedly means you're running an outdated kernel too, which is not ideal. I think it would be wise to take the hit and update both.
And why not taking a screenshot + print it to remember :p
tor :
You'll lose your uptime, but... don't be ridiculous. It's better to keep Tor up-to-date. That uptime undoubtedly means you're running an outdated kernel too, which is not ideal. I think it would be wise to take the hit and update both.
Lol....I'll frame it and then upgrade both...thanks for the kick in the rear..
On Aug 16, 2017 2:34 PM, "Petrusko" petrusko@riseup.net wrote:
And why not taking a screenshot + print it to remember :p
tor :
You'll lose your uptime, but... don't be ridiculous. It's better to keep Tor up-to-date. That uptime undoubtedly means you're running an outdated kernel too, which is not ideal. I think it would be wise to take the hit and update both.
-- Petrusko C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Uptime used to be something to brag about. Now it just means you aren't regularly updating. This is true for any kind of server, not just a relay.
On Thu, Aug 17, 2017 at 12:17 AM, K. Besig suprleg@gmail.com wrote:
Lol....I'll frame it and then upgrade both...thanks for the kick in the rear..
On Aug 16, 2017 2:34 PM, "Petrusko" petrusko@riseup.net wrote:
And why not taking a screenshot + print it to remember :p
tor :
You'll lose your uptime, but... don't be ridiculous. It's better to keep Tor up-to-date. That uptime undoubtedly means you're running an outdated kernel too, which is not ideal. I think it would be wise to take the hit and update both.
-- Petrusko C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 08/17/2017 04:24 PM, Chuck McAndrew wrote:
Uptime used to be something to brag about. Now it just means you aren't regularly updating.
+1
I do usually follow the vanilla stable kernel - meaning my uptime isn't bigger than 2 weeks since that.
- -- Toralf PGP C4EACDDE 0076E94E
Wouldn‘t something like KernelCare help which patches the kernel without the need to reboot?
-------- Original Message -------- Subject: Re: [tor-relays] Relay uptime versus outdated Tor version Local Time: 17 August 2017 6:11 PM UTC Time: 17 August 2017 16:11 From: toralf.foerster@gmx.de To: tor-relays@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 08/17/2017 04:24 PM, Chuck McAndrew wrote:
Uptime used to be something to brag about. Now it just means you aren"t regularly updating.
+1
I do usually follow the vanilla stable kernel - meaning my uptime isn"t bigger than 2 weeks since that.
Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE-----
iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWZXAMxccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTkFdAP9F3POPsg83GS4edr5NLOV9kEcX EUP0rQJuR/I109SGlAD/eRucOWT/1+fuEOWtG/2Q3MBx9AFgbnL24HwKOSXiWg4= =83Z1 -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
In theory hot-patching kernels is a great idea.
However, they're technically not loading a new kernel. Something like kexec in theory lets one load a new kernel.
Furthermore, these hot-patching programs usually only support Linux. If we want to increase the diversity of the Tor network, as we most certainly should, then we need more BSD relays, so these hot-patching programs don't cut it.
It's also worth remembering that there are miscellaneous other services and system components that aren't necessarily reloaded by a new kernel. If the C standard library got an update, it's not possible to hot patch that.
Just restart it. It takes a few minutes, it's actually guaranteed to work unlike dubious hot-patching programs.
Keepyourprivacy:
Wouldn‘t something like KernelCare help which patches the kernel without the need to reboot?
Duncan dguthrie@posteo.net wrote:
In theory hot-patching kernels is a great idea.
However, they're technically not loading a new kernel. Something like kexec in theory lets one load a new kernel.
Furthermore, these hot-patching programs usually only support Linux. If we want to increase the diversity of the Tor network, as we most certainly should, then we need more BSD relays, so these hot-patching programs don't cut it.
The tor project has made the point that OS diversity is important, but it has failed to show the courage of its conviction. It commits great effort to maintain a "safe" tor browser for the OS for which tor relays currently abound, yet still offers no version of that browser to entice *BSD, Solaris, MINIX, or other OS users to run tor relays. Instead, such users are apparently expected either to use clearly unsafe browsers or to run VMs of other than their native OS to run a safe browser. The tor community is thus very lucky for what diversity of relay OS currently exists. I've pointed this problem out several times, but to the best of my memory, none of the tor developers has ever responded on this issue.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
Firstly, a note of caution: I am not affiliated with the Tor project.
Scott Bennett:
Duncan dguthrie@posteo.net wrote:
In theory hot-patching kernels is a great idea.
However, they're technically not loading a new kernel. Something like kexec in theory lets one load a new kernel.
Furthermore, these hot-patching programs usually only support Linux. If we want to increase the diversity of the Tor network, as we most certainly should, then we need more BSD relays, so these hot-patching programs don't cut it.
The tor project has made the point that OS diversity is important,but it has failed to show the courage of its conviction. It commits great effort to maintain a "safe" tor browser for the OS for which tor relays currently abound, yet still offers no version of that browser to entice *BSD, Solaris, MINIX, or other OS users to run tor relays. Instead, such users are apparently expected either to use clearly unsafe browsers or to run VMs of other than their native OS to run a safe browser. The tor community is thus very lucky for what diversity of relay OS currently exists.
If I may, the point of diversifying the network is *not* to "entice" BSD/Solaris/MINIX users, the number of which, even compared to Linux, which is quite low, is astonishingly small. I'd argue more effort should actually be put into hardening Tor Browser for Windows, as it is on Linux that much of the hardening efforts are currently being focused, unfortunately.
The point is that as it stands, serious bugs that affect Linux currently affect the entirety of the Tor network. As a mono-culture, this could cause problems in the future, especially as the network expands. This is an issue for client users too, certainly. However, it is not clear that there would be a benefit to providing builds to operating systems with a very low number of users. I'm sure there are people using BeOS or Plan 9 which want to use Tor Browser, after all. They can always compile it from source if they wish (whether it would run is another matter, but that is work that would take away from helping a greater number of users).
That being said, there is in fact the very good TorBSD project which provides Tor Browser builds for OpenBSD. I do not know what the situation with FreeBSD is, but that provides a Linux compatibility layer, which I've heard Tor Browser works with. Here it is: http://torbsd.github.io/
I've pointed this problem out several times, but to the best of mymemory, none of the tor developers has ever responded on this issue.
Scott Bennett, Comm. ASMELG, CFIAG
- Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
- "A well regulated and disciplined militia, is at all times a good *
- objection to the introduction of that bane of all free governments *
- -- a standing army." *
- -- Gov. John Hancock, New York Journal, 28 January 1790 *
Best, Duncan
Relay diversity and client diversity are two different things. Last I heard it was a bad idea to run a relay on the same computer as a client, so I don't think Tor Browser for server OSes like Solaris is a great use of developer effort.
Windows is certainly the highest-value target for client diversity efforts. I hear the Brave company is hiring someone to work specifically on Tor integration, maybe you want to apply: https://brave.com/jobs/?gh_jid=781438
In my opinion, the best way to improve relay diversity would be to work on system administration automation. For instance, as far as I know there is no equivalent of Debian's 'unattended-upgrades' tool for any of the BSDs, or even for most Linux distributions.
zw
(Please forgive the top-posting and HTML, I'm writing this on a phone.)
On Sat, Aug 19, 2017 at 4:56 AM Duncan dguthrie@posteo.net wrote:
Firstly, a note of caution: I am not affiliated with the Tor project.
Scott Bennett:
Duncan dguthrie@posteo.net wrote:
In theory hot-patching kernels is a great idea.
However, they're technically not loading a new kernel. Something like kexec in theory lets one load a new kernel.
Furthermore, these hot-patching programs usually only support Linux. If we want to increase the diversity of the Tor network, as we most certainly should, then we need more BSD relays, so these hot-patching programs don't cut it.
The tor project has made the point that OS diversity is important,but it has failed to show the courage of its conviction. It commits great effort to maintain a "safe" tor browser for the OS for which tor relays currently abound, yet still offers no version of that browser to entice *BSD, Solaris, MINIX, or other OS users to run tor relays. Instead, such users are apparently expected either to use clearly unsafe browsers or to run VMs of other than their native OS to run a safe browser. The tor community is thus very lucky for what diversity of relay OS currently exists.
If I may, the point of diversifying the network is *not* to "entice" BSD/Solaris/MINIX users, the number of which, even compared to Linux, which is quite low, is astonishingly small. I'd argue more effort should actually be put into hardening Tor Browser for Windows, as it is on Linux that much of the hardening efforts are currently being focused, unfortunately.
The point is that as it stands, serious bugs that affect Linux currently affect the entirety of the Tor network. As a mono-culture, this could cause problems in the future, especially as the network expands. This is an issue for client users too, certainly. However, it is not clear that there would be a benefit to providing builds to operating systems with a very low number of users. I'm sure there are people using BeOS or Plan 9 which want to use Tor Browser, after all. They can always compile it from source if they wish (whether it would run is another matter, but that is work that would take away from helping a greater number of users).
That being said, there is in fact the very good TorBSD project which provides Tor Browser builds for OpenBSD. I do not know what the situation with FreeBSD is, but that provides a Linux compatibility layer, which I've heard Tor Browser works with. Here it is: http://torbsd.github.io/
I've pointed this problem out several times, but to the best of mymemory, none of the tor developers has ever responded on this issue.
Scott Bennett, Comm. ASMELG, CFIAG
- Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
- "A well regulated and disciplined militia, is at all times a good *
- objection to the introduction of that bane of all free governments *
- -- a standing army." *
- -- Gov. John Hancock, New York Journal, 28 January 1790 *
Best, Duncan _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Zack Weinberg zackw@cmu.edu wrote:
Relay diversity and client diversity are two different things. Last I heard
People who run relays usually started out as people running clients. They liked tor and decided to help out by running a relay, *too*. Do you really believe they would choose to install some OS other than what they already use just to help diversify the relay population? I haven't used the tor browser bundle for Windows in a long time. Does its controller's GUI still offer the option of running a relay in addition to being a client while tor is up and running? Some of us only run one computer. Are you suggesting that we spin up a VM to install an unfamiliar OS on which to run a relay, just to help with relay diversity? What current client-user will leap at the idea of learning to do all that and do it safely in order to run a relay, which he also will need to learn to do safely, when he could instead just run a relay on a system he already knows, thereby reducing his learning load to only the stuff he needs to know about tor? The volume of material needed to learn an OS vastly exceeds what a new relay operator needs to know about tor, after all.
it was a bad idea to run a relay on the same computer as a client, so I
It's arguably a bad idea to do that if your relay is an Exit, but then it's usually an even worse idea to run an Exit at home. Some people think it's a bad idea to run tor outside of a jail, too. (Unfortunately, most OS do not have jails.)
don't think Tor Browser for server OSes like Solaris is a great use of developer effort.
I suggest you ponder more on the matter of where relay operators come from and what they might be willing to do or have the resources to devote to running OS foreign to their normal uses for their computers. Either you want to recruit for diversity or you just want to serve the OS that are already most abundantly running relays. If you want to recruit for diversity, then you need to consider how you're going to do that successfully. I contend that that generally means recruiting people who are already running those OS. That, in turn, means getting them to learn about tor by giving them something they can use to try it out. Telling them, "We'd like you to run a tor relay on your Bitrig system, though you won't be able to get much use out of it yourself, not even to try it out", doesn't seem to me to be very likely to cut it. That idea also seems to be corroborated by the current relay diversity, which is the situation that has brought us to the current discussion. Running a relay safely and smartly has a significant learning curve to climb at the outset. Making it appealing enough to them to climb it is called recruiting.
Windows is certainly the highest-value target for client diversity efforts.
How so? (Unless by target you mean client users to be eliminated? That would certainly be *an* approach to increasing client OS diversity, but not an acceptable one, IMHO.) It already has the most clients. Anyway, we're not discussing increasing client OS diversity in this thread, but rather increasing the OS diversity of relays. Please stop to consider what diversification and diversity actually mean, which is the opposite of what you argue for here. They don't mean piling most of the resources into growing the dominant subpopulation. The same applies to LINUX.
I hear the Brave company is hiring someone to work specifically on Tor integration, maybe you want to apply: https://brave.com/jobs/?gh_jid=781438
Windows is already running a huge percentage of the tor relay population. How are you going to recruit Windows users to run relays on an OS they don't already use? I contend that you won't. Instead, you must recruit current users of such OS.
In my opinion, the best way to improve relay diversity would be to work on system administration automation. For instance, as far as I know there is no equivalent of Debian's 'unattended-upgrades' tool for any of the BSDs, or even for most Linux distributions.
Are you kidding? Debian's "unattended-upgrades" tool must be something spectacular then. Please tell us what it does that isn't handled by, say, freebsd-update for the base OS and "pkg upgrade --yes" for the installed packages like tor? IIRC, DragonflyBSD uses pkg, too. Or how about pkgsrc on NetBSD? I've forgotten what OpenBSD uses, but it may well be pkgsrc. As for how the other BSDs perform binary updates of their base OS, I couldn't tell you, but I'd be astonished if they didn't have something for that. Just use crontab entries to run these tools unattended and periodically. On FreeBSD, if you build your ports from source via the ports tree, you could run "svn update /usr/ports" and either use portmaster or poudriere to build them and install the newly built versions. A lot of people do something similar for updating the base system from source in the other BSDs. The FreeBSD developers are in the process of setting up large blocks of the base OS as packages that can be automatically updated just like any packages built from ports, although I don't think that's quite ready for prime time yet. NetBSD may already have this capability; I just don't recall. Relay operators do not come into existence like virtual particle pairs from a vacuum. We're talking about humans, and those come from real-life, individual contexts. If you want to recruit them, then understanding and accepting that fact are critical to doing it successfully.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
Hi all,
I have been following the emails with intrigue. I run a Windows10 system at home through Virgin Media Hub, my package with them is the 300Mbps one. I recently had cause to research what Tor was about. I decided upon that research to run a Middle Relay.
So I purchased my computer parts (I self Build my machines) and obtained the help of a friend to load Ubuntu 16.04 LTS. It's not a super machine but it runs on a AMD A4-6300 APU with Radeon(tm) HD Graphics × 2 - OS 64bit - with an SSD hard drive.
I followed the instructions on how to load the relay and set it up, took me more than a week or so as I am no genius on Linux.
slow learning curve but we got there.
My relay is called Ybslik - it's been up and down due to my inability to understand how to configure things within the terminal.
But with the help from StackExchange I have been able to complete some tasks.
My small relay is now working ok and I hope adding to the Diversity of Tor.
Ybslik
Steve Bishop
On 19/08/17 17:01, Scott Bennett wrote:
Zack Weinberg zackw@cmu.edu wrote:
Relay diversity and client diversity are two different things. Last I heard
People who run relays usually started out as people running clients.They liked tor and decided to help out by running a relay, *too*. Do you really believe they would choose to install some OS other than what they already use just to help diversify the relay population? I haven't used the tor browser bundle for Windows in a long time. Does its controller's GUI still offer the option of running a relay in addition to being a client while tor is up and running? Some of us only run one computer. Are you suggesting that we spin up a VM to install an unfamiliar OS on which to run a relay, just to help with relay diversity? What current client-user will leap at the idea of learning to do all that and do it safely in order to run a relay, which he also will need to learn to do safely, when he could instead just run a relay on a system he already knows, thereby reducing his learning load to only the stuff he needs to know about tor? The volume of material needed to learn an OS vastly exceeds what a new relay operator needs to know about tor, after all.
it was a bad idea to run a relay on the same computer as a client, so I
It's arguably a bad idea to do that if your relay is an Exit, but thenit's usually an even worse idea to run an Exit at home. Some people think it's a bad idea to run tor outside of a jail, too. (Unfortunately, most OS do not have jails.)
don't think Tor Browser for server OSes like Solaris is a great use of developer effort.
I suggest you ponder more on the matter of where relay operators comefrom and what they might be willing to do or have the resources to devote to running OS foreign to their normal uses for their computers. Either you want to recruit for diversity or you just want to serve the OS that are already most abundantly running relays. If you want to recruit for diversity, then you need to consider how you're going to do that successfully. I contend that that generally means recruiting people who are already running those OS. That, in turn, means getting them to learn about tor by giving them something they can use to try it out. Telling them, "We'd like you to run a tor relay on your Bitrig system, though you won't be able to get much use out of it yourself, not even to try it out", doesn't seem to me to be very likely to cut it. That idea also seems to be corroborated by the current relay diversity, which is the situation that has brought us to the current discussion. Running a relay safely and smartly has a significant learning curve to climb at the outset. Making it appealing enough to them to climb it is called recruiting.
Windows is certainly the highest-value target for client diversity efforts.
How so? (Unless by target you mean client users to be eliminated? Thatwould certainly be *an* approach to increasing client OS diversity, but not an acceptable one, IMHO.) It already has the most clients. Anyway, we're not discussing increasing client OS diversity in this thread, but rather increasing the OS diversity of relays. Please stop to consider what diversification and diversity actually mean, which is the opposite of what you argue for here. They don't mean piling most of the resources into growing the dominant subpopulation. The same applies to LINUX.
I hear the Brave company is hiring someone to work specifically on Tor integration, maybe you want to apply: https://brave.com/jobs/?gh_jid=781438
Windows is already running a huge percentage of the tor relay population.How are you going to recruit Windows users to run relays on an OS they don't already use? I contend that you won't. Instead, you must recruit current users of such OS.
In my opinion, the best way to improve relay diversity would be to work on system administration automation. For instance, as far as I know there is no equivalent of Debian's 'unattended-upgrades' tool for any of the BSDs, or even for most Linux distributions.
Are you kidding? Debian's "unattended-upgrades" tool must be somethingspectacular then. Please tell us what it does that isn't handled by, say, freebsd-update for the base OS and "pkg upgrade --yes" for the installed packages like tor? IIRC, DragonflyBSD uses pkg, too. Or how about pkgsrc on NetBSD? I've forgotten what OpenBSD uses, but it may well be pkgsrc. As for how the other BSDs perform binary updates of their base OS, I couldn't tell you, but I'd be astonished if they didn't have something for that. Just use crontab entries to run these tools unattended and periodically. On FreeBSD, if you build your ports from source via the ports tree, you could run "svn update /usr/ports" and either use portmaster or poudriere to build them and install the newly built versions. A lot of people do something similar for updating the base system from source in the other BSDs. The FreeBSD developers are in the process of setting up large blocks of the base OS as packages that can be automatically updated just like any packages built from ports, although I don't think that's quite ready for prime time yet. NetBSD may already have this capability; I just don't recall. Relay operators do not come into existence like virtual particle pairs from a vacuum. We're talking about humans, and those come from real-life, individual contexts. If you want to recruit them, then understanding and accepting that fact are critical to doing it successfully.
Scott Bennett, Comm. ASMELG, CFIAG
- Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
- "A well regulated and disciplined militia, is at all times a good *
- objection to the introduction of that bane of all free governments *
- -- a standing army." *
- -- Gov. John Hancock, New York Journal, 28 January 1790 *
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi!
Ybslik:
Hi all,
I have been following the emails with intrigue. I run aWindows10 system at home through Virgin Media Hub, my package with them is the 300Mbps one. I recently had cause to research what Tor was about. I decided upon that research to run a Middle Relay.
So I purchased my computer parts (I self Build my machines) and obtained the help of a friend to load Ubuntu 16.04 LTS. It's not a super machine but it runs on a AMD A4-6300 APU with Radeon(tm) HD Graphics × 2 - OS 64bit - with an SSD hard drive.
I followed the instructions on how to load the relay and set it up, took me more than a week or so as I am no genius on Linux.
slow learning curve but we got there.
My relay is called Ybslik - it's been up and down due to my inability to understand how to configure things within the terminal.
Thanks for running a relay!
But with the help from StackExchange I have been able to complete some tasks.
My small relay is now working ok and I hope adding to the Diversity of Tor.
However, it's worth noting that by the "diversity of the Tor network", we're trying to push for non-Linux relays. It's just a point to note - it's great you've run a relay, it's just that you've not added to the diversity of the operating system of relays. If you feel able to, if or when you spin up a new relay, you should consider running a BSD, e.g. OpenBSD. However, diversity of location is also important, one supposes! So your home relay is at least adding to that, depending on where you live.
Thanks for running a relay, Duncan
Duncan:
Hi!
Ybslik:
Hi all,
Not sure how to start interjecting into this thread, but it does fit into how this August hasn't been a usual "dog days of summer" in more ways than one.
Coming from the perspective of TDP (https://torbsd.github.io/). . .
Some comments below, including replies to earlier pieces that were sniped.
I have been following the emails with intrigue. I run aWindows10 system at home through Virgin Media Hub, my package with them is the 300Mbps one. I recently had cause to research what Tor was about. I decided upon that research to run a Middle Relay.
So I purchased my computer parts (I self Build my machines) and obtained the help of a friend to load Ubuntu 16.04 LTS. It's not a super machine but it runs on a AMD A4-6300 APU with Radeon(tm) HD Graphics × 2 - OS 64bit - with an SSD hard drive.
I followed the instructions on how to load the relay and set it up, took me more than a week or so as I am no genius on Linux.
That is a significant point. Do you really want someone not familiar with an OS to start running it as a public relay? I certainly don't.
I'd rather have Windows admins who are comfortable with their OS running relays as opposed to any other OS. I would rather hit a relay from Tom R than a lot of other people...
slow learning curve but we got there.
My relay is called Ybslik - it's been up and down due to my inability to understand how to configure things within the terminal.
Thanks for running a relay!
Yes. Thanks.
But with the help from StackExchange I have been able to complete some tasks.
My small relay is now working ok and I hope adding to the Diversity of Tor.
However, it's worth noting that by the "diversity of the Tor network", we're trying to push for non-Linux relays. It's just a point to note - it's great you've run a relay, it's just that you've not added to the diversity of the operating system of relays. If you feel able to, if or when you spin up a new relay, you should consider running a BSD, e.g. OpenBSD. However, diversity of location is also important, one supposes! So your home relay is at least adding to that, depending on where you live.
Thanks for running a relay,
Yup!
And stick to an OS you know best.
In regards to the other questions:
Windows is already running a huge percentage of the tor relay population.How are you going to recruit Windows users to run relays on an OS they don't already use? I contend that you won't. Instead, you must recruit current users of such OS.
Well, not really from our stats.
From the bandwidth measure:
https://torbsd.github.io/oostats/relays-bw-by-os.txt
By consensus weight:
https://torbsd.github.io/oostats/relays-cweight-by-os.txt
And by just an absolute count of OSs:
https://torbsd.github.io/oostats/relays-os-count.txt
Ironically in the first two sets of stats, even OpenBSD (relatively) dwarfs Windows with bandwidth and consensus weights.
You can tinker with the stats yourself with the source here:
https://github.com/torbsd/tdp-onion-stats/
Regarding Debian "unattended-upgrade" comparisons, I don't know much about Debian nor what exactly you mean.
OpenBSD does now have syspatch (https://man.openbsd.org/syspatch) which can be in cron to note patches available for the -stable branch.
FreeBSD's pkg does the contemporary functions with packaging and updates, as does freebsd-update with the base OS as noted.
I do think the question of system automation is overblown. Most people aren't running more than a few relays, and something like clusterssh is more than enough, along with the tools already in the base of most OSs. These are not server farms in most cases, and really shouldn't be. How much time can we imagine people spend tailing logs on stable Tor relays?
Sometimes I feel like I should just work on comparison charts to deal with FUD regarding the BSDs.
I have no idea why relay admins become relay admins. I did see one of the early presentations by Roger and Nick in NYC a very long time ago, and it was a short path from running the client to running a relay. It makes sense to court people who are already sysadmins (er, devops) to run relays, as the learning curve or familiarity with running a public server is easier to broach than for most desktop users.
In terms of client software, that's really a whole other question.
Certainly diversity matters there, but maybe with an emphasis on more developer-level issues. It's Windows and Android/iOS which dominate the "desktop" market it seems.
OpenBSD strictly adheres to standards like POSIX, making porting *from* OpenBSD an easier task. And it also means OpenBSD barks while other OSes tend to glide by errors. The licensing of the BSD operating systems is some variant of the BSD license, which may mean some are more apt to build systems that could integrate Tor Browser into it.
We are at the early stages of a TB for FreeBSD (https://github.com/torbsd/freebsd-ports/).
Finally, I have personally made this point before, and will not stop as long as it's necessary.
We have gotten nothing but encouragement and raves from many people in the Tor Project. I am yet to meet any of the large full-time or volunteer TP universe who doesn't know our project and the years we have put into it. Even when we burp something remotely interesting, it gets tweeted, even though we don't have a Twitter account.
Frankly, we're a bit overwhelmed on our end. We have obfs4proxy and its dependencies ready for testing for both OpenBSD and FreeBSD, plus it's in NetBSD ports-wip. We have to fight through each release of TB for OpenBSD but still need to get it backported so it hits -stable. I could go on and on. If you're really interested in diversity with BSDs, then fork our code on GitHub, test out the ports, etc.
Final note. I started running meetings to "recruit" Tor relays admins many years ago, maybe in 2011, among a layer of BSD people in NYC. TDP is going to start a little campaign in the BSD community to get others to do the same with bridges in the near future since bridge OS diversity is worse than relay deversity. If anyone really wants to improve the OS diversity situation and start 'recruiting' more non-Linux admins, that's a great place to start. Who's going to EuroBSDCon? vBSDCon? A great BoF topic IMHO.
As a teacher once shouted at me, "I'm from Missouri, show me." (ie, Missouri in the US claims to be the "show me" state).
g
George george@queair.net wrote:
Duncan:
Hi!
Ybslik:
Hi all,
Not sure how to start interjecting into this thread, but it does fit into how this August hasn't been a usual "dog days of summer" in more ways than one.
Coming from the perspective of TDP (https://torbsd.github.io/). . .
Some comments below, including replies to earlier pieces that were sniped.
[much text deleted --SB]
In regards to the other questions:
Windows is already running a huge percentage of the tor relay population.How are you going to recruit Windows users to run relays on an OS they don't already use? I contend that you won't. Instead, you must recruit current users of such OS.
I wrote the above paragraph, not Duncan. Someone didn't maintain the attribution chain properly.
Well, not really from our stats.
How so? None of the links below support your contention.
From the bandwidth measure:
Irrelevant to this question.
By consensus weight:
Also irrelevant to this question.
And by just an absolute count of OSs:
That's a piece of what you need to support your contention. Where is the rest of it? FWIW, tor does not report the information you need because clients that are not also relays do not report anything to the authorities. If they did, you would need still more information in order to connect the client information to the relay information. However, the whole primary point of tor is to protect those clients' users' anonymity. It seems to me that the only way to go about proving your contention would be to do a survey according to some accepted methodology from the social sciences to ask a sufficiently large sample of the relay operators running their relays on each OS on which OS they first got started using tor.
Ironically in the first two sets of stats, even OpenBSD (relatively) dwarfs Windows with bandwidth and consensus weights.
So what?
You can tinker with the stats yourself with the source here:
Very nice, but irrelevant to supporting your contention that my claim was not true.
Regarding Debian "unattended-upgrade" comparisons, I don't know much about Debian nor what exactly you mean.
If you read the posting to which I was responding, you saw it first in that posting, not mine. I simply quoted it in responding. I am not a user, much less a system administrator, of any kind of LINUX. As a very unhappy user (and new-to-UNIX system administrator) of SysVR1.05 back in 1986, I was sold on 4.3BSD the next year when I installed and first used it. I've done sysadmin work on at least three other SysV- descended UNIXes and disliked all of them. My first computer was a NeXT Cube, which came with NEXTSTEP (MACH 2.6 kernel, 4.3BSD userland, plus ObjC-based OOPS and NEXTSTEP windowing system, which later became the base, except for the windowing system, for OS X). When I bought my first x86-based machine, it came with Micro$lop Windows XP installed, the most disgraceful excuse for an operating system I had ever encountered. I immediately got my hands on a copy of the then latest release of FreeBSD at that time (5.2.1-RELEASE) and have been a mostly happy user and sysadmin ever since. For the last few years, I have been dealing with email via this account on a NetBSD system, which also happens to suit me pretty well. LINUX is a fine system, according to many people, but it's not UNIX, and it's not a BSD-style of system. If there were no BSDs, I would certainly run LINUX, especially given that other UNIX workalikes are usually proprietary (except MINIX!:-) but there are BSDs, so I don't because I don't need to. In many regards, choice of LINUX vs. a BSD is just a matter of personal taste, but there are also certain things that each system does better than any of the others, and there are quite a few features that only one or a few support. If you need/want certain things in an OS (e.g., a particular file system), then that may push you toward one system or a small subset of the OS available. I got introduced to tor shortly before I got FreeBSD installed on that now defunct computer, so techically speaking, I first got started with it on Windows, but I switched to FreeBSD ASAP, and that was where I really began to learn about tor and got to the point where I was willing to try my hand at running a relay. I never was a willing Windows user in the first place. BSD UNIX was what I knew well, and Windows was an endless source of maddening frustration. IOW, I feel like I got to know and understand tor on FreeBSD and only then began running a relay. Most Windows users are unlikely to have job experience doing system administration of any kind. They may know how to use its GUI and a number of applications well enough for what they do, but they generally are not programmers or sysadmins. I'm not especially surprised that a much smaller proportion of relays today is running on Windows systems. Just to understand tor's man page requires some technical understanding of operating systems and how they work internally, as well as how they look from outside. The average Windows user probably doesn't have the background to feel confident about diving in to setting up a relay. The tor browser bundle once defaulted to configuring and running a relay, although there was a check box that could be unchecked to prevent an instance from being configured as a relay. Times have changed. :-) My claim still stands. If someone would like to run a properly designed survey to disprove it, be my guest. I would be most interested in the results. In the meantime, I repeat my point that not having a tor browser for an operating system is not the way to go if you want more relays on that OS. People use whatever OS they use and for their own reasons. If you want them to run a relay on their machines in addition to what they normally run, they are not likely to switch OS just to try out tor, much less to fulfill your wish. If you want them to become familiar with tor to the point where they might run a relay, give them a browser they can use on their own system. IOW, target the people who are already using those OS, with the caveat that the technically ignorant are far less likely to tackle running a relay (the older label in the documentation being "server", which probably deters even more people from running relays because of feeling it would be too hard or over their heads).
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
Ybslik contact@ybslik.xyz wrote:
I have been following the emails with intrigue. I run a[details omitted --SB]
My relay is called Ybslik - it's been up and down due to my inability to understand how to configure things within the terminal.
But with the help from StackExchange I have been able to complete some tasks.
My small relay is now working ok and I hope adding to the Diversity of Tor.
Thank you for running a relay. Duncan dguthrie@posteo.net has already pointed out that choosing one of the two most heavily represented relay OS reduces, rather than increases, relay OS diversity. I thank you for your intent, even though you apparently misunderstood what was meant by diversity. In any case, I commend your bravery and energy in taking up a system new to you to run tor, but I also recommend you study security issues and features closely in any OS with which you are not yet intimately familiar but choose for running a relay. Having written that, if you someday choose to tackle learning yet another OS, please consider running a relay on one of the underrepresented relay OS. See, for example and in merely alphabetical order, Bitrig, DragonflyBSD, FreeBSD, Illumos, MINIX, MirOS, OpenBSD, NetBSD, NextBSD, OpenSolaris, TrueOS (bleeding-edge FreeBSD specially packaged for novices and the only slightly involved:^), or any other OS on which tor builds properly yet is currently poorly represented among existing tor relays. If I'm not mistaken, among the four largest BSD projects (i.e., FreeBSD, DragonflyBSD, NetBSD, OpenBSD), NetBSD is the most weakly represented among tor relays, which is too bad (IMO) because it is a very high-performance system that runs on damned nearly every kind of device with some kind of CPU chip in it, which makes it terrific for increasing hardware architectural diversity among relays, too. DragonflyBSD is probably second rarest of those four in the tor relay population. Learning these OS can have other, peripheral benefits, too. For example, you will find packet filters, file systems, scheduling and dispatching algorithms, I/O subsystems, virtual memory models, virtual machine support, etc. that are not found in Windows or LINUX. That is not to say that they are necessarily better than what you might find in LINUX, but they demonstrate a lot of different, creative, and interesting ideas about how to do things that you don't get exposed to by restricting your experience to the most heavily used OS. IMO, though, they are almost always better than what is available to choose from in Windows.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
Learning these OS can have other, peripheral benefits
Very true.
For reference, Solaris has been more or less dead ever since Oracle killed Sun and re-closed it. Now it's officially dead beyond "support" contracts, subject only to any benevolent and heroic zombie efforts, which are extremely unlikely due to its [line]age and license... https://meshedinsights.com/2017/09/03/oracle-finally-killed-sun/
Still, it presents a different attack surface, at least beyond the network application itself, if you can compile on it. Run a few nodes for fun if you want (fun being half the point of running nodes), you can still get the i386/amd64 binaries here... https://www.oracle.com/solaris/solaris11/index.html
But as a formal production OS, especially for the non-corporate opensource community since ever, Solaris proper is deader than long decayed and untouchable dead.
If you want the Sun family lineage, go with https://www.openindiana.org/ or maybe if you're stuck in the GNU toolchain, https://www.osdyson.org/ or if you want something that's actively maintained with at least some actual "Unix" heritage and unique feel https://www.freebsd.org/ or any other BSD like Open or Dragon or Net.
Every Linux / Windows / Apple user owes it to themselves to try something in the BSD family for at least a few months or so.
Don't forget Plan9, Open/Free VMS, MINIX, GNU HURD, HP-UX, AIX, FreeDOS, Android, iOS, OSX, etc.
Regardless of which overlay network you're using, or plugging nodes into, have fun gettin jiggy wit it :)
How this got off into TorBrowser puzzles me. Presumably the goal for clients is to reach them where they are. Certainly providing a diversity of clients is a "good goal" but beyon dreaching more users I fail to see how it helps the network writ large. I suppose indvitual users woudl be mroe secure with a wider array of clients available, but that's generally true of the Windows monculture in desktop computers. And as we shift to Android moblie devices as people primary internet connection many of those issues will likely follow, but I digress...
For relay diversity it's more obvious. If you can sabotage 93.6% of the band width because a Linux specific bug either in TOR or just the OS that's a huge problem (from https://torbsd.github.io/oostats/relays-bw-by-os.txt, sorry I forget who to credit but if you read the thread you will see...).
I run https://atlas.torproject.org/#details/A53C46F5B157DD83366D45A8E99A244934A14C... which in it's current incarnation is FreeBSD 11 since January 2017 or so. Though for most of it's life had been Debian or Ubuntu.
I'm definitely a "Linux Weenie" specifically of the Debian family so I enjoy what "unattended upgrades" can do interms of when and what you automatically upgrade and when/if to reboot if needed, but really the 98% of that that really matters you can do with a small shell script + cron. Installing TOR isn't really appreciably harder either "pkg install tor" is just as easy as "apt install tor" for people who want to live in a packed rather than source world. So I don't think the complecity barrier is real (though the perception of one may be a deterrent).
Looking at https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Public_server... it seems TOR relay OS's while skewed toward Linux and away from Windows aren't that far off from at least soem studies of "Internet based servers' market share". I debate the accuracy of these in general but within some largish margin of error they are probably not untrue.
Monoculture isn't just a TOR problem. I think we should advocate for it but I don't think we can solve it just in a TOR context. So yes if you run relays go learn some underserver Operating Systems the BSDs are a little weird at first coming from Linux but you're clever you'll manage or maybe go way out there to one of the Firefly (OpenSolaris) variants...but diversify all the things nto just TOR.
-Jon
Jonathan Proulx:
How this got off into TorBrowser puzzles me. Presumably the goal for clients is to reach them where they are. Certainly providing a diversity of clients is a "good goal" but beyon dreaching more users I fail to see how it helps the network writ large. I suppose indvitual users woudl be mroe secure with a wider array of clients available, but that's generally true of the Windows monculture in desktop computers. And as we shift to Android moblie devices as people primary internet connection many of those issues will likely follow, but I digress...
With TB as a client, I just mentioned the development end in an earlier email. There's certainly more to it.
There are certainly weaknesses in a client monoculture that differs from the network/node side on some levels, as the client software is in some chases the user base.
But it always seem to me users sometimes use the OS that provide the applications they want. TB matters insofar as one of those applications, I tend to think.
On the whole, one needs to consider that the same single vulnerability that weakens an OS on the network level could also affect the desktop.
For relay diversity it's more obvious. If you can sabotage 93.6% of the band width because a Linux specific bug either in TOR or just the OS that's a huge problem (from https://torbsd.github.io/oostats/relays-bw-by-os.txt, sorry I forget who to credit but if you read the thread you will see...).
And if you compromise the vast majority of desktop users, you don't just implicate those users with the vulnerability, but a big drop in the majority client OS would mean the crowd, so desperately needed for an anonymity solution, thins out.
Credit? Yes... us at TDP (https://torbsd.github.io/)
I run https://atlas.torproject.org/#details/A53C46F5B157DD83366D45A8E99A244934A14C... which in it's current incarnation is FreeBSD 11 since January 2017 or so. Though for most of it's life had been Debian or Ubuntu.
I'm definitely a "Linux Weenie" specifically of the Debian family so I enjoy what "unattended upgrades" can do interms of when and what you automatically upgrade and when/if to reboot if needed, but really the 98% of that that really matters you can do with a small shell script + cron. Installing TOR isn't really appreciably harder either "pkg install tor" is just as easy as "apt install tor" for people who want to live in a packed rather than source world. So I don't think the complecity barrier is real (though the perception of one may be a deterrent).
As I stated earlier, the tools for FreeBSD and OpenBSD are there.
utilities like syspatch on OpenBSD stable can be put into a regular cron job.
Same with pkg and freebsd-update on FreeBSD.
Note the BSDs provide daily/weekly/monthly emails by default, and any notifications are already or could easily be integrated into those emails.
Looking at https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Public_server... it seems TOR relay OS's while skewed toward Linux and away from Windows aren't that far off from at least soem studies of "Internet based servers' market share". I debate the accuracy of these in general but within some largish margin of error they are probably not untrue.
Monoculture isn't just a TOR problem. I think we should advocate for it but I don't think we can solve it just in a TOR context. So yes if you run relays go learn some underserver Operating Systems the BSDs are a little weird at first coming from Linux but you're clever you'll manage or maybe go way out there to one of the Firefly (OpenSolaris) variants...but diversify all the things nto just TOR.
I'm a little confused by that paragraph, but I do think it's possible to rectify the situation to a large extent. A large number of firms use BSD in their infrastructure or code (WhatsApp, NetFlix, Juniper...). What if some started to run relays or bridges? What if there was a list of BSD virtual private server firms that allowed Tor relays/bridges? I can go on and on, but those are the type of approaches we are trying at TDP.
Giving up on network diversity for Tor is essentially allowing it to remain vulnerable to a single kernel weakness.
On a side note, there's a reason why computing systems tend to monocultures. They are easier to build, maintain and develop on. It's more efficient to make the same exact widget out of a machine than it is to make six variations. That doesn't apply to the many current and potential relays operators out there.
g
On 23 Aug 2017, at 10:10, George george@queair.net wrote:
How this got off into TorBrowser puzzles me. Presumably the goal for clients is to reach them where they are. Certainly providing a diversity of clients is a "good goal" but beyon dreaching more users I fail to see how it helps the network writ large. I suppose indvitual users woudl be mroe secure with a wider array of clients available, but that's generally true of the Windows monculture in desktop computers. And as we shift to Android moblie devices as people primary internet connection many of those issues will likely follow, but I digress...
With TB as a client, I just mentioned the development end in an earlier email. There's certainly more to it.
There are certainly weaknesses in a client monoculture that differs from the network/node side on some levels, as the client software is in some chases the user base.
But it always seem to me users sometimes use the OS that provide the applications they want. TB matters insofar as one of those applications, I tend to think.
On the whole, one needs to consider that the same single vulnerability that weakens an OS on the network level could also affect the desktop.
We love it when people run Tor on all sorts of platforms. It helps us write better software, find obscure bugs, and help more people.
At the moment, the Core Tor and Tor Browser teams are focusing on getting Tor Browser working (better) on Android and iOS, the platforms with the largest web browsing share that don't have an official Tor Browser. We are also improving sandboxing across our existing Windows, Linux, and macOS builds. (And another half-dozen goals. We're busy!)
Personally, I think it's great that the Tor Diversity Project is getting different parts of Tor working on BSDs as well. We appreciate all the testing they do, and the patches they send us.
The Core Tor team also has a list of supported relay platforms.[0] We can't support a platform unless people test our alphas on that platform. We can give better support if people test bug fixes or submit patches when a platform breaks.
This list isn't a value judgement on any platform: it's simply a list of what platforms we are good at supporting, using our current resources. If we can add more volunteer or funded resources, we can support more platforms.
[0]: I think it's a draft. It might be on trac, but trac is down, so I can't find it right now.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 18 Aug 2017, at 22:56, Duncan dguthrie@posteo.net wrote:
Just restart it. It takes a few minutes, it's actually guaranteed to work unlike dubious hot-patching programs.
The Tor network is distributed and redundant.
Clients will shift to using other relays if yours is down.
Even the directory authorities can restart without the network having downtime.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
tor-relays@lists.torproject.org
-
Chuck McAndrew -
Duncan -
George -
grarpamp -
Jonathan Proulx -
K. Besig -
Keepyourprivacy -
Petrusko -
Scott Bennett -
teor -
tor -
Toralf Förster -
Ybslik -
Zack Weinberg