尝试在CentOS上以守护程序模式配置Django / mod_wsgi应用程序时python-home选项失败

Question

I have a Django application running on Centos 7.5 with Apache 2.4 and mod_wsgi 4.6.4. I'm having a hard time getting mod_wsgi to use the virtual environment I want it to use. I installed Python 3.6 via yum and used it to create a virtual environment. I compiled mod_wsgi from source, using the with-python option to point it to the correct Python binary. The (approximate) Apache configuration I expected to work, but which does not work, is the following:

# Required because of some third-party packages that use the 
# simplified GIL state API
WSGIApplicationGroup %{GLOBAL}

<VirtualHost *:80>
    WSGIDaemonProcess myapp python-home=/path/to/venv python-path=/path/to/my/app
    WSGIProcessGroup myapp
    WSGIScriptAlias / /path/to/my/app/wsgi.py
</VirtualHost>

<VirtualHost *:443>
    WSGIProcessGroup myapp
    WSGIScriptAlias / /path/to/my/app/wsgi.py
</VirtualHost>

This configuration can't find any of the packages installed in the virtual environment. Dumping sys.path shows that the path doesn't contain /path/to/venv/lib/python3.6/site-packages as expected, but rather /lib/python3.6/site-packages (ie the system directory). The only way I've been able to get my app to run is by changing the WSGIDaemonProcess directive to:

WSGIDaemonProcess myapp python-path=/path/to/my/app:/path/to/venv/lib/python3.6/site-packages

The first configuration (using python-home as recommended) does work for me on macOS 10.12 with Python 3.6 and mod_wsgi 4.5.24. A big difference between the two environments is the fact that SELinux is enabled on the CentOS server, but audit2allow shows nothing that explains my issue.

Answer 1

I got it figured out. I'm still not sure why I wasn't able to figure this out the first time, but it was an SELinux issue, as suspected. The problem was that everything under the virtual environment directory needed to have the httpd_sys_content_t context, except dynamically-loaded binary libraries, which need httpd_sys_script_exec_t . Once I did that, the python-home argument to WSGIDaemonProcess worked as expected.