Сбой опции python-home при попытке настроить приложение Django / mod_wsgi в режиме демона на CentOS - PullRequest
Новая
       20

Сбой опции python-home при попытке настроить приложение Django / mod_wsgi в режиме демона на CentOS

0 голосов
/ 26 июня 2018

У меня есть приложение Django, работающее на Centos 7.5 с Apache 2.4 и mod_wsgi 4.6.4. Мне трудно заставить mod_wsgi использовать виртуальную среду, которую я хочу использовать. Я установил Python 3.6 через yum и использовал его для создания виртуальной среды. Я скомпилировал mod_wsgi из исходного кода, используя опцию with-python, чтобы указать на правильный двоичный файл Python. (Примерная) конфигурация Apache, которую я ожидал работать, но которая не работает, следующая: 

# 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>

Эта конфигурация не может найти ни один из пакетов, установленных в виртуальной среде. Извлечение sys.path показывает, что путь не содержит /path/to/venv/lib/python3.6/site-packages, как ожидалось, а скорее /lib/python3.6/site-packages (то есть системный каталог). Единственный способ запустить приложение - изменить директиву WSGIDaemonProcess на: 

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

Первая конфигурация (с использованием python-home в соответствии с рекомендациями) у меня работает на macOS 10.12 с Python 3.6 и mod_wsgi 4.5.24. Большая разница между этими двумя средами заключается в том, что SELinux включен на сервере CentOS, но audit2allow не показывает ничего, что объясняет мою проблему.

1 Ответ

0 голосов
/ 27 июня 2018

Я понял это. Я все еще не уверен, почему я не смог понять это в первый раз, но это была проблема SELinux, как и предполагалось. Проблема заключалась в том, что все в каталоге виртуальной среды должно иметь контекст httpd_sys_content_t, кроме динамически загружаемых двоичных библиотек, которым требуется httpd_sys_script_exec_t. Как только я это сделал, аргумент python-home для WSGIDaemonProcess сработал, как и ожидалось.

...