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.<div><br></div><div>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 <a href="https://lists.torproject.org/pipermail/tor-dev/2014-December/007957.html">https://lists.torproject.org/pipermail/tor-dev/2014-December/007957.html</a><div><br><div class="gmail_quote">On Thu Jan 01 2015 at 1:23:49 PM Jeremy Olexa <<a href="mailto:jolexa@jolexa.net" target="_blank">jolexa@jolexa.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Everyone, Happy New Year, first post to the -dev list but I've been<br>
running some relays for months[1]. Overall a new user to Tor so feel<br>
free to point me elsewhere if I'm asking poor questions.<br>
<br>
I've noticed that the Tor Cloud project is dead in the water right<br>
now. The last post on this list is in June 2014[2] and the bugs have<br>
been neglected, especially the one I opened[3] which states that tor<br>
does not even start! I've seen that there is a new maintainer, but<br>
still don't see any [public] activity.<br>
<br>
There are a couple of issues that have opportunity to be handled<br>
better. A large roadblock seems to be building/publishing a new AMI so<br>
I've addressed that in a keeping it simple theme:<br>
- Use Amazon AMI instead of Ubuntu. Justification: more aligned to AWS<br>
and is a first rate citizen in the ecosystem, yum repos, security<br>
updates, etc<br>
- Use t2.micro instances. Justification: t1.micro (currently in use)<br>
are more expensive and less performant than t2.micro<br>
- Use cloud-init to fetch ec2-prep.sh and run the script to configure<br>
the instance[4]. Justification: Less likely to roll a new AMI just for<br>
ec2-prep.sh updates therefore more of a rolling update infrastructure.<br>
One example is adding a new bridge protocol, all newly launched<br>
instances would get the ec2-prep updates without rolling a new AMI.<br>
Justification 2: Less Tor Cloud maintainer work. Downside: AMI has<br>
dependency on <a href="http://gitweb.torproject.org" target="_blank">gitweb.torproject.org</a>'s uptime - we could use S3 or some<br>
other CDN but this is starting to go against the simple theme.<br>
- Publishing AMI to us-east (N Virginia), us-west2 (Oregon), us-europe<br>
(Ireland). Justification: These are the lowest cost regions.<br>
- Not publishing a separate AMI for private bridges. Justification: IF<br>
the Tor Cloud project wants to provide configuration for private<br>
bridges, reusing the shared AMI makes more sense. I have an idea of<br>
using cloud-init's user-data field but need to test it. Justification<br>
2: Simpler, less Tor Cloud maintainer work.<br>
- Not addressed (yet): Ubuntu's unattended upgrades concept. I have<br>
one idea (yum security plugin) but I haven't thought about all the<br>
implications.<br>
<br>
My AMI testing has proved that the above concepts work and I have ec2<br>
bridges running in east and west[5]. I propose that the TOR project<br>
uses the above model and I'm willing to help facilitate that. I am<br>
willing to share the AMI with some select beta testers but I'm not<br>
ready to make it public yet (some changes are expected). It is my idea<br>
that once the final AMI is produced, the Tor Cloud project will not<br>
have to publish another AMI unless wanting to change the instance<br>
type, or other "infrastructure" changes.<br>
<br>
I look forward to hearing some feedback, thanks,<br>
Jeremy<br>
<br>
[1]: <a href="https://atlas.thecthulhu.com/#search/jolexa" target="_blank">https://atlas.thecthulhu.com/#<u></u><u></u>search/jolexa</a><br>
[2]: <a href="https://lists.torproject.org/pipermail/tor-dev/2014-June/007001.html" target="_blank">https://lists.torproject.org/<u></u>p<u></u>ipermail/tor-dev/2014-June/<u></u>007<u></u>001.html</a><br>
[3]: <a href="https://trac.torproject.org/projects/tor/ticket/13391" target="_blank">https://trac.torproject.org/<u></u>pr<u></u>ojects/tor/ticket/13391</a><br>
[4]: <a href="https://github.com/jolexa/tor-cloud/blob/master/run-once.sh" target="_blank">https://github.com/jolexa/tor-<u></u><u></u>cloud/blob/master/run-once.sh</a><br>
[5]: <a href="https://globe.thecthulhu.com/#/search/query=ec2bridgei" target="_blank">https://globe.thecthulhu.com/#<u></u><u></u>/search/query=ec2bridgei</a><br>
______________________________<u></u><u></u>_________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/<u></u>c<u></u>gi-bin/mailman/listinfo/tor-<u></u>de<u></u>v</a><br>
</blockquote></div></div></div>