Re: [tor-dev] Tor Cloud Maintenance, revisited

[Jeremy Olexa <jolexa@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev