Autorisation refusée-socket nginx et uwsgi

Wow, ce problème me prend presque une journée entière!

J'utilise uwsgi 2.0.14, nginx 1.10.1, django 1.10

, Pour résumer, la chose la plus importante est de s'assurer que les deux ci-dessous deux utilisateurs ont rwx permission socket fichier:

1. l'utilisateur de nginx;
2. l'utilisateur de uWSGI;

Donc, vous pouvez les vérifier un par un.

Tout d'abord, vous pouvez vérifier si le serveur web nginx a l'autorisation en actualisant l'url, disons http://192.168.201.210:8024/morning/, sans exécuter uwsgi. Si vous voyez /var/log/nginx/error.log Aucun fichier ou répertoire, comme ceci:

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"

Créez simplement un fichier nommé helloworld.sock, actualisez l'url et vérifiez à nouveau le fichier journal, si vous voyez Permission denied dans le fichier journal, comme ceci:

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"

Cela signifie que le serveur web nginx n'a pas toutes les autorisations pour lire, écrire et exécuter. Vous pouvez donc accorder l'autorisation à ce fichier:

sudo chmod 0777 helloworld.sock

Ensuite, actualisez l'url et vérifiez à nouveau le fichier journal, si vous voyez connexion refusée dans le fichier journal, comme ceci:

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"

, C'est bon signe, cela signifie que votre serveur web nginx a la permission d'utiliser helloworld.sock fichier à partir de maintenant.

Suivant pour exécuter uwsgi et vérifier si l'utilisateur de uwsgi a la permission d'utiliser helloworld.sock. Tout d'abord, supprimez le fichier helloworld.sock que nous avons créé auparavant.

Exécuter uwsgi: uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py

Si vous voyez bind (): Autorisation refusée [core / socket.ligne c 230] , cela signifie que uwsgi n'ont pas la permission de lier helloworld.sock. C'est le problème du répertoire test, le répertoire parent de helloworld.sock.

sudo chmod 0777 test/

Maintenant, vous pouvez exécuter uwsgi succès.

Mais peut - être que vous voyez encore 502 Bad Gateway, c'est terrible, je l'ai vu toute la journée. Si vous vérifiez à nouveau le fichier error.log, vous le verrez à nouveau:

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"

Qu'est-ce qui ne va pas???

Vérifiez le détail du fichier helloworld.sock, vous pouvez voir:

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

uWSGI donne automatiquement l'autorisation 755 à ce fichier.

, Vous pouvez le modifier en ajoutant --chmod-socket:

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

OK! Enfin, vous pouvez voir:

Message à emporter :

1. uwsgi_params emplacement du fichier n'est pas important;
2. depuis Mon nginx utilisateur et uwsgi Utilisateur pas même et même pas au même groupe, donc je dois donner 777 la permission de helloworld.sock et son parent dir test/;
3. Si vous mettez helloworld.sock fichier dans votre répertoire personnel, vous obtiendrez toujours Autorisation refusée .
4. Il y a deux endroits où vous devez définir le chemin du fichier socket, un dans le fichier nginx conf, pour moi c'est helloworld_nginx.conf; Un lorsque vous exécutez uwsgi.
5. Vérifiez SELinux

C'est mon fichier 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's 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;
    }
}

Sur CentOS, j'ai essayé toutes ces choses mais cela n'a toujours pas fonctionné. Enfin, j'ai trouvé cet article:

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

Pour une machine de développement, nous courons simplement:

semanage permissive -a httpd_t

, Mais pour un vrai serveur de production, je n'ai pas compris. Vous devrez peut-être essayer d'autres choses décrites dans l'article ci-dessus.

Cette question m'a rendu fou. Mon environnement est centos7 + nginx + uwsgi, en utilisant une connexion de socket unix. La réponse acceptée est géniale, il suffit d'ajouter quelques points là-dedans.

UTILISATEUR ROOT, TEST RAPIDE

Tout d'abord, désactivez selinux, puis changez chmod-socket en 666, et enfin démarrez uwsgi en utilisant root.

Comme ceci

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

AUTRE UTILISATEUR

Si vous utilisez l'autre utilisateur que vous avez créé pour démarrer uwsgi, assurez-vous que les autorisations de l'utilisateur dossier sous la dossier d'accueil sont en 755, et que le propriétaire et le groupe correspondant.

Par exemple

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

Uwsgi.ini

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

Pourquoi? Parce que parfois l'application a besoin de lire ou d'écrire dans le système de fichiers au-delà de ce qui est accessible au serveur web. Je ne veux pas changer tout un tas de propriété et d'autorisations juste pour répondre à chaque situation. Je préfère que mon application fonctionne comme moi et fasse ce qu'elle doit faire. Définir le groupe comme www-data et chmoding le socket à 664 permet à ce groupe d'y écrire, fournissant ainsi la seule fenêtre de communication nécessaire entre le serveur web et l'application.

J'ai été confronté à ce problème pendant un moment et j'ai constaté que les drapeaux uid et gid de mon fichier uwsgi.ini n'étaient pas appliqués au fichier .sock

Vous pouvez tester cela en exécutant uwsgi, puis en vérifiant les autorisations sur votre fichier .sock à l'aide de la commande linux ls -l.

La solution pour moi était d'exécuter uwsgi avec sudo:

sudo uwsgi --ini mysite_uwsgi.ini

Avec le fichier .ini contenant les drapeaux:

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

Ensuite, les autorisations sur le fichier .sock étaient correctes, et l'erreur 502 Bad Gateway enfin disparu!

J'espère que cela aide:)

Cela me prend beaucoup de temps pour trouver le problème avec les autorisations. Et le problème est avec les autorisations bien sûr. L'utilisateur par défaut est nginx. Ce que j'ai fait: dans /etc/nginx/nginx.conf modifier l'utilisateur:

user  www-data;

Ensuite, rejoignez votre utilisateur sur www-data goup:

usermod -a -G www-data yourusername

Jeu suivant uwsgi:

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

Puis redémarrez nginx:

sudo systemctl restart nginx

Et redémarrez finalement uwsgi.

Un autre grand article pour les utilisateurs CentOS:

Https://axilleas.me/en/blog/2013/selinux-policy-for-nginx-and-gitlab-unix-socket-in-fedora-19/

Bien que les réponses soient utiles concernant CentOS, le problème se trouve sous SELinux.

J'ai suivi l'article entier mais ce qui a résolu le problème je croyais où les commandes suivantes:

yum install -y policycoreutils-{python,devel}
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp
usermod -a -G user nginx
chmod g+rx /home/user/

Veuillez remplacer l'utilisateur par votre utilisateur réel pour l'octroi des autorisations. Il en va de même pour le répertoire sous chmod commande.

Vous devez décommenter

#server 127.0.0.1:8001;

Du bloc amont et de même faire les changements dans uwsgi.ini comme

socket = 127.0.0.1:8001