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

[Tor Bug Tracker & Wiki]

#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:15 infinity0]:
 > Replying to [comment:12 dcf]:
 > > 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.
 >

 Fixed, just did it the simple way in Makefile.am in install-daemon

 Replying to [comment:14 dcf]:
 > I see. The facilitator's `parse_addr_spec` really is a different kind of
 beast. For that reason, maybe we should make ''it'' the exception, with a
 different function name, rather than foisting its more complicated
 interface on the other programs that need `parse_addr_spec`. Maybe a
 separate `resolve(host, port)` function would do it. Unless I'm mistaken,
 the facilitator's weird mutant `parse_addr_spec` is the same as
 `flashproxy.util.parse_addr_spec`, with the additional step of
 parsing/name resolution.
 >
 > I see
 [https://gitweb.torproject.org/flashproxy.git/blob/813bda092193136423d27ef3c41aa1b26199ab4f:/facilitator/facilitator#l421
 only one place] with `resolve=True`, and resolution arguably isn't needed
 there. In
 [https://gitweb.torproject.org/flashproxy.git/blob/813bda092193136423d27ef3c41aa1b26199ab4f:/facilitator/facilitator#l421
 parsing client registrations], we still want to
 `socket.getaddrinfo(socket.AI_NUMERICHOST)` somehow, because we don't want
 to resolve untrusted DNS names nor give them to proxies. The
 [https://gitweb.torproject.org/flashproxy.git/blob/813bda092193136423d27ef3c41aa1b26199ab4f:/facilitator
 /facilitator-email-poller#l191 only other place] `fac.parse_addr_spec` is
 used is in flashproxy-email-poller to parse the IMAP server, and there
 it's clear we should be using plain `flashproxy.util.parse_addr_spec`
 instead.
 >
 > That's my proposal: Use good old `flashproxy.util.parse_addr_spec`
 everywhere, and in the few cases where we need to resolve the address or
 ensure that it is numeric, do that as a separate step. (The
 `parse_addr_spec`+extra step can be encapsulated in a function, of
 course.)
 >

 Fixed.

 Everything is here: https://github.com/infinity0/flashproxy/compare/merge-
 next...fac-build

 (I decided to work on top of the previous merge for a simpler diff; it
 also saves my earlier conflict resolution into the git history.)

 Things left to do are are --email as a selector into reg-email.pass and
 better handling of the appspot files, but if you're alright with it I'll
 do those after the final merge into master.

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