Errore Nginx: (13: Autorizzazione negata) durante la connessione a monte

Sto ottenendo questo errore nel mio file nginx-error.log :

 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" 

Il browser mostra anche un errore 502 Bad Gateway. L’output di un curl è lo stesso, Bad Gateway html

Ho provato a risolverlo modificando i permessi per /tmp/uwsgi.sock su 777. Questo non ha funzionato. Ho anche aggiunto me stesso al gruppo www-data (un paio di domande simili sembravano suggerite). Inoltre, nessun dado.

Ecco il mio file 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/*; } 

    Sto eseguendo un’applicazione Flask con Nginsx e Uwsgi, solo per essere esauriente nella mia spiegazione. Se qualcuno ha qualche idea, li apprezzerei davvero.


    MODIFICARE

    Mi è stato chiesto di fornire il mio file di configurazione uwsgi. Quindi, non ho mai scritto personalmente il mio nginx o il mio file uwsgi. Ho seguito la guida qui che imposta tutto usando il playbook ansible. Il file nginx.conf stato generato automaticamente, ma non c’era nulla in /etc/uwsgi tranne un file README in entrambe apps-available cartelle apps-enabled per apps-available . Devo creare il mio file di configurazione per uwsgi? Avevo l’impressione che ansible si prendesse cura di tutte quelle cose.

    Credo che l’ ansible-playbook capito la mia configurazione uwsgi da quando eseguo questo comando

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

    si avvia e genera questo:

     *** 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) 

    Il problema dell’authorization si verifica perché uwsgi ripristina la proprietà e le autorizzazioni di /tmp/uwsgi.sock su 755 e l’utente che esegue uwsgi ogni volta che uwsgi viene avviato.

    Il modo corretto per risolvere il problema è di rendere uwsgi modificare la proprietà e / o il permesso di /tmp/uwsgi.sock in modo che nginx possa scrivere su questo socket. Pertanto, ci sono tre possibili soluzioni.

    1. Esegui uwsgi come utente di dati www in modo che questo utente possegga il file socket creato da esso.

       uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data 
    2. Modificare la proprietà del file socket in modo che sia www-data a possederlo.

       uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data 
    3. Cambia le autorizzazioni del file socket, in modo che www-data possa scrivere su di esso.

       uwsgi -s /tmp/uwsgi.sock -w my_app:app --chmod-socket=666 

    Preferisco il primo approccio perché non lascia uwsgi in esecuzione come root.

    I primi due comandi devono essere eseguiti come utente root. Il terzo comando non ha bisogno di essere eseguito come utente root.

    Il primo comando lascia uwsgi in esecuzione come utente www-data. Il secondo e il terzo comando lasciano uwsgi in esecuzione come l’utente effettivo che ha eseguito il comando.

    Il primo e il secondo comando consentono solo all’utente www-data di scrivere sul socket. Il terzo comando consente a qualsiasi utente di scrivere sul socket.

    Preferisco il primo approccio perché non lascia uwsgi in esecuzione come utente root e non rende il file del socket scrivibile in tutto il mondo.

    Devi impostare queste autorizzazioni ( chmod / chown ) nella configurazione di uWSGI.

    È il chmod-socket e il chown-socket .

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

    Anche se la soluzione accettata è vera, SELinux potrebbe bloccare l’accesso. Se hai impostato correttamente le autorizzazioni e ricevi ancora i messaggi di authorization negati, prova:

     setenforce Permissive 

    Se funziona allora SELinux era in errore – o piuttosto stava lavorando come previsto! Per aggiungere le autorizzazioni necessarie per fare nginx :

      # 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 

    Successivamente, resetta la politica di SELinux alla forzatura con:

     sudo setenforce Enforcing 

    So che è troppo tardi, ma potrebbe essere d’aiuto per gli altri. Suggerirò di seguire la boccetta in esecuzione con virtualenv, uwsgi e nginx documentazione molto semplice e dolce.

    Devi triggersre il tuo ambiente se esegui il tuo progetto in virtualenv.

    ecco lo yolo.py

     from config import application if __name__ == "__main__": application.run(host='127.0.0.1') 

    E creare il file uwsgi.sock nella directory / tmp / e lasciarlo vuoto. Come ha risposto @susanpal “Il problema del permesso si verifica perché uwsgi ripristina la proprietà e le autorizzazioni di /tmp/uwsgi.sock a 755 e l’utente che esegue uwsgi ogni volta che uwsgi inizia.” è corretto.

    Quindi devi dare il permesso di archiviare i file ogni volta che uwsgi inizia. quindi ora segui il comando sottostante

     uwsgi -s /tmp/uwsgi.sock -w yolo:application -H /var/www/yolo/env --chmod-socket=666 

    Un piccolo comando da @susanpal. E per la connessione permanente , aggiungi semplicemente ” & ” fine del comando

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

    Dovresti pubblicare entrambi i file di configurazione di nginx e uwsgi per la tua applicazione (quelli in / etc / nginx / sites-enabled / e / etc / uwsgi / – o ovunque li metterai).

    Di solito verifica di avere una linea simile alla seguente nella configurazione dell’app nginx:

     uwsgi_pass unix:///tmp/uwsgi.sock; 

    e lo stesso nome di socket nel file di configurazione uwsgi:

     socket=/tmp/uwsgi.sock