manual setup fails

[brada]

trying the setup on debian 8.

everything appears to build/install correctly (did not notice any errors). visting the machine running the code results in this:

Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1836, in __call__
return self.wsgi_app(environ, start_response)
File "/opt/alarmdecoder-webapp/ad2web/app.py", line 94, in __call__
return self.app(environ, start_response)
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1820, in wsgi_app
response = self.make_response(self.handle_exception(e))
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1403, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1817, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1477, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1381, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1475, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1461, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/opt/alarmdecoder-webapp/ad2web/decorators.py", line 21, in decorated_function
if current_user.is_anonymous() or not current_user.is_admin():
TypeError: 'bool' object is not callable

any idea whats going on here? that line of python appears to be a valid conditional...

[kevin]

Can you post your 'pip freeze' to list all installed components and their version? Wondering if you got a newer version of the Flask packages and perhaps they changed their API or something.

[brada]

alabaster==0.7.6
alarmdecoder==0.10.0
alembic==0.8.2
async==0.6.2
Babel==2.1.1
blinker==1.4
cffi==1.2.1
chardet==2.3.0
chump==1.5.1
cryptography==1.0.2
defusedxml==0.4.1
docutils==0.12
enum34==1.0.4
Flask==0.10.1
Flask-Babel==0.9
Flask-Cache==0.13.1
Flask-Login==0.3.0
Flask-Mail==0.9.1
Flask-OpenID==1.2.5
Flask-Script==2.0.5
Flask-SQLAlchemy==2.0
Flask-Testing==0.4.2
Flask-WTF==0.12
funcsigs==0.4
gevent==1.0.2
gevent-socketio==0.3.6
gevent-websocket==0.9.5
gitdb==0.6.4
gntp==1.0.2
greenlet==0.4.9
gunicorn==19.3.0
httplib2==0.9.2
idna==2.0
ipaddress==1.0.14
itsdangerous==0.24
Jinja2==2.8
jsonpickle==0.9.2
Mako==1.0.2
MarkupSafe==0.23
mock==1.3.0
netifaces==0.10.4
nose==1.3.7
numpy==1.9.3
pbr==1.8.0
Pillow==2.6.1
psutil==3.2.1
pyasn1==0.1.9
pycparser==2.14
Pygments==2.0.1
pyOpenSSL==0.15.1
pyserial==2.7
python-apt==0.9.3.12
python-debian==0.1.27
python-debianbts==1.11
python-editor==0.4
python-openid==2.2.5
pytz==2015.6
reportbug==6.6.3
roman==2.0.0
sh==1.11
six==1.8.0
sleekxmpp==1.3.1
smmap==0.9.0
snowballstemmer==1.2.0
SOAPpy==0.12.22
speaklater==1.3
Sphinx==1.3.1
sphinx-rtd-theme==0.1.9
SQLAlchemy==1.0.8
twilio==4.6.0
Werkzeug==0.10.4
wheel==0.26.0
wstools==0.4.3
WTForms==2.0.2

[kevin]

Yeah, Flask-Login changed their API, these are now properties within that version.
Installing Flask-Login 0.2.11 instead should solve your problem! If that doesn't, compare your Flask package versions with the ones in requirements.txt and install those exact versions rather than the ">=" conditional in the requirements.txt

[brada]

cleaned up the caches and reverted to indicated versions in requirements.txt

started a reinstall after fighting with pip a bit to install pyftdi and got this:

Running setup.py bdist_wheel for distribute
Complete output from command /usr/bin/python -c "import setuptools;__file__='/tmp/pip-build-S7cT6j/distribute/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /tmp/tmpvEn3SNpip-wheel-:
usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: -c --help [cmd1 cmd2 ...]
or: -c --help-commands
or: -c cmd --help

error: invalid command 'bdist_wheel'

----------------------------------------
Failed building wheel for distribute


its continuing to run, so im going to try it out, and i thought you might like to know.

[brada]

got a little further. looks like the backend process doesnt want to start:

root@alarmmon:/etc/gunicorn.d# systemctl status gunicorn.service
â gunicorn.service - (null)
Loaded: loaded (/etc/init.d/gunicorn)
Active: failed (Result: exit-code) since Wed 2015-09-30 22:54:11 PDT; 10s ago
Process: 1002 ExecStop=/etc/init.d/gunicorn stop (code=exited, status=0/SUCCESS)
Process: 1043 ExecStart=/etc/init.d/gunicorn start (code=exited, status=1/FAILURE)

Sep 30 22:54:11 alarmmon gunicorn[1043]: self.check_call(args + gunicorn_args + self['args'], env=env)
Sep 30 22:54:11 alarmmon gunicorn[1043]: File "/usr/sbin/gunicorn-debian", line 157, in check_call
Sep 30 22:54:11 alarmmon gunicorn[1043]: subprocess.check_call(*args, **kwargs)
Sep 30 22:54:11 alarmmon gunicorn[1043]: File "/usr/lib/python2.7/subprocess.py", line 540, in check_call
Sep 30 22:54:11 alarmmon gunicorn[1043]: raise CalledProcessError(retcode, cmd)
Sep 30 22:54:11 alarmmon gunicorn[1043]: subprocess.CalledProcessError: Command '['start-stop-daemon', '--start', '--oknodo', '--quiet', '--chdir...id', '--n
Sep 30 22:54:11 alarmmon gunicorn[1043]: failed!
Sep 30 22:54:11 alarmmon systemd[1]: gunicorn.service: control process exited, code=exited status=1
Sep 30 22:54:11 alarmmon systemd[1]: Failed to start (null).
Sep 30 22:54:11 alarmmon systemd[1]: Unit gunicorn.service entered failed state.

[brada]

tried running above as both pi (created that on the system) and root. same error.

is there a specific version of gunicorn needed too?

[kevin]

In the image we ship, we use gunicorn version 19.3.0 and nginx build from source of version 1.7.4 for websocket support - will look into these other errors, have not seen them before.

bdist_wheel is in the python package 'wheel' if that helps

[brada]

i started over, in case there was cruft somewhere. deb7 this time, as its closer to raspbian.

i pinned the python module versions, and gunicorn is starting up now.

a little confused - the nginx proxy is trying to connect on 5000, but gunicorn is listening on 8000? i switched the proxy because that seemed easier. its timing out now though, maybe that wasnt the right thing to do?

[kevin]

Did you copy our gunicorn configs from the contrib directory? It should be port 5000 There are also other things in the config that are required