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 <[email protected]> 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 > > [1]: https://atlas.thecthulhu.com/#search/jolexa > [2]: https://lists.torproject.org/pipermail/tor-dev/2014-June/007001.html > [3]: https://trac.torproject.org/projects/tor/ticket/13391 > [4]: https://github.com/jolexa/tor-cloud/blob/master/run-once.sh > [5]: https://globe.thecthulhu.com/#/search/query=ec2bridgei > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
