Разрешение отклонено - сокет nginx и uwsgi

Ответ 1

Мне кажется, вам просто нужно сменить файл сокета на 666 (664 в порядке с www-данными) или удалить его и снова запустить сервер uwsgi.

В моем uwsgi.ini:

chmod-socket = 664
uid = www-data
gid = www-data

Ответ 2

Ничего себе, эта проблема требует меня почти целый день!

Я использую uwsgi 2.0.14, nginx 1.10.1, django 1.10

Подводя итог, самое главное - убедиться, что оба из ниже двух пользователей имеют rwx разрешение на socket файл:

• пользователь nginx;
• пользователь uWSGI;

Итак, вы можете проверить их по одному.

Сначала вы можете проверить, имеет ли веб-сервер nginx разрешение, обновив URL-адрес, скажем http://192.168.201.210:8024/morning/, без запуска uwsgi. Если вы видите /var/log/nginx/error.log Нет такого файла или каталога, например:

2016/10/14 16:53:49 [crit] 17099#0: *19 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

Просто создайте файл с именем helloworld.sock и снова обновите URL-адрес и проверьте файл журнала, если вы видите Permission denied в файле журнала, например:

2016/10/14 17:00:45 [crit] 17099#0: *22 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

Это означает, что веб-сервер nginx не имеет всех прав на чтение, запись и выполнение. Таким образом, вы можете предоставить разрешение на этот файл:

sudo chmod 0777 helloworld.sock

Затем обновите URL-адрес и проверьте файл журнала еще раз, если вы видите Отклонено соединение в файле журнала, например:

2016/10/14 17:09:28 [error] 17099#0: *25 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

Это хороший знак, это означает, что ваш веб-сервер nginx имеет разрешение на использование файла helloworld.sock с этого момента.

Далее выполните uWSGI и проверьте, имеет ли пользователь uWSGI разрешение использовать helloworld.sock. Во-первых, удалите файл helloworld.sock, который мы создали ранее.

Запустите uwsgi: uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py

Если вы видите bind(): Permission denied [core/socket.c строка 230], значит, uWSGI не имеет права связывать helloworld.sock. Это проблема каталога test, родительского каталога helloworld.sock.

sudo chmod 0777 test/

Теперь вы можете запустить uWSGI успешно.

Но, возможно, вы все еще видите 502 Bad Gateway, это ужасно, я видел его весь день. Если вы снова проверите файл error.log, вы увидите это снова:

2016/10/14 17:33:00 [crit] 17099#0: *28 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

Что не так???

Проверьте детали файла helloworld.sock, вы можете увидеть:

srwxr-xr-x. 1 belter mslab       0 Oct 14 17:32 helloworld.sock

uWSGI автоматически разрешает этот файл 755.

Вы можете изменить его, добавив --chmod-socket:

uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py --chmod-socket=777

OK! Наконец, вы можете увидеть:

Отнять сообщение:

• uwsgi_params расположение файла не важно;
• Поскольку мой пользователь nginx и uWSGI пользователь не одинаковый и даже не в той же группе, поэтому мне нужно предоставить 777 разрешение helloworld.sock и его родительский каталог test/;
• Если вы поместите файл helloworld.sock в свой домашний каталог, вы всегда получите Permission denied.
• Есть два места, которые необходимо установить для пути к файлу socket, один в файле конфига nginx, для меня это helloworld_nginx.conf; один, когда вы запускаете uwsgi.
• Проверить SELinux

Это мой файл helloworld_nginx.conf:

# helloworld_nginx.conf
upstream django {
    server unix:///usr/share/nginx/html/test/helloworld.sock; # for a file socket
    # server 127.0.0.1:5902; # for a web port socket (we'll use this first)
}

# configuration of the server
server {
    # the port your site will be served on
    listen      8024;
    # the domain name it will serve for
    server_name .belter-tuesday.com; # substitute your machine IP address or FQDN
    charset     utf-8;

    # max upload size
    client_max_body_size 75M;   # adjust to taste

    # Finally, send all non-media requests to the Django server.
    location /morning {
        include     uwsgi_params;
        uwsgi_pass  django;
    }
}

Ответ 3

В CentOS я пробовал все эти вещи, но все равно это не сработало. Наконец, я нашел эту статью:

https://www.nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/

Для машины разработки мы просто запускаем:

semanage permissive -a httpd_t

Но для реального сервера производства я не понял. Возможно, вам придется попробовать другие вещи, описанные в этой статье.

Ответ 4

uwsgi.ini

[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 664

Почему? Потому что иногда приложение должно читать или записывать в файловую систему за пределы того, что доступно веб-серверу. Я не хочу менять целую кучу прав и разрешений только для каждой ситуации. Я бы предпочел, чтобы мое приложение выполнялось как я, и делайте то, что нужно. Установка группы в виде www-данных и chmoding сокета на 664 позволяет этой группе писать на нее, тем самым обеспечивая единственное необходимое окно связи между веб-сервером и приложением.

Ответ 5

Я некоторое время сталкивался с этой проблемой и обнаружил, что флаги uid и gid из моего файла uwsgi.ini не применяются к файлу .sock

Вы можете проверить это, запустив uwsgi, а затем проверив разрешения в вашем файле .sock с помощью команды linux ls -l.

Решение для меня состояло в том, чтобы запустить uwsgi с помощью sudo:

sudo uwsgi --ini mysite_uwsgi.ini

с файлом .ini, содержащим флаги:

chmod-socket = 664
uid = www-data
gid = www-data

Тогда права на файл .sock были правильными, и ошибка 502 Bad Gateway наконец исчезла!

Надеюсь, что это поможет:)

Ответ 6

Этот вопрос сошел с ума. Моя среда - centos7 + nginx + uwsgi, используя соединение сокета unix. Принятый ответ является удивительным, просто добавьте там несколько точек.

ПОЛЬЗОВАТЕЛЬ ROOT, БЫСТРОЕ ИСПЫТАНИЕ

Сначала отключите selinux, затем измените chmod-socket на 666 и, наконец, запустите uwsgi с помощью root.

Подобно этому

setenforce 0 #turn off selinux
chmod-socket = 666
uwsgi --ini uwsgi.ini

ДРУГОЙ ПОЛЬЗОВАТЕЛЬ

Если вы используете другого пользователя, которого вы создали для запуска uwsgi, убедитесь, что права доступа к папке пользователя в домашней папке 755 и что владелец и группа соответствуют.

Например

chmod-socket = 666
usermod -a -G nginx webuser #add webuser to nginx group
cd /home/
chmod -R 755 webuser
chown -R webuser:webuser webuser
uwsgi --ini uwsgi.ini --gid webuser --uid webuser

Ответ 7

вам нужно раскомментировать

#server 127.0.0.1:8001;

из восходящего блока и аналогичным образом вносят изменения в uwsgi.ini как

socket = 127.0.0.1:8001