[tor-dev] Tor Cloud Maintenance, revisited

[Vlad Tsyrklevich]

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 at 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
>
> [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
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150103/8da2b23c/attachment.html>