Create obfsproxy images for AWS

We need more obfs2 servers. It would be nice if we could have images for various AWS regions ready to go.

added component::archived/tor cloud owner::runa priority::immediate resolution::fixed severity::normal status::closed type::task labels

Would it be bad to just add obfsproxy to our current bridge images for amazon? Then everybody running a bridge image would be accessible as a normal bridge or as an obfsproxy bridge.

Also, then we don't create a new image we have to maintain.

Replying to arma:

Would it be bad to just add obfsproxy to our current bridge images for amazon? Then everybody running a bridge image would be accessible as a normal bridge or as an obfsproxy bridge.

I don't think it works that way. My understanding is that when someone launches an ‘instance’ of one of our images, Amazon makes a copy of its hard disk image in their account.

Replying to rransom:

Replying to arma:

Would it be bad to just add obfsproxy to our current bridge images for amazon? Then everybody running a bridge image would be accessible as a normal bridge or as an obfsproxy bridge.

I don't think it works that way. My understanding is that when someone launches an ‘instance’ of one of our images, Amazon makes a copy of its hard disk image in their account.

Sure. Fine. So that hard disk image should include obfsproxy, and the part of the hard disk image that configures what their Tor does should include launching the obfsproxy.

(We will want to change Tor so it advertises its obfsproxy address in, say, its extrainfo desc, if we want bridgedb to be able to learn about the obfsproxy address. That's probably on somebody's roadmap already.)

Sure, happy to just update the current bridge images instead of creating additional ones. The AWS bridges already running will not change, though.

Is there anything I should know that is not described on https://www.torproject.org/projects/obfsproxy-instructions.html.en ?

Replying to runa:

Sure, happy to just update the current bridge images instead of creating additional ones. The AWS bridges already running will not change, though.

... Assuming the required packages are available in Lucid Lynx.

Building obfsproxy bridge images with Ubuntu isn't as easy as I thought it would be. We currently have more than enough obfsproxy bridge addresses, so I'm going to close with as wontfix and reopen when we do need these images.

Trac:
Resolution: N/A to wontfix
Status: new to closed

Looks like we need to include Tor version 0.2.4x-alpha to have the bridges report directly to BridgeDB. Any chance we can have 0.2.4.x-alpha Debian packages?

Trac:
Priority: normal to blocker
Resolution: wontfix to N/A
Status: closed to reopened

Tor 0.2.4.1-alpha will be out in the next day or so, with debs following shortly after.

Done, see https://blog.torproject.org/blog/obfsproxy-bridges-amazon-cloud

Trac:
Resolution: N/A to fixed
Status: reopened to closed

Set all tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

closed

mentioned in issue #5514 (closed)

mentioned in issue #6644 (closed)