Django, nginx, FastCGI - работа через сокеты unix, проблемы с разрешением

Я настроил nginx для запуска сайта django через сокет:

fastcgi_pass unix:/tmp/django.socket;

теперь я (вручную) бегу

./manage.py runfcgi socket=/tmp/django.socket

HTTP-запрос приводит к 502 неверному шлюзу, и возникает следующая ошибка:

connect () в unix: /tmp/django.socket не удалось (13: разрешение отклонено) при подключении к восходящему потоку,

какие разрешения я должен установить, чтобы иметь возможность легко перезапустить django fcgi?

У меня была именно такая проблема. Я запускал django-site на Gunicorn через сокет unix (на Fedora 19). Но nginx не запускался. Я видел файл nginx-errors.log

2014/03/15 04:25:01 [crit] 18309#0: *422 connect() to unix:/webapps/django/run/gunicorn.sock failed (13: Permission denied) while connecting to upstream

Я правильно установил права и владельцев всех файлов. В конце концов я узнал, что это связано с SElinux, и нашел решение. Вот

ОБНОВИТЬ

после первого комментария

Решение, описанное по ссылке, которую я предоставил, очень длинное. Итак, я просто копирую часть этого решения здесь -

Одно быстрое решение - отключить selinux

setenforce 0

Эта команда отключает selinux для всех программ. Чтобы разрешить nginx читать сокет unix, пока включен selinux, выполните следующую процедуру:

По умолчанию сообщения журнала SELinux записываются в /var/log/audit/audit.log через систему аудита Linux auditd. Если демон auditd не запущен, сообщения записываются в /var/log/messages. Сообщения журнала SELinux помечаются ключевым словом AVC, чтобы их можно было легко отфильтровать от других сообщений, как с grep.

Итак, greping nginx в /var/log/audit/audit.log Я нашел те относительные сообщения AVC, которые действительно указывают на отказ nginx в подключении к gitlab.socket.

type=AVC msg=audit(1377542938.307:248364): avc:  denied  { write } for  pid=2597 comm="nginx" name="gitlab.socket" dev="vda1" ino=1180273 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=sock_file
type=AVC msg=audit(1377542938.307:248364): avc:  denied  { connectto } for  pid=2597 comm="nginx" path="/home/git/gitlab/tmp/sockets/gitlab.socket" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket`

Используя инструмент под названием audit2allow, мы можем очищать сообщения AVC. Если он у вас еще не установлен, он поставляется с пакетом policycoreutils-devel.

grep nginx /var/log/audit/audit.log | audit2allow

и результат:

#============= httpd_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_t http_cache_port_t:tcp_socket name_connect;

# !!! This avc is allowed in the current policy
allow httpd_t httpd_log_t:file setattr;

#!!!! This avc is allowed in the current policy
allow httpd_t httpd_sys_content_t:sock_file write;

#!!!! This avc is allowed in the current policy
allow httpd_t initrc_t:unix_stream_socket connectto;

#!!!! This avc is allowed in the current policy
allow httpd_t user_home_dir_t:dir search;

#!!!! This avc is allowed in the current policy
allow httpd_t user_home_t:dir { search getattr };

#!!!! This avc is allowed in the current policy
allow httpd_t user_home_t:sock_file write;

#!!!! This avc is allowed in the current policy
allow httpd_t var_run_t:file { read write };

Это политики, которые следует использовать с SELinux. Обратите внимание, что user_home важен, поскольку APP_ROOT GitLab находится в / home / git /. Точно так же вы заметили политику, относящуюся к запрещенному соединению сокета: unix_stream_socket connectto.

Затем мы можем продолжить и использовать audit2allow для создания настраиваемого модуля политики, разрешающего следующие действия:

grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp`

Мы можем проверить, правильно ли загружен модуль политики, перечислив загруженные модули с помощью semodule -l.

После этого не забудьте снова включить SELinux с помощью setenforce 1.

Nginx работает под каким-то пользователем (в Debian это обычно www-data), вы можете проверить это:

ps aux | grep nginx | grep worker

Пользователь будет в первом столбце.

Этот пользователь должен иметь доступ к /tmp/django.socket для записи и чтения. Вы можете решить эту проблему, запустив django под тем же пользователем, что и nginx (например, www-data в Debian), или вам нужно добавить пользователя nginx в ту же группу, что и пользователь, под которым вы запускаете django, и сокет должен иметь разрешение на чтение и запись для группы.

Первое решение проще и (для меня) лучше.