Re: [tor-relays] VPS
On Sun, 20 Oct 2013 12:40:52 -0800 I beatthebasta...@inbox.com allegedly wrote: Mick, Is Serverstack.nl particularly pro-tor exit nodes? By the front page it would seem so. Robert Heh! I hadn't seen that before. (Though take a look at serverstack.com for a more, erm, normally corporate front page). Honestly, I do not know serverstack's position. I rent that particular VPS from digitalocean, it just happens to be in Amsterdam on AS46652. digitalocean's own position appears to be supportive of non-exit relays only. Mick - Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net - signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] rm /var/lib/tor/keys/* before changing exit policy?
Martin Kepplinger: Really quick not too important question. When switching a relay to become an exit node or the other way round, does it make sense to delete /var/lib/tor/keys/* beforehand and start it over this way? Why would you want to do that? Updates to a relay's exit policy are spread to clients through the consensus and can be done at any moments. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] rm /var/lib/tor/keys/* before changing exit policy?
Lunar: Martin Kepplinger: Really quick not too important question. When switching a relay to become an exit node or the other way round, does it make sense to delete /var/lib/tor/keys/* beforehand and start it over this way? Why would you want to do that? Updates to a relay's exit policy are spread to clients through the consensus and can be done at any moments. Because, say, i change from guard to (possible) exit. it maybe stays an entry node for those who have it and doesn't serve as an exit as much as it could. The tor net is probably more in need of exits that guards. And I don't know if similar mechanisms exist in a non-guard case. It's just speculation. ___ 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
Re: [tor-relays] rm /var/lib/tor/keys/* before changing exit policy?
On 10/21/2013 01:52 PM, Martin Kepplinger wrote: Lunar: Martin Kepplinger: Really quick not too important question. When switching a relay to become an exit node or the other way round, does it make sense to delete /var/lib/tor/keys/* beforehand and start it over this way? Why would you want to do that? Updates to a relay's exit policy are spread to clients through the consensus and can be done at any moments. Because, say, i change from guard to (possible) exit. it maybe stays an entry node for those who have it and doesn't serve as an exit as much as it could. The tor net is probably more in need of exits that guards. And I don't know if similar mechanisms exist in a non-guard case. It's just speculation. A relay may serve both as guard and as exit. There is no problem with that. Just update your exit policy in torrc and restart tor (or send a SIGHUP signal to tor process). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] rm /var/lib/tor/keys/* before changing exit policy?
You shouldn't really worry about these things. If the network is better off with an exit who doesn't have the guard flag, the authorities should remove the guard flag, which will cause a gradual migration away from you as a guard, rather than failed circuits as nodes keep attempting to connect to your exit just to find an unexpected identity and disconnecting again. On Mon, Oct 21, 2013 at 7:08 AM, irregula...@riseup.net wrote: On 10/21/2013 01:52 PM, Martin Kepplinger wrote: Because, say, i change from guard to (possible) exit. it maybe stays an entry node for those who have it and doesn't serve as an exit as much as it could. The tor net is probably more in need of exits that guards. And I don't know if similar mechanisms exist in a non-guard case. It's just speculation. A relay may serve both as guard and as exit. There is no problem with that. Just update your exit policy in torrc and restart tor (or send a SIGHUP signal to tor process). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] minimum ram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I: To see if it was possible just now I set up an obfsproxy bridge as best I could but it failed to download properly. Can you be more specific about what this means? What exactly happened? The instructions say set up Tor then the obfsproxy software which seemed to use up the ram. (I've reinstalled the OS from Ubuntu 11.. to Quantal) I generally use Debian for very low-end servers as it's pretty easy to have a pared-down install that uses very little RAM for the OS. When you first boot your VPS and don't have *anything* else running - no Tor, no obfsproxy - what is the output of 'free -m'? Have I misunderstood something? Is there an easier way to set up a bridge like the Amazon ECC ones on a 256mB VPS that ab initio Linux people can try? Not yet, although it's a worthy project - the difference is that bridges need to be long-lived - you want it to be up for months or years, which AFAIK is not the case with the free Amazon EC2 instances, they're temporary relays unless you decide to pay for EC2. (The free usage amount on EC2 does not allow you to operate even for a whole month, fine for relays in some sense, sort of, not good for bridges). If the Tor Project wants to be really big it would seem to be better to be easier to provide resources such as your idea of a box anyone can plug in. Well, they only have a few really smart people working on the core anonymity and crypto problems that people like me could never hope to understand, so it's up to me and you and other people who understand the importance of Tor to help provide those solutions. :) A plug-and-forget bridge package with a list of known good microVPS providers would be a great thing, though. My Raspberry Pi/single-board-computer project will definitely end up in more bridges if I complete it, because it will urge the user to be a bridge if they're really too slow to be a relay (and automatically reconfigure itself if their link becomes too slow and stays that way for a long time - at least, that's the plan). Best, - -Gordon M. Robert -Original Message- From: gor...@morehouse.me Sent: Sun, 20 Oct 2013 19:37:11 -0700 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] minimum ram I: Gordon, It seems useful to run obfsproxy bridges on $1 a month VPSs then. Can weather.torproject.org be used to monitor whether they're running or not? That's a very good question - I hadn't tried monitoring my bridges with it because I had other means. Fortunately, a reboot to a bridge doesn't set it back like it would a relay. Users of the bridge are inconvenienced (maybe) while it's offline, but cheap VPSes are *great* for dedicated bridges, and 128MB RAM is currently enough. Best, -Gordon M. Is there any utility in the very cheap VPSs with 128mb of ram? I did some testing quite a while ago and found that 256MB was the minimum amount of RAM for a relay. It works for some time with 128MB, but it then runs out of memory, and it is not very good to have it restart all the time. I say was because currently, with more than 3 million clients in the network, a relay might even run out of memory with 256MB RAM. I don't have any current data on that though. A 128MB VPS can comfortably support an obfsproxy bridge - just get a provider that doesn't reboot you a ton. I've run a number of such bridges. I would not go below 512MB RAM for a relay that is going to handle more than 2Mbps (about 200KB/sec) - you will eventually run out of RAM and Tor will be killed, and that's not great for the network. My source for the above is a lot of blood, sweat and tears with Tor on the Raspberry Pi model B. :) Best, - -Gordon M. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSZUUeAAoJED/jpRoe7/ujFsEH/je6IY9pCpxSLN8PrHVhmOfA oS9Yd9Fo7JyTkZqHfjSZIV6V/hsyB6StuGmTM3ga+y/Hz7LDnMCpEqbMOh54gVZN FTb7ylAndD8dfxtRjkFnIkdZ02w33l21z/mE5VijDEmxzTGqsAoqvGjd/5JfEmPL nz06mzfLjI8WvbhliEO1883fbrozjOYOALCO+1cErx7KN2gDPV1ZAXxL6ZSEzpdC W0e3Xf9qnn5GkcnaQvK3GZVLNAMer0r0lxMgIivOrc8r3cyIhw1buBC4Kgk1ZrnA jcm/WjJZCvJc/B+NehR+nCZDQnaXBUFca2xMe/WK9NNmsJ/tIQAjvc/rVyftBSU= =jkv+ -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay security, re: local network
On 01/10/2013 03:34, The Doctor wrote: That reminds me of a question I've been meaning to ask lately... Has anyone tried running Tor on top of OSv (http://osv.io/)? As I understand it, OSv is an ultra-small OS which is Linux API-compatible and designed for running a single app only atop a virtualization stack. For example, it should, in theory, be possible to run the Tor daemon within a copy of OSv, that would be the only application running inside of that VM, and it should be running like greased lightning because it would be the only process running in that VM. First, I see no figures about the alleged performance of OSv. Secondly, I suspect that the kernel overhead, on a reasonable Tor node, is negligible when compared to book-keeping, crypto operations and so on. However, I'm also curious, so tell us if you try it :-) signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
