web-dev-qa-db-ger.com

Erlaubnis verweigert - Nginx und Uwsgi Socket

Nun, ich versuche gerade, meine Django-Anwendung mit Nginx und Uwsgi auszuliefern. Ich verwende derzeit eine virtuelle Umgebung, in der uwsgi installiert ist. Beim Versuch, auf die Seite zuzugreifen, wird jedoch zurzeit ein Fehler mit dem Fehler 502 angezeigt.

Den Fehler erlebe ich.

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"

Das ist meine 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
    }
}

Hier ist meine uwsgi.ini-Datei

[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

Von dem, was ich auf Google gelesen habe, ist es ein Berechtigungsproblem mit der www-data-Gruppe und dem Verzeichnis/tmp /. Ich bin jedoch neu in diesem Bereich und habe versucht, die Berechtigungsstufe des Ordners ohne Erfolg zu ändern. Könnte mich jemand in die richtige Richtung weisen? Ist das ein Berechtigungsproblem?.

Ist es in der Praxis auch üblich, die Socken-Datei im tmp-Verzeichnis abzulegen?

Vielen Dank 

40
Deep

Ich denke, Sie müssen nur Ihre Socket-Datei in 666 ändern (664 ist in Ordnung mit www-Daten), oder entfernen Sie sie und führen Sie den uwsgi-Server erneut aus.

In meiner uwsgi.ini:

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

Wow, dieses Problem dauert fast einen ganzen Tag!

Ich benutze uwsgi 2.0.14, nginx 1.10.1, Django 1.10

Zusammenfassend ist es das Wichtigste, sicherzustellen, dass beide der folgenden Benutzer über die rwx-Berechtigung für die socket-Datei verfügen:

  1. der Benutzer von nginx;
  2. der Benutzer von uWSGI;

Sie können sie also einzeln überprüfen.


Zuerst können Sie prüfen, ob der Webserver nginx über eine Berechtigung verfügt, indem Sie die URL aktualisieren, z. B. http://192.168.201.210:8024/morning/ , ohne uwsgi auszuführen. Wenn Sie /var/log/nginx/error.logKeine solche Datei oder ein solches Verzeichnis sehen, wie folgt:

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"

Erstellen Sie einfach eine Datei mit dem Namen helloworld.sock, und aktualisieren Sie die URL, und überprüfen Sie die Protokolldatei erneut, wenn Sie in der Protokolldatei Permission denied sehen:

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"

Dies bedeutet, dass der Webserver nginx nicht alle Berechtigungen zum Lesen, Schreiben und Ausführen besitzt. So können Sie dieser Datei die Berechtigung erteilen:

Sudo chmod 0777 helloworld.sock

Aktualisieren Sie dann die URL und überprüfen Sie die Protokolldatei erneut, wenn Sie in der Protokolldatei Connection abgelehnt Sehen.

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"

Dies ist ein gutes Zeichen. Dies bedeutet, dass Ihr Webserver nginx von nun an die Berechtigung hat, die helloworld.sock-Datei zu verwenden.


Klicken Sie als Nächstes auf uwsgi und prüfen Sie, ob der Benutzer von uwsgi die Berechtigung hat, helloworld.sock zu verwenden. Entfernen Sie zunächst die zuvor erstellte Datei helloworld.sock.

Führen Sie uwsgi aus: uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py

Wenn Sie bind () sehen: Berechtigung verweigert [core/socket.c-Zeile 230], bedeutet dies, dass uwsgi keine Berechtigung zum Binden von helloworld.sock hat. Dies ist das Problem des Verzeichnisses test, des übergeordneten Verzeichnisses von helloworld.sock.

Sudo chmod 0777 test/

Jetzt können Sie uwsgi erfolgreich ausführen. 

Aber vielleicht sehen Sie noch 502 Bad Gateway, es ist schrecklich, ich habe es den ganzen Tag gesehen. Wenn Sie die error.log-Datei erneut überprüfen, wird Folgendes erneut angezeigt:

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"

Was ist falsch???

Überprüfen Sie die Details der helloworld.sock-Datei. Sie können Folgendes sehen:

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

uWSGI erteilt dieser Datei 755 automatisch die Berechtigung. 

Sie können es ändern, indem Sie --chmod-socket hinzufügen:

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

OK! Zum Schluss können Sie sehen:

 successfully see the web info


Nachricht zum Mitnehmen:

  1. Der Ort der uwsgi_params-Datei ist nicht wichtig.
  2. Da mein nginx-Benutzer und uwsgi-Benutzer nicht identisch sind und auch nicht in derselben Gruppe sind, muss ich 777 die Berechtigung für helloworld.sock und sein übergeordnetes Verzeichnis test/ erteilen.
  3. Wenn Sie die helloworld.sock-Datei in Ihrem Home-Verzeichnis ablegen, erhalten Sie immer Permission denied.
  4. Es gibt zwei Stellen, an denen Sie den socket-Dateipfad einstellen müssen, einen in der Nginx-Conf-Datei. Für mich ist es helloworld_nginx.conf; eine, wenn Sie uwsgi ausführen.
  5. Überprüfen Sie SELinux 

Dies ist meine helloworld_nginx.conf-Datei:

# 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

Bei CentOS habe ich all diese Dinge ausprobiert, aber es hat immer noch nicht funktioniert. Zum Schluss habe ich diesen Artikel gefunden:

https://www.nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/

Für eine Entwicklungsmaschine führen wir einfach Folgendes aus:

semanage permissive -a httpd_t

Aber für einen echten Produktionsserver habe ich nicht herausgefunden ... Sie müssen möglicherweise andere Dinge ausprobieren, die im obigen Artikel beschrieben werden.

9
Hugh Wang

Diese Ausgabe hat mich verrückt gemacht. Meine Umgebung ist centos7 + nginx + uwsgi mit Unix-Socket-Verbindung. Die akzeptierte Antwort ist großartig, fügen Sie einfach einige Punkte hinzu.

ROOT USER, QUICK TEST

Schalten Sie zuerst selinux aus, ändern Sie dann chmod-socket auf 666 und starten Sie uwsgi schließlich mit root.

So was

setenforce 0 #turn off selinux
chmod-socket = 666
uwsgi --ini uwsgi.ini

ANDERER BENUTZER

Wenn Sie den anderen von Ihnen erstellten Benutzer zum Starten von uwsgi verwenden, stellen Sie sicher, dass die Berechtigungen des Benutzerordners unter dem Basisordner 755 sind und dass der Eigentümer und die Gruppe übereinstimmen.

Zum Beispiel

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

Ich habe mich eine Weile mit diesem Problem auseinandergesetzt und festgestellt, dass die uid- und gid-Flags meiner uwsgi.ini-Datei nicht auf die .sock-Datei angewendet wurden

Sie können dies testen, indem Sie uwsgi ausführen und dann die Berechtigungen für Ihre .sock-Datei mit dem Linux-Befehl ls -l überprüfen.

Die Lösung für mich war, uwsgi mit Sudo auszuführen:

Sudo uwsgi --ini mysite_uwsgi.ini

mit der .ini-Datei, die die Flags enthält:

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

Dann waren die Berechtigungen für die .sock-Datei korrekt und der 502 Bad Gateway-Fehler ist endgültig verschwunden!

Hoffe das hilft :)

