> On 22 Dec 2017, at 4:27 pm, neilD <[email protected]> wrote:
>
> I work at a large electronics company and am trying to make some simple web
> apps on our department’s server.
>
>
>
> Server version: Apache/2.2.3
> Architecture: 64-bit
> Server MPM: Prefork
> threaded: no
> forked: yes (variable process count)
>
>
> With many previous apps hosted on it and Python versions installed, I don’t
> want to make many global changes to break existing apps. My plan was to use
> Flask with the recommended virtualenv solution. I created the virtualenv
> with python2.7 from anaconda, then pip-installed flask and mod_wsgi 4.5.22
> while venv was active.
>
> I confirmed version matching with:
>
> ldd
> /home/my-username/public_html/rrfexpire/venv/lib/python2.7/site-packages/mod_wsgi/server/mod_wsgi-py27.so
>
> which returned:
>
>
> libpython2.7.so.1.0 => /usr/local/bin/anaconda/lib/libpython2.7.so.1.0
This suggests you have install Anaconda Python in the strangest non standard
place.
If you run Anaconda Python command line and do:
import sys
print(sys.prefix)
what do you get?
I would suggest it is a bad idea to be installing the whole Anaconda Python
installation under /usr/local/bin as that path suggests.
> my rrfexpire.wsgi:
>
>
> activate_this =
> '/home/my-username/public_html/rrfexpire/venv/bin/activate_this.py'
> with open(activate_this) as file_:
> exec(file_.read(), dict(__file__=activate_this))
> import sys
> sys.path.insert(0, '/home/my-username/public_html/rrfexpire/venv')
> from rrfexpire import app as application
Shouldn't need to do activation in the WSGI script file.
> In httpd.conf, previous users have working flask apps configured as:
>
> WSGIPythonHome /usr/local/bin/anaconda3
This path looks wrong.
Presuming you the output from ldd is correct, this should be:
WSGIPythonHome /usr/local/bin/anaconda
But then, you should really disable use of mod_wsgi embedded mode altogether
and set the Python installation home directory on WSGIDaemonProcess instead.
> WSGIDaemonProcess Repeaters user=apache group=apache threads=5
> display-name=flasker
> WSGIScriptAlias /reticlerepeat /var/www/flask/repeaters/repeaters.wsgi
>
> <Directory /var/www/flask/repeaters>
> AuthType Basic
> AuthName "ProbeEng Webserver: Enter Your Tech Username and Password"
> AuthBasicProvider ldap
> AuthzLDAPAuthoritative off
> AuthLDAPURL "ldap://ldap.city.tech.com/ou=mtworkers,o=tech.com?uid";
>
> ##### Require Authentication
> #
> Require valid-user
> WSGIProcessGroup Repeaters
> WSGIApplicationGroup %{GLOBAL}
> Order deny,allow
> Allow from all
> </Directory>
>
So what you want is to start with what you have below, but very importantly,
add:
WSGIRestrictEmbedded On
outside of any VirtualHost. Best place is probably directly after LoadModule
line for mod_wsgi.
Just to be absolutely sure you are picking up correct Python shared library,
and that your ldd isn't only working because LD_LIBRARY_PATH is set in your
environment for your user (which wouldn't be set for Apache), just before the
LoadModule line, add:
LoadFile /usr/local/bin/anaconda/lib/libpython2.7.so.1.0
> For my app, I tried to contain it in a VirtualHost:
>
> VirtualHost *>
> ServerName lelrdaapps01.city.Tech.com:80
>
> ErrorLog /home/my-username/public_html/rrfexpire/error.log
> LogLevel debug
>
> WSGIDaemonProcess rrfexpire
> python-home=/home/my-username/public_html/rrfexpire/venv
> python-path=/home/my-username/public_html/rrfexpire/venv/lib/python2.7/site-packages/
> user=apache group=apache
You don't need:
user=apache group=apache
as default config will run it as whatever Apache user is anyway.
You should not need the 'path=...' option at all.
The 'python-home' option needs to be whatever 'sys.prefix' for virtual
environment is, which looks okay with what you have, but check it.
> WSGIScriptAlias /rrfexpire
> /home/my-username/public_html/rrfexpire/rrfexpire.wsgi
>
> <Directory /home/my-username/public_html/rrfexpire>
> WSGIProcessGroup rrfexpire
> WSGIApplicationGroup %{GLOBAL}
> Order allow,deny
> Allow from all
> </Directory>
> </VirtualHost>
>
> Error logs confirm my app is attempting to use Anaconda3, but it seems to
> never successfully attach the interpreter.
>
> [Thu Dec 21 19:39:54 2017] [info] mod_wsgi (pid=18998): Starting process
> 'rrfexpire' with uid=48, gid=48 and threads=15.
> [Thu Dec 21 19:39:54 2017] [info] mod_wsgi (pid=18998): Python home
> /usr/local/bin/anaconda3.
> [Thu Dec 21 19:39:54 2017] [info] mod_wsgi (pid=18998): Initializing Python.
> [Thu Dec 21 19:39:54 2017] [info] mod_wsgi (pid=19000): Python home
> /usr/local/bin/anaconda3.
> [Thu Dec 21 19:39:54 2017] [info] mod_wsgi (pid=19000): Initializing Python.
> [Thu Dec 21 19:39:54 2017] [info] mod_wsgi (pid=18997): Attach interpreter ''.
> [Thu Dec 21 19:39:54 2017] [info] mod_wsgi (pid=18996): Attach interpreter ''.
>
>
> I believe my app would work fine if it would use the interpreter and packages
> installed in the venv, but the WSGIPythonHome path above my VirtualHost is
> overriding that. I am able to get ‘Hello World’ by using the python3 syntax
> for activate_this in the rrfexpire.wsgi file. But when I call on other
> packages that I have installed in my venv, they will often not exist in the
> Anaconda3 directory, breaking my app.
>
> Are there any obvious methods I’m overlooking to set a python-home for my
> virtualenv, without breaking existing apps?
> I’m willing to fight through this, but this previous problem
> <https://groups.google.com/forum/#!searchin/modwsgi/pythonhome%7Csort:date/modwsgi/1oEuIHDiCbM/nLNL-TXTAQAJ>
> makes me afraid that this will be above my abilities.
> There are good instructions here
> <https://groups.google.com/forum/#!searchin/modwsgi/anaconda%7Csort:date/modwsgi/w6-31hnZlBo/hyQGpNQnFwAJ>
> (May 9) for using Anaconda Python with mod_wsgi, but I am afraid the first
> step of removing system-wide mod_wsgi will break existing production apps.
>
So if you are still loading the system mod_wsgi package, which is going to be
compiled for system Python and not Anaconda Python, then none of this will work.
The mod_wsgi you load must be the one that was compiled for Anaconda Python.
You cannot force mod_wsgi compiled for one Python installation/version, to use
a different Python installation/version.
If you can't stop using the system mod_wsgi package, you should use
mod_wsgi-express (start-server) to run a separate instance of Apache/mod_wsgi
for Python version you need. Then setup the main Apache to proxy requests
through to that separate instance.
Can you confirm that you are still loading the system mod_wsgi and not one you
compiled for Anaconda Python?
Graham
> Thanks, Neil
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/modwsgi
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
