Impossible d'exécuter uwsgi en tant que root, "bind (): autorisation refusée"
J'essaie de configurer uWsgi, Django, Nginx avec ce document: http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html
Terminez la configuration du fichier uwsgi.ini, créez un lien symbolique à /etc/uwsgi/vassals.
Échec à la dernière étape: Lancez le démarrage de uWSGI lorsque le système démarre.
Lorsque vous exécutez cette commande:
Sudo /usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data
J'ai eu cette erreur:
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
Si j'exécute cette commande sans Sudo, tout va bien.
J'ai ajouté l'utilisateur "kk" au groupe "www-data", et voici le 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
Je suppose que j'ai peut-être commis une erreur sur la permission du fichier. Est-ce que quelqu'un a une bonne idée? Merci.
Mettre à jour:
Le document officiel est correct, je suis les étapes pour déployer le projet dans un autre nouveau VPS, aucune erreur ne s’est produite.
J'avais ce problème. Exécuter sans définir le groupe et les identifiants d’utilisateur a résolu le problème. J'y reviendrai probablement lorsque j'aurai plus de temps pour corriger les autorisations de fichiers pour le répertoire, mais cela fonctionne pour le moment.
/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals
EDIT J'ai eu le temps de revoir cette réponse et je dois dire que c'est pas une bonne pratique pour exécuter uwsgi en production.
Le problème avec le tutoriel tel qu'il est écrit est qu'il suppose que www-data est un utilisateur et que l'utilisateur et le groupe www-data ont accès à tous les fichiers dont il a besoin sur votre serveur. en particulier le fichier de socket. Remplacez les arguments appropriés par votre utilisateur et votre groupe et vous pourrez continuer (sans laisser de faille de sécurité béante sur votre serveur).
Donc, la commande correcte (si j’étais utilisateur ovangle dans le groupe ovangle serait):
/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid ovangle --gid ovangle
Il serait préférable de créer un utilisateur disposant des autorisations spécifiques nécessaires pour exécuter le serveur avec succès, mais cela reste un exercice pour le lecteur.
Je ne sais pas pourquoi les autorisations ne fonctionnent pas, mais j'ai rencontré le même problème.
Un moyen rapide de résoudre ce problème consiste à déplacer les sockets vers/tmp! (Ce qui est un endroit assez raisonnable pour garder les prises de courant de toute façon ...)
il suffit donc de mettre à jour la configuration uwsgi avec:
socket = /tmp/mysite.sock
et le nginx-config avec:
upstream Django {
server unix:///tmp/mysite.sock;
}
et ça va commencer à fonctionner!
Vous avez fait les autorisations à l'envers.
uwsgi fonctionne en tant que www-data.
Votre socket se trouve directement dans le domicile de kk, qui appartient probablement à l'utilisateur kk et au groupe kk.
Vous avez fait en sorte que kk puisse accéder à tout ce qui appartient à www-data, mais pas à www-data pour accéder à ce que kk possède.
Vous voulez ajouter le www-data au groupe de kk. De cette façon, www-data peut atteindre le socket chez kk.
usermod www-data -aG kk
Confirmez avec groups www-data et vous devriez obtenir www-data : www-data kk en indiquant que www-data est maintenant dans le groupe principal de kk.
Désormais, les autorisations du dossier de départ de kk ont au moins '6' pour l'autorisation de groupe que www-data peut lire et écrire sur le socket si nécessaire. Par exemple. chmod 660 /home/kk/XXXXXXX/mysite.sock.
C’est ainsi que j’ai eu la prise pour démarrer en toute sécurité. Êtes-vous en cours d'exécution dans un virtualenv? J'ai reçu le même message d'erreur lorsque j'ai été transféré vers virtualenv avec mon application, car il n'y a pas de Sudo dans l'env. Je devais deactivate le virtualenv ensuite pour installer uwsgi globalement. Après avoir installé uWSGI, je devais télécharger le plug-in python3 avec Sudo apt-get install uwsgi-plugin-python3 et ajouter "plugins = python3" à mon fichier ini uWSGI. Après tout cela, j’ai pu démarrer uWSGI avec Sudo/root eq. Sudo uwsgi --ini mysite.ini.
En ce qui concerne la sécurité, il est recommandé d’ajouter ces lignes au fichier ini:
uid = www-data
gid = www-data
chmod-socket = 644
# Plus here's the plugin I mentioned
plugins = python3
Pour que ceux-ci soient respectés, www-data doit posséder le répertoire parent dans lequel le fichier mysite.sock sera créé, et la commande uwsgi doit être lancée avec Sudo. Si l'une de ces options est désactivée, le socket est créé en tant qu'utilisateur ayant exécuté la commande uwsgi.
J'ai aussi eu cette erreur. Il s'est avéré que mon dossier avait le mauvais propriétaire et groupe. Les fichiers à l'intérieur étaient corrects, donc je ne les ai pas attrapés pendant un moment.
A couru dans le même problème, après l'avoir résolu en exécutant avec des utilisateurs et des groupes disposant de suffisamment d'autorisations pour le fichier de socket, j'ai réalisé que c'était probablement un bogue.
C'est très déroutant si vous pouvez réellement l'exécuter dans l'utilisateur actuel avec uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data alors qu'une fois que Sudo est ajouté, vous obtenez une erreur bind(): Permission denied.
La seule explication possible est que vous l'exécutez sans Sudo, d'une manière ou d'une autre --uid www-data --gid www-data part NE FONCTIONNE PAS et que vous l'exécutez avec un utilisateur actuel disposant d'une autorisation suffisante; et une fois que Sudo est ajouté, --uid www-data --gid www-data part fonctionne à nouveau comme par magie, ce qui aboutit à www-data ne disposant pas de la permission suffisante pour lier le fichier de socket.
Sorte de ressusciter une vieille question, mais j'ai rencontré ce problème.
J'ai trouvé la solution. J'avais déjà exécuté uwsgi pour tester quelque chose en tant que root. Plus tard, j'ai essayé de l'exécuter en tant que www-data. Finalement, j'ai réalisé que le serveur de statistiques créait un fichier de socket en /tmp/name.stats.sock qui appartenait à root et qui planterait donc uwsgi. Je viens de supprimer ça et ça marche maintenant!
J'espère que cela aide quiconque à trébucher avec cela.
Si vous utilisez un socket de port Web (comme la première partie de la démo) au lieu de sockets unix, vous pouvez le changer.
# uwsgi.ini
socket = :8001
et ça..
# 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)
}
et vous éviterez les problèmes de permission.
Le problème que vous avez posé est que uwsgi tente de créer un fichier de socket Unix pour interagir avec un serveur Web via le protocole fastCGI dans le répertoire que vous avez configuré/home/kk/XXXXXXX/. pour l'utilisateur à partir duquel vous exécutez uwsgi dans le répertoire/home/kk/XXXXXXX/