1
gbmillard

Ich brauche viel Zeit, um das Problem mit den Berechtigungen zu finden .. und das Problem ist natürlich mit den Berechtigungen. Der Standardbenutzer ist nginx. Was ich getan habe: .__ in /etc/nginx/nginx.conf Benutzer ändern:

user  www-data;

Als nächstes fügen Sie Ihren Benutzer zur www-data-Gruppe hinzu:

usermod -a -G www-data yourusername

Nächstes Set uwsgi:

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

Und dann nginx neu starten:

Sudo systemctl restart nginx

Und endlich den uwsgi neu starten.

1
Ilko

uwsgi.ini

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

Warum? Denn manchmal muss die App außerhalb des für den Webserver zugänglichen Bereichs lesen oder schreiben. Ich möchte nicht eine ganze Reihe von Inhabern und Berechtigungen ändern, nur um jede dieser Situationen zu berücksichtigen. Ich möchte meine Anwendung lieber als mich ausführen lassen und tun, was sie tun muss. Wenn Sie die Gruppe als www-data festlegen und den Socket auf 664 ändern, kann diese Gruppe in diese Gruppe schreiben, wodurch das einzige notwendige Fenster für die Kommunikation zwischen dem Webserver und der App bereitgestellt wird.

0
Michael Ekoka

Ein weiterer toller Artikel für CentOS-Benutzer:

https://axilleas.me/de/blog/2013/selinux-policy-for-nginx-and-gitlab-unix-socket-in-Fedora-19/

Obwohl Antworten bezüglich CentOS hilfreich sind, liegt das Problem hinter SELinux.

Ich habe den gesamten Artikel verfolgt, aber was das Problem gelöst hat, glaubte ich mit den folgenden Befehlen:

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/

Ersetzen Sie den Benutzer durch Ihren tatsächlichen Benutzer für die Erteilung von Berechtigungen. Gleiches gilt für das Verzeichnis unter dem Befehl chmod.