[tor-dev] Tor Cloud Maintenance, revisited

[Jeremy Olexa <jolexa@xxxxxxxxxx>]

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