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
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
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
:
nginx
;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.log
Aucun 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:
Enlever le message:
uwsgi_params
n'est pas important;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/
;helloworld.sock
dans votre répertoire personnel, vous obtiendrez toujours Permission denied.socket
, un dans le fichier nginx conf, pour moi, il s'agit de helloworld_nginx.conf
; un lorsque vous exécutez uwsgi.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;
}
}
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.
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
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 :)
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.
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.
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.