Ich habe uwsgi und nginx so konfiguriert, dass sie über den Socket (chmod 777) funktionieren, der sich im Home-Verzeichnis des Benutzers befindet, aber nginx kann nicht auf den Socket zugreifen (13: Zugriff verweigert in error.log). Habe versucht, den Socket mit 777 chmod nach /tmp/ zu verschieben, aber dann kam die Fehlermeldung2: No such file or directory
2021/09/21 19:40:16 [crit] 68278#0: *17 connect() to unix:///tmp/my.sock failed (2: No such file or directory) while connecting to upstream, client: ***, server: ***, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///tmp/my.sock:", host: "****"
2021/09/21 20:10:16 [crit] 517#0: *1 connect() to unix:/home/***/.deploy/my.sock failed (13: Permission denied) while connecting to upstream, client: ***, server: ***, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/home/***/.deploy/my.sock:", host: "***"
PS Selinux deaktiviert
Antwort1
Bevor Sie zur Antwort kommen, sollten Sie alles daran setzen, die schlechten Sicherheitsgewohnheiten wie die Verwendung von chmod 777 oder das Deaktivieren von SELinux zu überwinden. Vielmehr sollten Sie sich umfassend mit dem UNIX-Berechtigungsmodell vertraut machen, damit Sie immer die richtigen Berechtigungen kennen. Außerdem sollten Sie Ihre Dienste so konfigurieren, dass sie mit SELinux funktionieren, um von den zusätzlichen Sicherheitsebenen zu profitieren, die es bietet.
Der Grund, warum Ihr Socket tief im Home-Verzeichnis eines Benutzers nicht funktioniert, ist, dass einElternteilDie Berechtigungen des Verzeichnisses verhindern den erforderlichen Zugriff (in diesem Fall die Suche x). Verwenden Sie , namei -l /home/***/.deploy/my.sockum die Berechtigungen aller übergeordneten Verzeichnisse auf einmal anzuzeigen und diejenigen zu korrigieren, die keine Suchberechtigung zulassen (am wahrscheinlichsten ist dies /home/***).
chmod +x /as/needed
Denken Sie auch daran, die Berechtigungen und Eigentümerschaften am Socket selbst nach Bedarf zu korrigieren.
Der Vollständigkeit halber sei erwähnt, dass Ihr Socket /tmpnicht gefunden wurde, weil nginx, das als Systemdienst ausgeführt wird, nicht auf das Systemverzeichnis zugreifen kann /tmp. Systemd startet es, PrivateTmp=truewodurch ein eindeutiges privates Verzeichnis erstellt und /tmpder Namespace von nginx auf dieses Verzeichnis festgelegt wird. Dafür sind all diese /tmp/xxx-systemd-private-fooVerzeichnisse da.