Opened 2 months ago

Last modified 42 minutes ago

#31834 needs_review defect

Make obfs4 Docker image more usable

Reported by: phw Owned by: phw
Priority: Medium Milestone:
Component: Circumvention Version:
Severity: Normal Keywords: docker, s30-o24a2
Cc: cohosh, phw Actual Points: 1.1
Parent ID: #31281 Points: 1
Reviewer: cohosh Sponsor: Sponsor30-can

Description (last modified by phw)

Here is some feedback we got from an operator (see this blog post for the full story):

  • Make it easier to get the bridge's fingerprint and/or bridge line. At the moment, users have to spawn a shell in the container, which is tedious.
  • Maybe provide a docker-compose file.
  • Improve our official setup instructions. These instructions were more helpful to an operator.
  • Add a note that operators can run docker logs <container> to check if it's up and running.
  • Mention concerns regarding permanence: Ideally, a container should run as long as possible.
  • Allow running a bridge on a port <1024 (as per mrphs's request in comment:2).

Child Tickets

Change History (15)

comment:1 Changed 8 weeks ago by phw

Keywords: s30-o24a2 added
Parent ID: #31281

comment:2 Changed 7 weeks ago by mrphs

It would be awesome if this docker image provided a way to run obfs4 on privileged ports as well

comment:3 Changed 6 weeks ago by phw

Description: modified (diff)

comment:4 Changed 6 weeks ago by phw

Description: modified (diff)

comment:5 in reply to:  description Changed 3 weeks ago by thymbahutymba

Replying to phw:

During these days I figure out some solutions about some problems pointed by Philipp.

  • Make it easier to get the bridge's fingerprint and/or bridge line. At the moment, users have to spawn a shell in the container, which is tedious.

For make easier get not only the fingerprint but all the log available (with docker logs CONTAINER) I added to the start-tor.sh file one more log line Log notice stdout.

  • Maybe provide a docker-compose file.

I had to make a choice between docker-compose and Makefile, I chose the Makefile. The reason that convince me in this choice was the fact that each container, that are not related each other, provides an instance of tor (they don't be part of a whole service which is the purpose of docker-compose). Using the Makefle give also others advantages like embed the build command and the config target. Just to be more clear here the Makefile that I wrote:

FLAGS=-d --restart unless-stopped --log-opt "max-size=30m"
EMAIL=
VOLUME=/var/lib/tor

.PHONY: build
build:
	docker build -t obfs4-proxy

.PHONY: deploy
deploy: DockerObfs4Proxy-1 DockerObfs4Proxy-2

DockerObfs4Proxy-%: config-%
	docker run \
		-e  "OR_PORT=${OR_PORT}" -e "PT_PORT=${PT_PORT}" -e "EMAIL=${EMAIL}" \
		-p "${OR_PORT}":"${OR_PORT}" -p "${PT_PORT}":"${PT_PORT}" \
		-v "$@-vol":"${VOLUME}" \
		--name $@ 	\
		${FLAGS} 	\
		obfs4-proxy

config-1:
	$(eval OR_PORT = 993)
	$(eval PT_PORT = 443)

config-2:
	$(eval OR_PORT = 143)
	$(eval PT_PORT = 995)

In this case can be even replaced the deploy-container.sh file also due to the fact that the user have to be able to chose the ports that he prefers.
Is worth to notice that using this approach the user can deploy as many containers as he wants just changing few things: what is required by the deploy target and adding the respective config-X target.

  • Mention concerns regarding permanence: Ideally, a container should run as long as possible.

I also added a volume for the /var/lib/tor directory keeping the seniority earned by the bridge. In that way if an update is required is easy to build the new image and deploy it.

I would also like to say that just editing the section about the torrc file in start-tor.sh there is the chance to deploy container for guard, middle and exit nodes.

Last edited 3 weeks ago by thymbahutymba (previous) (diff)

comment:6 Changed 2 days ago by phw

Description: modified (diff)

Here's a brief update with what I've managed to address so far:

Make it easier to get the bridge's fingerprint and/or bridge line. At the moment, users have to spawn a shell in the container, which is tedious.


Commit d2335c91 adds a script that determines the bridge line. Users can run it like this:

$ docker exec 9d66b756b3cc get-bridge-line
obfs4 1.2.3.4:1234 A177E491C751488E7ADA397C7E47E4B3155723BD cert=KrQlXDh826TGTSywmtRaAZkq/dLI45m3Jl/drkYeaVD1ykghcJeFjyubff6hf1ZMG7ujeA iat-mode=0


Improve our official setup instructions. These instructions were more helpful to an operator.


I improved our official instructions in commit bfe821bc.

Add a note that operators can run docker logs <container> to check if it's up and running.


Documented in commit bfe821bc and made possible in commit 1f5fd1e8.

Allow running a bridge on a port <1024 (as per mrphs's request in comment:2).


Fixed in commit aceb0c10.

comment:7 Changed 32 hours ago by phw

Description: modified (diff)

Maybe provide a docker-compose file.


thymbahutymba's comment convinced me that a Makefile is a better solution than a docker-compose file. I replaced the script deploy-container.sh with a Makefile in commit 2dce6dc7.

Mention concerns regarding permanence: Ideally, a container should run as long as possible.


I adopted thymbahutymba's idea of using a volume by adding docker's --volume argument to the Makefile.

comment:8 Changed 32 hours ago by phw

Reviewer: cohosh
Status: assignedneeds_review

This is finally ready for a review. Cecylia, could you please review the commits starting at and including d2335c91?

comment:9 Changed 32 hours ago by phw

Reminder to myself: once the changes are reviewed, we need to update our instructions and push a new image version.

comment:10 Changed 31 hours ago by cohosh

Status: needs_reviewmerge_ready

It looks really good! I like the changes that were made. I left a few comments on the commits but it's good to go as is.

comment:11 in reply to:  10 ; Changed 29 hours ago by phw

Actual Points: 1.1
Resolution: fixed
Status: merge_readyclosed

Replying to cohosh:

It looks really good! I like the changes that were made. I left a few comments on the commits but it's good to go as is.


Thanks, your comments were very helpful. I addressed your feedback in commit 543e5db2, a13b1d79, and 2bb69bd2. I also updated our setup instructions and pushed a new image tag, 0.3.

comment:12 in reply to:  11 Changed 29 hours ago by thymbahutymba

Replying to phw:

Replying to cohosh:

It looks really good! I like the changes that were made. I left a few comments on the commits but it's good to go as is.


Thanks, your comments were very helpful. I addressed your feedback in commit 543e5db2, a13b1d79, and 2bb69bd2. I also updated our setup instructions and pushed a new image tag, 0.3.

I would like to let you know about an issue in your Makefile, with that solution you can't deploy more that one container in the whole system; therefore if you would to run more the one bridge (relay in general) you can't due to limitation about the volume's name that is the same every time. Maybe, if you don't like my solution with config-X, provide a kind of env file or whatever else that keep track about the number of container deployed. I hope I was clear enough.

comment:13 in reply to:  6 Changed 29 hours ago by thymbahutymba

Replying to phw:

Make it easier to get the bridge's fingerprint and/or bridge line. At the moment, users have to spawn a shell in the container, which is tedious.


Commit d2335c91 adds a script that determines the bridge line.

Remember also that since now the directory is mapped as docker volume the path

PT_STATE=/var/lib/tor/pt_state/obfs4_bridgeline.txt

is no longer meaningful and should be replaced with something like

PT_STATE=/var/lib/docker/volumes/<VOLUME NAME>/_data/

Edit:
Nevermind, I thought the script was outside the container.

Last edited 28 hours ago by thymbahutymba (previous) (diff)

comment:14 Changed 28 hours ago by phw

Resolution: fixed
Status: closedreopened

I'm reopening this ticket, so we can make our Makefile support more than one bridge.

comment:15 Changed 42 minutes ago by phw

Status: reopenedneeds_review

Here's a patch that derives docker's volume name from the two given ports, making it possible to deploy more than one container on a machine:
https://dip.torproject.org/torproject/anti-censorship/docker-obfs4-bridge/compare/master...fix%2F31834

I know that thymbahutymba is no fan of this but I find it intuitive that each call to make deploy results in a new container being deployed. As for the volume names: I believe that thymbahutymba prefers the volume name to contain the bridge name instead of the ports. I'm fine with this too but I find it a little awkward because we'd be introducing a new constraint (unique bridge names) which don't exist in Tor.

Note: See TracTickets for help on using tickets.