web-dev-qa-db-fra.com

Autorisation refusée - socket nginx et uwsgi

Eh bien, je suis en train d’essayer d’obtenir mon application Django avec nginx et uwsgi. J'utilise actuellement un environnement virtuel dans lequel uwsgi est installé. Cependant, je reçois actuellement une erreur de passerelle 502 lorsque je tente d'accéder à la page.

L'erreur que je vis.

2014/02/27 14:20:48 [crit] 29947#0: *20 connect() to unix:///tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 144.136.65.176, server: domainname.com.au, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", Host: "www.domainname.com.au"

C'est mon nginx.conf

    # mysite_nginx.conf

# the upstream component nginx needs to connect to
upstream Django {
    server unix:///tmp/uwsgi.sock; # for a file socket
    #server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}

# configuration of the server
server {
    # the port your site will be served on
    listen      80;
    # the domain name it will serve for
    server_name .domainname.com.au; # 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 /home/deepc/media;  # your Django project's media files - amend as required
    }

    location /static {
        alias /home/deepc/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     /home/deepc/.virtualenvs/dcwebproj/dcweb/uwsgi_params; # the uwsgi_params file you installed
    }
}

Voici mon fichier uwsgi.ini

[uwsgi]
socket=/tmp/uwsgi.sock
chmod-socket=644
uid = www-data
gid = www-data

chdir=/home/deepc/.virtualenvs/dcwebproj/dcweb
module=dcweb.wsgi:application
pidfile=/home/deepc/.virtualenvs/dcwebproj/dcweb.pid
vacuum=true

D'après ce que j'ai lu sur Google, c'est un problème de permissions avec le groupe www-data et le répertoire/tmp /. Cependant, je suis nouveau dans ce domaine et j'ai essayé de changer le niveau de permission du dossier en vain. Quelqu'un peut-il m'indiquer la bonne direction? Est-ce un problème d'autorisations?.

Aussi, est-ce bien de mettre le fichier chaussette dans le répertoire tmp?

Merci 

djangoubuntunginxuwsgi
40
Deep

Je pense que vous avez juste besoin de changer votre fichier de socket en 666 (664 ne pose pas de problème avec www-data), ou de le supprimer et de relancer le serveur Uwsgi.

Dans mon uwsgi.ini:

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

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

En résumé, l’essentiel est de s’assurer que les deux utilisateurs inférieurs à ont le droit rwx sur le fichier socket:

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

Vous pouvez donc les vérifier un à un.

Tout d’abord, vous pouvez vérifier si le serveur Web nginx est autorisé en actualisant l’URL, par exemple http://192.168.201.210:8024/morning/ , sans exécuter uwsgi. Si vous voyez /var/log/nginx/error.logAucun fichier ou répertoire de ce type, 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 suit:

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 ne dispose pas de toutes les autorisations nécessaires pour lire, écrire et exécuter. Vous pouvez donc autoriser 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"

Ceci est un bon signe, cela signifie que votre serveur web nginx a l'autorisation d'utiliser le fichier helloworld.sock à partir de maintenant.

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

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

Si vous voyez bind (): Autorisation refusée [core/socket.c, ligne 230], cela signifie que uwsgi n’a pas l’autorisation 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 avec succès. 

Mais peut-être que vous voyez toujours 502 Bad Gateway, c'est terrible, je l'ai vu toute la journée. Si vous vérifiez à nouveau le fichier error.log, vous verrez ceci à 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 les détails du fichier helloworld.sock, vous pouvez voir:

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

uWSGI donne à ce fichier l'autorisation 755 automatiquement. 

Vous pouvez le changer en ajoutant --chmod-socket:

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

D'ACCORD! Enfin, vous pouvez voir:

 successfully see the web info

Enlever le message:

  1. L'emplacement du fichier uwsgi_params n'est pas important;
  2. Étant donné que mes utilisateurs nginx et uwsgi ne sont pas identiques et ne font pas partie du même groupe, je dois donc donner le droit 777 à helloworld.sock et à son répertoire parent test/;
  3. Si vous mettez le fichier helloworld.sock dans votre répertoire personnel, vous obtiendrez toujours Permission denied.
  4. Il y a deux endroits où vous devez définir le chemin du fichier socket, un dans le fichier nginx conf, pour moi, il s'agit de helloworld_nginx.conf; un lorsque vous exécutez uwsgi.
  5. Vérifiez SELinux 

Ceci 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;
    }
}
19
Belter

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 exécutons 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.

9
Hugh Wang

Ce problème m'a rendu fou. Mon environnement est centos7 + nginx + uwsgi, utilisant une connexion de socket unix. La réponse acceptée est géniale, il suffit d’ajouter quelques points.

UTILISATEUR RACINE, TEST RAPIDE

Commencez par désactiver selinux, puis remplacez chmod-socket par 666 et lancez enfin uwsgi avec root.

Comme ça

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 du dossier utilisateur situé sous le dossier de base sont 755 et que le propriétaire et le groupe correspondent.

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
1
noveleven

Je me suis débattu avec ce problème pendant un moment et j'ai constaté que les indicateurs 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 de lancer 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 a finalement disparu!

J'espère que cela t'aides :)

1
gbmillard

Il me faut 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 changer d'utilisateur:

user  www-data;

Ensuite, joignez votre utilisateur au groupe www-data:

usermod -a -G www-data yourusername

Prochain set uwsgi:

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

Et puis redémarrez nginx:

Sudo systemctl restart nginx

Et enfin redémarrer Uwsgi.

1
Ilko

uwsgi.ini

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

Pourquoi? Parce que parfois, l'application doit lire ou écrire sur le système de fichiers au-delà de ce qui est accessible au serveur Web. Je ne veux pas changer tout un tas de droits de propriété et d'autorisations pour s'adapter à chacune de ces situations. Je préférerais que mon application fonctionne comme moi et fasse ce qu'elle doit faire. Le paramétrage du groupe en tant que www-data et la modification du socket sur 664 permettent à ce groupe de s'y écrire, fournissant ainsi la seule fenêtre de communication nécessaire entre le serveur Web et l'application.

0
Michael Ekoka

Un autre excellent article pour les utilisateurs CentOS:

https://axilleas.me/fr/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 situe sous SELinux.

J'ai suivi l'intégralité de l'article mais ce qui a résolu le problème, je le 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/

S'il vous plaît, remplacez l'utilisateur par votre utilisateur actuel pour l'octroi des autorisations. Il en va de même pour le répertoire sous la commande chmod. 

0
Santiago M. Quintero