[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]:
> 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`.
>
(Not done this yet.) With the current setup, --imap is unnecessary since
it's already in the file. However, if you wanted to read the password from
say, /etc/exim4/passwd.client, then --imap would be useful since that file
only contains SMTP address patterns. (But it also uses : as a separator
rather than space.) Is that the use-case you had in mind?
> 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.
My main aim was to reduce the work needed to set that up - simply
installing it to a readonly location where you can't edit config.go, isn't
good enough from that perspective. Installing symlinks is something that
could and should be automated
AFAICS, if nothing goes wrong, you only really need run appcfg.py once for
the upload. In this case, you can run it from the same machine as the
facilitator and give --no_cookies to appcfg.py, so that it doesn't store
authcookies to disk. So I'm not sure it's really worth the effort to run
it from a separate machine. For testing, it's probably best to run it on a
non-production server.
I've updated the docs to mention --no_cookies and testing on a separate
machine, but I could also follow-up with these options if you really want
to get rid of the /etc/ symlinks.
- install to /var/lib instead, but it makes it a bit more confusing for
the user. (mediawiki does this, symlinking to both /etc/ config files and
/usr/share program files)
- add a shell script that the user can run, to create these symlinks and
copy config.go to a directory of his choice (maybe automatically run this
on /var/lib on post-install)
- separate Debian binary package for the appengine files
- could even have a separate install script, but that's a bit overkill
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9974#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