Hi Vlad,
I agree. AWS pricing is not friendly for bandwidth users. However, it is free for the first year of use and the general population is not taking advantage of this. Which, AFACT, is one of the points of the Tor Cloud project. Once you are not free-tier eligible, I highly recommend using a cheaper service like DO, Linode, Vultr, etc. At least DO and Linode would be trivial to setup.
In summary, there is no need to replace AWS, but instead to supplement it with other providers and make the Tor Cloud project more robust.
-Jeremy
On Fri, Jan 2, 2015 at 6:10 PM, Vlad Tsyrklevich vlad@tsyrklevich.net wrote:
Hi Jeremy, I've working on something related so I figured I'd comment. I've been working on a TorCloud replacement using DigitalOcean's API, this has the benefit of a simplified set-up process (one-click set-up) and the pricing on bandwidth is a major win over AWS ($5 for 1TB U/L instead of $20 for 40GB, though your move to t2.micro would move it down to $10.) The back-end is there and pretty much ready to go, I've primarily been waiting for my co-author to come back from vacation to finish the front-end.
I haven't actually discussed sunsetting/replacing the current TorCloud with the Tor Project so this project might as well be vaporware; however, I think continuing to use AWS doesn't make sense for pricing and ease-of-use. All that said, if you're taking this on, it'd be great to try to also address TorCloud's currently susceptibility to discovery by internet-wide port scanning as I mentioned in https://lists.torproject.org/pipermail/tor-dev/2014-December/007957.html
On Thu Jan 01 2015 at 1:23:49 PM Jeremy Olexa jolexa@jolexa.net wrote:
Hi Everyone, Happy New Year, first post to the -dev list but I've been running some relays for months[1]. Overall a new user to Tor so feel free to point me elsewhere if I'm asking poor questions.
I've noticed that the Tor Cloud project is dead in the water right now. The last post on this list is in June 2014[2] and the bugs have been neglected, especially the one I opened[3] which states that tor does not even start! I've seen that there is a new maintainer, but still don't see any [public] activity.
There are a couple of issues that have opportunity to be handled better. A large roadblock seems to be building/publishing a new AMI so I've addressed that in a keeping it simple theme:
- Use Amazon AMI instead of Ubuntu. Justification: more aligned to AWS
and is a first rate citizen in the ecosystem, yum repos, security updates, etc
- Use t2.micro instances. Justification: t1.micro (currently in use)
are more expensive and less performant than t2.micro
- Use cloud-init to fetch ec2-prep.sh and run the script to configure
the instance[4]. Justification: Less likely to roll a new AMI just for ec2-prep.sh updates therefore more of a rolling update infrastructure. One example is adding a new bridge protocol, all newly launched instances would get the ec2-prep updates without rolling a new AMI. Justification 2: Less Tor Cloud maintainer work. Downside: AMI has dependency on gitweb.torproject.org's uptime - we could use S3 or some other CDN but this is starting to go against the simple theme.
- Publishing AMI to us-east (N Virginia), us-west2 (Oregon), us-europe
(Ireland). Justification: These are the lowest cost regions.
- Not publishing a separate AMI for private bridges. Justification: IF
the Tor Cloud project wants to provide configuration for private bridges, reusing the shared AMI makes more sense. I have an idea of using cloud-init's user-data field but need to test it. Justification 2: Simpler, less Tor Cloud maintainer work.
- Not addressed (yet): Ubuntu's unattended upgrades concept. I have
one idea (yum security plugin) but I haven't thought about all the implications.
My AMI testing has proved that the above concepts work and I have ec2 bridges running in east and west[5]. I propose that the TOR project uses the above model and I'm willing to help facilitate that. I am willing to share the AMI with some select beta testers but I'm not ready to make it public yet (some changes are expected). It is my idea that once the final AMI is produced, the Tor Cloud project will not have to publish another AMI unless wanting to change the instance type, or other "infrastructure" changes.
I look forward to hearing some feedback, thanks, Jeremy
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev