[tor-bugs] #9974 [Flashproxy]: packaging and installation scripts for facilitator
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sun Nov 17 07:46:57 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: |
-----------------------------+----------------------------
Changes (by dcf):
* status: needs_review => needs_revision
Comment:
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:
{{{
$ ./configure --enable-initscripts
...
configure: WARNING: could not determine system CGI executables dir, using
$(libexecdir); set cgibindir to override.
...
}}}
...and the Apache config file `facilitator/examples/fp-facilitator.conf`
doesn't exist until after you've done `./configure` and `make` in the
facilitator directory.
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 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 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.
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 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'
}}}
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.
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
}}}
Seeing this error made me think. I like what you did with changing the
format of the `reg-email.pass` file. Suppose we made that file a mapping
of email→password, potentially with many lines. Then put back the
`--email` and `--imap` options, which would cause the proper line to be
selected. The email address and password file path could be set in
`defaults/facilitator-email-poller`.
I was surprised that the App Engine files ended up in
`$(sysconfdir)/flashproxy`.
{{{
$ ls -l /usr/local/etc/flashproxy/reg-appspot/
total 4
lrwxrwxrwx 1 root root 58 Nov 17 06:15 app.yaml -> /usr/local/share
/flashproxy-facilitator/appengine/app.yaml
-rw-r--r-- 1 root root 137 Nov 17 06:15 config.go
lrwxrwxrwx 1 root root 59 Nov 17 06:15 fp-reg.go -> /usr/local/share
/flashproxy-facilitator/appengine/fp-reg.go
lrwxrwxrwx 1 root root 56 Nov 17 06:15 README -> /usr/local/share
/flashproxy-facilitator/appengine/README
}}}
I can kind of see why it would make sense, after all you do have to
''configure'' `config.go`. And you do want someone installing a
facilitator to have easy access to the source code. I don't think it
matches what I see as the recommended use case, though--people shouldn't
be uploading their App Engine code from the facilitator itself. That can
be done with a separate Google account whose password can be kept offline.
People are also going to want to try at least compiling the code before
uploading it, and it seems weird to be doing that in `etc`. I think it's
sufficient to install the files in `/usr/local/share` and then refer to
them in documentation.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9974#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list