[tor-bugs] #9974 [Flashproxy]: packaging and installation scripts for facilitator

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Nov 18 15:23:33 UTC 2013


#9974: packaging and installation scripts for facilitator
-----------------------------+----------------------------
     Reporter:  infinity0    |      Owner:  dcf
         Type:  enhancement  |     Status:  needs_revision
     Priority:  normal       |  Milestone:
    Component:  Flashproxy   |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------------

Comment (by infinity0):

 Replying to [comment:12 dcf]:
 > Installation of the merge-next branch
 ([https://github.com/infinity0/flashproxy/commit/dfd80a48930b328a8410172bc74fcfdf8593428f
 dfd80a48930b328a8410172bc74fcfdf8593428f]) went pretty smoothly. Thank you
 for your work on this. I can see that you have been diligent and taken
 care of many details. I took some notes during the installation.
 >
 > I made a trivial commit on top of your merge-next branch:
 >  *
 https://gitweb.torproject.org/user/dcf/flashproxy.git/shortlog/refs/heads
 /fac-build
 >
 > I found that I couldn't follow `facilitator/INSTALL` and
 `facilitator/doc/http-howto.txt` in strict sequence. Instead, I had to
 first install Apache, then install the facilitator, then edit the Apache
 config. The reason is that running `configure` for the facilitator
 requires Apache so that the CGI directory can be inferred

 I've added instructions to install apache2 to INSTALL, which takes care of
 the install-from-source case. OTOH distros can set cgibindir manually in
 their packaging scripts, and avoid installing apache2 at build-time. We'll
 probably do something like Recommends: httpd-cgi | apache2 in the Debian
 package.

 > Commit
 [https://github.com/infinity0/flashproxy/commit/0080b8dff74c583682867eb190e49237fee3b9db
 0080b8dff74c583682867eb190e49237fee3b9db] turned Apache logging on, and
 the commit log didn't have a reason why. I disabled logging manually.
 >

 I've put /dev/null back. Sorry, this was an oversight. I think I was a bit
 too keen in "making things consistent".

 > I had copied the `reg-email.pass` file from the other facilitator. Of
 course that meant it wasn't in the proper new format. The error message
 printed the actual secret password to the screen, which it shouldn't do.
 It didn't appear to write the password to any log files that I could find.
 > {{{
 > # /etc/init.d/facilitator-email-poller start
 > Failed to parse password file "/usr/local/etc/flashproxy/reg-
 email.pass": could not find email or password: <actual password>
 > }}}
 >

 I've change this to print the line number instead.

 > I didn't find any documentation telling you to edit
 `$(sysconfdir)/default/*` to set `RUN_DAEMON=yes`. I had to do that for
 facilitator, facilitator-reg-daemon, and facilitator-email-poller.
 >

 Fixed

 > The install scripts should probably create the `$(localstatedir)/log`
 and `$(localstatedir)/run` directories. With the `--localstatedir` given
 in the instructions they probably already exist, but when I had
 `localstatedir=/usr/local/var`, I got errors:
 > {{{
 > Traceback (most recent call last):
 >   File "/usr/local/bin/facilitator-reg-daemon", line 212, in <module>
 >     main()
 >   File "/usr/local/bin/facilitator-reg-daemon", line 176, in main
 >     options.log_file = open(options.log_filename, "a")
 > IOError: [Errno 2] No such file or directory: '/usr/local/var/log
 /facilitator-reg-daemon.log'
 >
 >   File "/usr/local/bin/facilitator", line 518, in <module>
 >     main()
 >   File "/usr/local/bin/facilitator", line 499, in main
 >     f = open(options.pid_filename, "w")
 > IOError: [Errno 2] No such file or directory:
 '/usr/local/var/run/facilitator.pid'
 > }}}
 >

 I'll have to think about the best way to do this... those directories are
 more strictly the site-local admin's concern; if they are intentionally
 installing stuff there, they should have created those directories
 manually. But this is true for /var/local too, run and log don't exist by
 default there.

 > I didn't find a mention in the documentation of the need to install
 `$(sysconfdir)/flashproxy/relays` and what should go in there. I got an
 error at startup:
 > {{{
 > # /etc/init.d/facilitator start
 > Traceback (most recent call last):
 >   File "/usr/local/bin/facilitator", line 518, in <module>
 >     main()
 >   File "/usr/local/bin/facilitator", line 472, in main
 >     with open(options.relay_filename) as fp:
 > IOError: [Errno 2] No such file or directory:
 '/usr/local/etc/flashproxy/relays'
 > }}}
 >

 Fixed

 > The defaults files say:
 > {{{
 > # Uncomment this to log potentially sensitive information from your
 users.
 > # This may be useful for debugging or diagnosing functional problems,
 but
 > # should be avoided in a high-risk environment.
 > #UNSAFE_LOGGING="yes"
 > }}}
 > I don't disagree with the sentiment, and the default setting is correct.
 What's a high-risk environment? We should rather recommend it to everyone,
 even those in a trusted environment. Call it defense in depth or whatever,
 it's better not to be sitting on a pile of IP addresses.
 >

 Changed to "most other cases".

 > I got an error when I tried to start facilitator-email-poller. It looks
 like the `--email` option was not removed from the init script nor the
 `getopt` call. `FACILITATOR_EMAIL_ADDR` doesn't seem to be defined
 anywhere.
 > {{{
 > /etc/init.d/facilitator-email-poller:
 > DAEMON_ARGS="$DAEMON_ARGS --email $FACILITATOR_EMAIL_ADDR"
 >
 > # /etc/init.d/facilitator-email-poller start
 > Traceback (most recent call last):
 >   File "/usr/local/bin/facilitator-email-poller", line 169, in <module>
 >     "unsafe-logging",
 >   File "/usr/lib/python2.7/getopt.py", line 131, in gnu_getopt
 >     opts, args = do_longs(opts, args[0][2:], longopts, args[1:])
 >   File "/usr/lib/python2.7/getopt.py", line 156, in do_longs
 >     raise GetoptError('option --%s requires argument' % opt, opt)
 > getopt.GetoptError: option --email requires argument
 > }}}

 Fixed

 Replying to [comment:13 dcf]:
 > Replying to [comment:11 infinity0]:
 > > Replying to [comment:10 dcf]:
 > > >
 [https://github.com/infinity0/flashproxy/commit/aafd15b8927e0d7519152d3e88f655b571037f04
 #diff-2751e08e60a242b8ab992d77d774e405L13 Setting FP_FACILITATOR in fp-
 reg.go.] It's good to make this externally configurable. I think it's
 better, however, to make the the configurable part a whole URL, and not
 just the domain part. We should support facilitators running on different
 ports and with different base paths. Run `go fmt` after making changes to
 Go files.
 > > >
 > >
 > > I believe the existing code already supports this, since we only put
 https:// and /reg/ around FP_FACILITATOR which is just a string. (/reg/ is
 hard-coded into facilitator.cgi so I thought to leave it hard-coded here
 too.) I'll fix the docstring to mention this though, right now it just
 says "host[:port]".
 >
 > I'm actually thinking about the case where someone does
 > {{{
 >         ScriptAliasMatch ^mybasepath/(.*)
 /usr/local/bin/facilitator.cgi$1
 > }}}
 > instead of
 > {{{
 >         ScriptAliasMatch ^(.*) /usr/local/bin/facilitator.cgi$1
 > }}}
 > Then the reg path would be at /mybasepath/reg, rather than /reg. I think
 it's fine to leave the "reg" part hardcoded. I've thought about changing
 to something like this so we can serve an actual HTML page at /, with
 information about what the facilitator is. But I can easily take care of
 making the configuration a URL. [http://golang.org/pkg/net/url/#URL.Parse
 url.Parse] is what you would use to resolve a relative path against a base
 URL.

 er, I'm still slightly confused here. The current code already supports
 this - FP_FACILITATOR is just a string, which you can set to
 "myfacilitator.com/basepath" and the appengine program will just prepend
 "https://" and append "/reg/" to make
 "https://myfacilitator.com/basepath/reg/". You could parse it as a URL for
 validation, though.

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


More information about the tor-bugs mailing list