wake-up-neo.com

Uwsgi kann nicht als root ausgeführt werden, "bind (): Berechtigung verweigert"

Ich versuche, uWsgi, Django, Nginx mit diesem Dokument zu konfigurieren: http://uwsgi-docs.readthedocs.org/de/latest/tutorials/Django_and_nginx.html

Beenden Sie die Konfiguration der uwsgi.ini-Datei, und erstellen Sie einen Softlink unter /etc/uwsgi/vassals.

Fehler beim letzten Schritt: uWSGI beim Systemstart starten.

Wenn Sie diesen Befehl ausführen:

Sudo /usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data

Ich habe diesen Fehler erhalten: 

clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 3813
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)
bind(): Permission denied [core/socket.c line 227]
Tue May 27 05:29:26 2014 - [emperor] curse the uwsgi instance uwsgi.ini (pid: 1391)
Tue May 27 05:29:29 2014 - [emperor] removed uwsgi instance uwsgi.ini

Wenn ich diesen Befehl ohne Sudo ausführen, ist alles in Ordnung.

Ich habe Benutzer "kk" zur Gruppe "www-data" hinzugefügt, und hier ist der uwsgi.ini

[uwsgi]
chdir           = /home/kk/XXXXXXX
module          = wsgi
home            = /home/kk/XXXXXXX

master          = true
processes       = 10
socket          = /home/kk/XXXXXXX/mysite.sock
chmod-socket    = 666
vacuum          = true

Ich glaube, ich habe möglicherweise einen Fehler in der Dateizulassung gemacht. Hat jemand eine gute Idee? Danke.


Aktualisieren:

Das offizielle Dokument ist korrekt. Ich befolge die Schritte, um das Projekt in einem anderen neuen VPS bereitzustellen. Es ist kein Fehler aufgetreten.

22
Hunger

Ich hatte dieses Problem. Wenn Sie die Gruppe und die Benutzer-IDs nicht festlegen, wurde das Problem behoben. Ich werde dies wahrscheinlich erneut besprechen, wenn ich mehr Zeit habe, um Dateiberechtigungen für das Verzeichnis festzulegen, aber es funktioniert im Moment

/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals

EDIT Ich hatte Zeit, diese Antwort erneut zu lesen, und ich muss sagen, dass dies nicht gute Praxis ist, wenn Sie uwsgi in der Produktion ausführen.

Das Problem mit dem beschriebenen Tutorial besteht darin, dass www-data ein Benutzer ist und dass www-data Benutzer und Gruppe Zugriff auf alle Dateien haben, die auf Ihrem Server benötigt werden. insbesondere die Socket-Datei. Ersetzen Sie die entsprechenden Argumente durch Ihren Benutzer und Ihre Gruppe, und Sie sind bereit zu gehen (und lassen keine klaffenden Sicherheitslücken auf Ihrem Server zu).

Der korrekte Befehl (wenn ich der Benutzer ovangle in der Gruppe ovangle wäre) wäre also:

/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid ovangle --gid ovangle

Es ist besser, einen Benutzer zu erstellen, der über die erforderlichen Berechtigungen verfügt, um den Server erfolgreich auszuführen. Dies ist jedoch für den Leser eine Übung. 

14
ovangle

Ich weiß nicht, warum die Berechtigungen nicht funktionieren, aber ich bin auf das gleiche Problem gestoßen.

Eine schnelle Möglichkeit, dies zu beheben, besteht darin, die Sockets auf/tmp zu verschieben. (Welches ist ein ziemlich vernünftiger Ort, um Steckdosen zu halten ...)

also einfach die uwsgi config mit aktualisieren:

socket          = /tmp/mysite.sock

und die nginx-config mit:

upstream Django {
    server unix:///tmp/mysite.sock;
}

und es fängt an zu arbeiten!

9
Norling

Sie haben die Berechtigungen rückwärts ausgeführt.

uwsgi läuft als www-data.

Ihr Socket befindet sich direkt in kk zu Hause, der vermutlich dem kk-Benutzer und der kk-Gruppe gehört.

Sie haben es so gemacht, dass kk auf alles zugreifen kann, was www-data besitzt, nicht so, dass www-data auf das zugreifen kann, was kk besitzt.

Sie möchten die www-Daten zur Gruppe von kk hinzufügen. Auf diese Weise können www-Daten die Steckdose in kk zu Hause erreichen.

usermod www-data -aG kk

