Erreur Nginx: (13: Autorisation refusée) lors de la connexion à l'amont
Je reçois cette erreur dans mon nginx-error.log
fichier:
2014/02/17 03:42:20 [crit] 5455#0: *1 connect() to unix:/tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: xx.xx.x.xxx, server: localhost, request: "GET /users HTTP/1.1", upstream: "uwsgi://unix:/tmp/uwsgi.sock:", host: "EC2.amazonaws.com"
Le navigateur affiche également une erreur 502 Bad Gateway. La sortie d'un curl
est la même, Mauvaise passerelle html
J'ai essayé de le réparer en changeant les autorisations pour /tmp/uwsgi.sock
à 777. Cela ne fonctionne pas. Je me suis également ajouté au groupe www-data
(quelques questions qui semblaient similaires l'ont suggéré). Aussi, pas de dés.
Voici mon fichier nginx.conf
:
Nginx.conf
worker_processes 1;
worker_rlimit_nofile 8192;
events {
worker_connections 3000;
}
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Je fais tourner une fiole application avec Nginsx et Uwsgi, juste pour être complet dans mon explication. Si quelqu'un a des idées, je les apprécierais vraiment.
Modifier
On m'a demandé de fournir mon fichier de configuration uwsgi. Donc, je n'ai jamais personnellement écrit mon Nginx ou mon fichier uwsgi. J'ai suivi le guide ici qui met tout en place en utilisant ansible-playbook. Le fichier nginx.conf
a été généré automatiquement, mais il n'y avait rien dans /etc/uwsgi
sauf un fichier README
dans apps-enabled
et apps-available
dossier. Dois-je créer mon propre fichier de configuration pour uwsgi? J'avais l'impression qu'ansible s'occupait de toutes ces choses.
Je crois que ansible-playbook
a compris ma configuration uwsgi depuis quand j'exécute cette commande
uwsgi -s /tmp/uwsgi.sock -w my_app:app
Il démarre et affiche ceci:
*** Starting uWSGI 2.0.1 (64bit) on [Mon Feb 17 20:03:08 2014] ***
compiled with version: 4.7.3 on 10 February 2014 18:26:16
os: Linux-3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:22:01 UTC 2014
nodename: ip-10-9-xxx-xxx
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/username/Project
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 4548
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
Python version: 2.7.5+ (default, Sep 19 2013, 13:52:09) [GCC 4.8.1]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1f60260
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1f60260 pid: 26790 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 26790, cores: 1)
5 réponses
Le problème d'autorisation se produit parce que uwsgi réinitialise la propriété et les autorisations de / tmp / uwsgi.chaussette à 755 et l'utilisateur exécutant uwsgi chaque fois que uWSGI démarre.
La bonne façon de résoudre le problème est de faire uwsgi modifier le propriétaire et/ou l'autorisation de /tmp/uwsgi.chaussette telle que nginx peut écrire sur cette socket. Par conséquent, il existe trois solutions possibles.
-
Exécutez uwsgi en tant qu'utilisateur www-data afin que cet utilisateur possède le fichier socket créé par il.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data
-
Modifiez la propriété du fichier socket afin que www-data Le possède.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data
-
Modifiez les autorisations du fichier socket, afin que www-data puisse y écrire.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chmod-socket=666
Je préfère la première approche car elle ne laisse pas uwsgi fonctionner en tant que root.
Les deux premières commandes doivent être exécutées en tant que root. La troisième commande n'a pas besoin d'être exécuté en tant qu'utilisateur root.
La première commande laisse uwsgi s'exécuter en tant que www-data utilisateur. Les deuxième et troisième commandes laissent uwsgi en cours d'exécution en tant qu'utilisateur réel qui a exécuté la commande.
La première et la deuxième commande permettent uniquement à l'utilisateur www-data d'écrire sur le socket. La troisième commande permet à un utilisateur d'écrire sur le support.
Je préfère la première approche car elle ne laisse pas uWSGI fonctionner en tant qu'utilisateur root et ne rend pas le fichier socket accessible en écriture .
Vous devez définir ces autorisations (chmod
/chown
) dans la configuration uWSGI.
, Il est le chmod-socket
et le chown-socket
.
Http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-socket http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chown-socket
Alors que la solution acceptée est true, SELinux peut également bloquer L'accès. Si vous avez correctement défini les autorisations et que vous obtenez toujours des messages refusés, essayez:
sudo setenforce Permissive
Si cela fonctionne, SELinux était en faute - ou plutôt fonctionnait comme prévu! Pour ajouter les autorisations nécessaires à nginx
Faire:
# to see what permissions are needed.
sudo grep nginx /var/log/audit/audit.log | audit2allow
# to create a nginx.pp policy file
sudo grep nginx /var/log/audit/audit.log | audit2allow -M nginx
# to apply the new policy
sudo semodule -i nginx.pp
Après cela, réinitialisez la stratégie SELinux avec:
sudo setenforce Enforcing
Je sais qu'il est trop tard, mais il pourrait aider à d'autres. Je suggère de suivre en cours d'exécution flask avec virtualenv, uwsgi et Nginx documentation très simple et douce.
Doit activer votre environnement si vous exécutez votre projet dans virtualenv.
Voici le yolo.py
from config import application
if __name__ == "__main__":
application.run(host='127.0.0.1')
Et créer uwsgi.fichier sock dans le répertoire / tmp / et laissez-le vide. Comme la réponse de @ susanpal a dit "le problème d'autorisation se produit parce que uwsgi réinitialise la propriété et les autorisations de / tmp / uwsgi.chaussette à 755 et l'utilisateur exécutant uwsgi chaque fois que uWSGI démarre."il est correct.
Donc, vous devez donner la permission de fichier sock chaque fois que uWSGI commence. alors maintenant, suivez la commande ci-dessous
uwsgi -s /tmp/uwsgi.sock -w yolo:application -H /var/www/yolo/env --chmod-socket=666
Une commande un peu différente de @ susanpal. Et pour persistent connexion, il suffit d'ajouter "&" fin de la commande
uwsgi -s /tmp/uwsgi.sock -w yolo:app -H /var/www/yolo/env --chmod-socket=666 &
Vous devez publier les fichiers de configuration nginx et uwsgi pour votre application (ceux dans/etc/nginx/ sites-enabled / et / etc / uwsgi/ - ou partout où vous les mettez).
Vérifiez généralement que vous avez une ligne similaire à la suivante dans la configuration de votre application nginx:
uwsgi_pass unix:///tmp/uwsgi.sock;
Et le même nom de socket dans votre fichier de configuration uwsgi:
socket=/tmp/uwsgi.sock