Re: [tor-bugs] #31834 [Circumvention]: Make obfs4 Docker image more usable

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#31834: Make obfs4 Docker image more usable
-------------------------------+-------------------------------
 Reporter:  phw                |          Owner:  phw
     Type:  defect             |         Status:  needs_review
 Priority:  Medium             |      Milestone:
Component:  Circumvention      |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:  1.1
Parent ID:  #31281             |         Points:  1
 Reviewer:  cohosh             |        Sponsor:  Sponsor30-can
-------------------------------+-------------------------------

Comment (by thymbahutymba):

 Replying to [comment:15 phw]:
 > 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.

 Actually my point is not about bridge name but how to identify in a smart
 way the name of the container and the volume connected with. I thought
 that having external config file can solve this (and others) problem. In
 this case the user can keep the configuration file separated by the
 Makefile, moreover if the user need to re-deploy the container, due to
 image update or whatever else, this make the process quite easy and faster
 than run deploy multiple time, which requires to have in mind which are
 the ports associated to that. After saying that just consider something
 like what follows.
 {{{
 # env
 BRIDGE_NAME=DockerObfs4
 BRIDGE_LIST=${BRIDGE_NAME}-{1..2}

 ${BRIDGE_NAME}-1-OR_PORT=993
 ${BRIDGE_NAME}-1-PT_PORT=143

 ${BRIDGE_NAME}-2-OR_PORT=443
 ${BRIDGE_NAME}-2-PT_PORT=25

 # Makefile
 include env

 deploy: $(shell echo ${BRIDGE_LIST})

 ${BRIDGE_NAME}-%:
     @echo ${BRIDGE_LIST}
     @[ ${$@-OR_PORT} ] || ( echo "Env var OR_PORT for $@ is not set.";
 exit 1 )
     @[ ${$@-PT_PORT} ] || ( echo "Env var PT_PORT for $@ is not set.";
 exit 1 )
     @docker run \
         ....    \
         --volume $@:/var/lib/tor \
         ....
 }}}
 Just to summarize what I think are the advantages of that:
 * Is not required to remember the configuration each time;
 * Easy to identify at which container is associate one volume;
 * No need to run multiple times {{{make deploy <SOMETHING>}}} for each
 instance that we would run that's means speedup on deployment phase.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31834#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs