web-dev-qa-db-fra.com

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 de passerelle 502 incorrecte. La sortie d'un curl est la même, Bad Gateway html

J'ai essayé de le réparer en modifiant les autorisations pour /tmp/uwsgi.sock à 777. Cela n'a pas fonctionné. Je me suis également ajouté au www-data groupe (quelques questions qui semblaient similaires le suggéraient). De plus, pas de dés.

Voici mon nginx.conf fichier:

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 lance une application Flask avec Nginsx et Uwsgi, juste pour être plus approfondie 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 écrit personnellement mon nginx ou mon fichier uwsgi. J'ai suivi le guide ici qui met tout en place en utilisant ansible-playbook. Le nginx.conf le fichier a été généré automatiquement, mais il n'y avait rien dans /etc/uwsgi sauf un fichier README dans les deux apps-enabled et apps-available Dossiers. 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 compris ma configuration uwsgi depuis que j'exécute cette commande

uwsgi -s /tmp/uwsgi.sock -w my_app:app

il démarre et sort 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)
nginxflaskuwsgiansible-playbook
38
Alex Chumbley

Le problème d'autorisation se produit car uwsgi réinitialise la propriété et les autorisations de /tmp/uwsgi.sock à 755 et l'utilisateur exécutant uwsgi à chaque démarrage d'uwsgi.

La bonne façon de résoudre le problème est de faire en sorte que uwsgi change la propriété et/ou l'autorisation de /tmp/uwsgi.sock de telle sorte que nginx puisse écrire sur ce socket. Par conséquent, il existe trois solutions possibles.

  1. Exécutez uwsgi en tant qu'utilisateur www-data afin que cet utilisateur possède le fichier socket créé par lui.

    uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data

  2. 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

  3. 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 qu'utilisateur root. La troisième commande n'a pas besoin d'être exécutée en tant qu'utilisateur root.

La première commande laisse uwsgi en cours d'exécution en tant qu'utilisateur www-data. Les deuxième et troisième commandes laissent uwsgi s'exécuter en tant qu'utilisateur réel qui a exécuté la commande.

Les première et deuxième commandes permettent uniquement à l'utilisateur www-data d'écrire dans le socket. La troisième commande permet à tout utilisateur d'écrire dans le socket.

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.

48
Susam Pal

Bien que la solution acceptée soit vraie, SELinux pourrait également bloquer l'accès. Si vous avez correctement défini les autorisations et que vous obtenez toujours des messages d'autorisation refusée, 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, procédez comme suit:

  # 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 politique SELinux sur Enforcing avec:

Sudo setenforce Enforcing
7
enaut

Vous devez définir ces autorisations (chmod/chown) dans la configuration uWSGI.

C'est le chmod-socket et le chown-socket.

http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-sockethttp://uwsgi-docs.readthedocs.org/en/latest/ Options.html # chown-socket

2
iurisilvio

Dans mon cas, changer une autorisation php fait l'affaire

Sudo chown user:group -R /run/php

J'espère que ça aidera quelqu'un.

0
Florin

Je sais qu'il est trop tard, mais cela pourrait aider les autres. Je vous suggère de suivre Exécution flask avec virtualenv, uwsgi et nginx documentation très simple et douce.

Vous devez activer votre environnement si vous exécutez votre projet dans virtualenv.

voici le yolo.py 

from config import application

if __== "__main__":
    application.run(Host='127.0.0.1')

Et créez le fichier uwsgi.sock dans le répertoire/tmp/et laissez-le vide. Comme @susanpal a répondu: "Le problème d'autorisation se produit car uwsgi réinitialise la propriété et les autorisations de /tmp/uwsgi.sock à 755 et l'utilisateur exécute uwsgi à chaque démarrage d'uwsgi." c'est correct.

Vous devez donc autoriser le stockage du fichier à chaque démarrage d'uwsgi. 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 légèrement différente de @susanpal. Et pour connexion persistante, ajoutez simplement " & " fin de la commande

uwsgi -s /tmp/uwsgi.sock -w yolo:app -H /var/www/yolo/env --chmod-socket=666 &
0
Mitul Shah