Bestätigen Sie mit groups www-data und Sie sollten www-data : www-data kk zurückbekommen, um anzuzeigen, dass sich www-data jetzt in der primären Gruppe von kk befindet.

Vorausgesetzt, die Basisordnerberechtigungen von kk haben jetzt mindestens '6' für die Gruppenberechtigung, damit www-data den Socket je nach Bedarf lesen und schreiben kann. Z.B. chmod 660 /home/kk/XXXXXXX/mysite.sock.

3

So habe ich die Steckdose für den sicheren Start bekommen. Laufen Sie in einer Virtualenv? Ich habe die gleiche Fehlermeldung erhalten, als ich mit meiner App an das virtualenv übergeben wurde, da in der Umgebung kein Sudo vorhanden ist. Ich musste deactivate die virtualenv dann uwsgi global installieren. Nach der Installation von uWSGI musste ich das python3-Plugin mit Sudo apt-get install uwsgi-plugin-python3 herunterladen und "plugins = python3" meiner uWSGI-INI-Datei hinzufügen. Nach all dem konnte ich uWSGI mit Sudo/root eq starten. Sudo uwsgi --ini mysite.ini.

Aus Sicherheitsgründen wird empfohlen, diese Zeilen zur INI-Datei hinzuzufügen:

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

# Plus here's the plugin I mentioned
plugins = python3

Damit diese berücksichtigt werden können, muss www-data das übergeordnete Verzeichnis besitzen, in dem die Datei mysite.sock erstellt wird, und der Befehl uwsgi muss mit Sudo gestartet werden. Wenn eine dieser Optionen deaktiviert ist, wird der Socket als Benutzer erstellt, der den Befehl uwsgi ausgeführt hat.

1
Josh White

Ich hatte auch diesen Fehler. Es stellte sich heraus, dass mein Ordner den falschen Besitzer und die falsche Gruppe hatte. Die Dateien in den Dateien waren korrekt, sodass ich sie eine Weile nicht fangen konnte.

0
Spence Wetjen

Nachdem ich das Problem gelöst hatte, mit Benutzern und Gruppen, die über die Berechtigung für die Socket-Datei verfügten, zu lösen, wurde mir klar, dass dies wahrscheinlich ein Fehler ist. 

Es ist sehr verwirrend, wenn Sie es tatsächlich im aktuellen Benutzer mit uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data ausführen können, während einmal Sudo hinzugefügt wird, erhalten Sie bind(): Permission denied-Fehler. 

Die einzige Erklärung dafür wäre, wenn Sie es ohne Sudo ausführen, irgendwie --uid www-data --gid www-data part DOES NOT funktionieren und Sie es tatsächlich mit dem aktuellen Benutzer ausführen, der über ausreichende Berechtigungen verfügt. und sobald Sudo hinzugefügt wurde, funktioniert --uid www-data --gid www-data Part wieder magisch, was dazu führt, dass www-data nicht über die erforderlichen Berechtigungen zum Binden der Socket-Datei verfügt. 

0
Shane

Ich habe eine alte Frage wiederbelebt, aber ich bin auf dieses Problem gestoßen.

Ich habe die Lösung gefunden. Ich hatte zuvor uwsgi ausgeführt, um etwas als root zu testen. Später habe ich versucht, es als www-data auszuführen. Schließlich fand ich heraus, dass der Statistik-Server eine Socket-Datei in /tmp/name.stats.sock erstellt, die sich im Besitz von root befand und daher uwsgi zum Absturz bringen würde. Ich habe das gerade entfernt und es funktioniert jetzt!

Ich hoffe, das hilft jedem, mit dem man herumstolpert.

0
clurect

Wenn Sie mit einem Webport-Socket (wie im ersten Teil der Demo) anstelle von Unix-Sockets in Ordnung sind, können Sie dies ändern.

# uwsgi.ini
socket = :8001

und das..

# mysite_nginx.conf
upstream Django {
    # server unix:///home/teewuane/uwsgi-tutorial/mysite/mysite.sock; # for a file socket
    server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}

und Sie vermeiden die Berechtigungsprobleme.

0
teewuane

Die Ursache des Problems, nach dem Sie gefragt werden, besteht darin, dass uwsgi versucht, eine Unix-Socket-Datei zu erstellen, um mit einem Webserver über das fastCGI-Protokoll in dem von Ihnen konfigurierten Verzeichnis zu interagieren./home/kk/XXXXXXX/für den Benutzer führen Sie uwsgi aus in das Verzeichnis/home/kk/XXXXXXX/

0
Cmyker