[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9974 [Flashproxy]: packaging and installation scripts for facilitator
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs