Я пытаюсь настроить приложение Django с помощью uwsgi и nginx, но все время сталкиваюсь с очень раздражающей проблемой.
log
Моя папка проекта находится в / var / www /
, принадлежит
и имеет разрешения 764
. Каждая подпапка и файл (в настоящее время) находятся под этим владельцем и этими разрешениями.
Я запускаю все на виртуальной машине Ubuntu 16.04 (управляемой моим администратором), и мой пользователь имеет доступ sudo
.
Я упустил что-то очевидное?
Обновление:
На данный момент все работает, когда другой
имеет разрешения на чтение и запись
в сокете и разрешение на чтение и выполнение
для остальной части проекта.
Итак, nginx не распознается должным образом ... Я дважды проверил, и nginx работает как пользователь www-data
, который является владельцем группы всего моего проекта и имеет права на чтение и выполнение
, как и у других
, которые теперь есть.
myproject_nginx.conf
(В дополнение к настройкам в этом файле я добавил user www -data www-data;
в /etc/nginx/nginx.conf
.)
# myproject_nginx.conf
# the upstream component nginx needs to connect to
upstream django {
server unix:///var/www/myproject/myproject.sock;
}
# configuration of the server
server {
# the port your site will be served on
listen 8000;
# the domain name it will serve for
server_name my.ip.goes.here; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 75M; # adjust to taste
# Django media
location /media {
alias /var/www/myproject/media; # your Django project's media files - amend as required
}
location /static {
alias /var/www/myproject/static; # your Django project's static files - amend as required
# Finally, send all non-media requests to the Django server.
location / {
uwsgi_pass django;
include /var/www/myproject/uwsgi_params; # the uwsgi_params file you installed
}
}
myproject_uwsgi.ini
# myproject_uwsgi.ini file
[uwsgi]
# Django-related settings
# the base directory (full path)
chdir = /var/www/myproject
# Django's wsgi file
module = myproject.wsgi
# the virtualenv (full path)
home = /var/www/myenv
# process-related settings
master = true
# maximum number of worker processes
processes = 10
# the socket (full path)
socket = /var/www/myproject/myproject.sock
# ... with appropriate permissions - may be needed
chmod-socket = 666
uid = me
gid = www-data
# clear environment on exit
vacuum = true
После нескольких часов боли я нашел решение именно этой проблемы.
Есть две проблемы: 1) права доступа к папке 2) виртуальная среда
Виртуальная среда нарушает ваши права доступа и мешает uwsgi правильно создать сокет -просто деактивируйте venv и установите django и uwsgi по всей системе. Возможно, есть способ решить эту проблему в venv, но я не знаю ни одного.
Затем установите права доступа к папке проекта django на 777 (или измените ее владельца на root).
cd в папку и запустите команду wsgi от имени пользователя root:
sudo uwsgi --socket mysite.sock --module mysite.wsgi --chmod-socket=664 --uid www-data --gid www-data
это создает mysite.sock с www-данными владельца, и я больше не получаю сообщение об отказе в разрешении.
Надеюсь, это поможет.
-edit- после некоторого дополнительного исследования я последовал этому руководству и заставил его работать как службу systemd без каких-либо из этих проблем - я полагаю, что официальное руководство принимает некоторые вещи как должное.
Я столкнулся с аналогичной проблемой, основанной на аналогичном учебнике по цифровому океану.
Мой взлом заключался в chmod a + rw mysite.sock
после запуска uwsgi.
Тем не менее, я думаю, что изменится --chmod-socket = 666 также подойдет.
Я всегда начинаю при разработке развертывания и/или тестировании, запуская что-то вроде этого:
uwsgi --socket /tmp/mysite.sock --module mysite.wsgi --chmod-socket=777
Затем, как только вы увидите, что ваш сайт работает, вы можете работать над использованием метод файла INI. Это хорошо, потому что команда для запуска вашего сервера приложений упрощена до:
uwsgi --ini mysite.ini
Джорджио Гизотти уже упомянул все это, так что ответ должен быть принят.
В этом руководстве по Использованию сокетов Unix вместо портов эта команда работала:
uwsgi --socket mysite_nginx.sock --wsgi-file test.py --chmod-socket=666