Erlaubnis verweigert - Nginx und Uwsgi-Buchse
Frage
Nun, ich versuche derzeit, meine Django-Anwendung mit Nginx und Uwsgi zu erhalten.Ich verwende derzeit eine virtuelle Umgebung, auf die UWSGI installiert ist.Ich bekomme momentan einen 502-fehlerhaften Gateway-Fehler, wenn Sie versuchen, auf die Seite zuzugreifen.
Der Fehler, den ich erlebe.
generasacodicetagpre.Dies ist meine nginx.conf
generasacodicetagpre.Hier ist meine uwsgi.ini-Datei
generasacodicetagpre.Von dem, was ich bei Google gelesen habe, ist ein Berechtigungsproblem mit der WWW-Datengruppe und / tmp / mit dem Verzeichnis.Ich bin jedoch neu darauf und habe versucht, die Berechtigungsstufe des Ordners ohne Erfolg zu wechseln.Könnte mich jemand in die richtige Richtung zeigen?Ist das ein Problem von Berechtigungen.
ist es auch in Ordnung, die Sockendatei in TMP-Verzeichnis zu setzen?
danke
Lösung
Ich denke, Sie müssen nur Ihre Socket-Datei auf 666 ändern (664 ist in OK mit www-Daten) oder entfernen Sie ihn erneut und führen Sie den UWSGI-Server erneut aus.
in meinem uwsgi.ini:
generasacodicetagpre.Andere Tipps
Wow, this problem takes me almost a whole day!
I use uwsgi 2.0.14, nginx 1.10.1, django 1.10
To sum up, the most important thing is to make sure both of below two users have rwx
permission to socket
file:
- the user of
nginx
; - the user of
uWSGI
;
So, you can check them one by one.
First you can check if the web server nginx
has permission by refreshing the url, say http://192.168.201.210:8024/morning/, without running uwsgi. If you see /var/log/nginx/error.log
No such file or directory, like this:
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"
Just create a file named helloworld.sock
, and refresh the url and check log file again, if you see Permission denied in log file, like this:
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"
It means web server nginx
does not have all permission to read, write and execute. So you can grant permission to this file:
sudo chmod 0777 helloworld.sock
Then, refresh the url and check log file again, if you see Connection refused in log file, like this:
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"
This is a good sign, it means your web server nginx
has the permission to use helloworld.sock
file from now on.
Next to run uwsgi
and check if the user of uwsgi
has permission to use helloworld.sock
. Firstly, remove the file helloworld.sock
we have created before.
Run uwsgi: uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py
If you see bind(): Permission denied [core/socket.c line 230], it means uwsgi
don't have permission to bind helloworld.sock
. This is the problem of the directory test
, the parent directory of helloworld.sock
.
sudo chmod 0777 test/
Now, you can run uwsgi
successful.
But maybe you still see 502 Bad Gateway, it's terrible, I have seen it all day. If you check error.log
file again, you will see this again:
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"
What's wrong???
Check the detail of helloworld.sock
file, you can see:
srwxr-xr-x. 1 belter mslab 0 Oct 14 17:32 helloworld.sock
uWSGI
gives this file 755
permission automatically.
You can change it by adding --chmod-socket
:
uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py --chmod-socket=777
OK! Finally, you can see:
Take away message:
uwsgi_params
file's location is not important;- Since my
nginx
user anduwsgi
user not same and even not at the same group, so I need to give777
permission tohelloworld.sock
and its parent dirtest/
; - If you put
helloworld.sock
file in your home directory, you'll always get Permission denied. - There are two places you need to set the
socket
file path, one in nginx conf file, for me it ishelloworld_nginx.conf
; one when you run uwsgi. - Check SELinux
This is my helloworld_nginx.conf
file:
# 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;
}
}
On CentOS, I tried all those things but still it did not work. Finally, I found this article:
https://www.nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/
For a development machine, we simply run:
semanage permissive -a httpd_t
But for a real production server, I have not figured out. You may need to try other things described in the above article.
This is take me a lot of time to find the problem with permissions.
And the problem is with permissions of course.
Default user is nginx.
What i did:
in /etc/nginx/nginx.conf
change user:
user www-data;
Next join your user to www-data goup:
usermod -a -G www-data yourusername
Next set uwsgi:
[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 660
And then restart nginx:
sudo systemctl restart nginx
And finaly restart uwsgi.
I grappled with this problem for a while, and found that the uid
and gid
flags from my uwsgi.ini
file were not being applied to the .sock
file
You can test this by running uwsgi, then checking the permissions on your .sock
file using the linux command ls -l
.
The solution for me was to run uwsgi
with sudo:
sudo uwsgi --ini mysite_uwsgi.ini
with the .ini
file containing the flags:
chmod-socket = 664
uid = www-data
gid = www-data
Then the permissions on the .sock
file were correct, and the 502 Bad Gateway
error finally vanished!
Hope this helps :)
This issue made me crazy. My environment is centos7+nginx+uwsgi, using unix socket connection. The accepted answer is awesome, just add some points in there.
ROOT USER, QUICK TEST
First, turn off selinux, then change chmod-socket to 666, and finally start uwsgi using root.
Like this
setenforce 0 #turn off selinux
chmod-socket = 666
uwsgi --ini uwsgi.ini
OTHER USER
If you use the other user you created to start uwsgi, make sure that the permissions of the user folder under the home folder are 755, and that the owner and the group are corresponding.
For example
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
uwsgi.ini
[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 664
Why? Because sometimes the app needs to read or write to the file system beyond what's accessible to the web server. I don't want to change a whole bunch of ownership and permissions just to accommodate each such situation. I'd rather have my application run as me and do what it needs to do. Setting the group as www-data and chmoding the socket to 664 allows for that group to write to it, thus providing the only necessary window of communication between the web server and the app.
Another great article for CentOS users:
https://axilleas.me/en/blog/2013/selinux-policy-for-nginx-and-gitlab-unix-socket-in-fedora-19/
Although answers are useful regarding CentOS the problem lies beneath SELinux.
I followed the entire article but what solved the issue I believed where the following commands:
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/
Please substitute user with your actual user for granting permissions. Same applies for the directory under chmod command.
you need to uncomment
#server 127.0.0.1:8001;
from upstream block and similarly do the changes in uwsgi.ini as
socket = 127.0.0.1:8001