linux - emperor - uwsgi nginx python
No se puede ejecutar uwsgi como root, "bind(): Permiso denegado" (9)
Intento configurar uWsgi, Django, Nginx con este documento: http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html
uwsgi.ini la configuración del archivo uwsgi.ini , cree un enlace flexible en /etc/uwsgi/vassals .
Falló en el último paso: haga que se inicie uWSGI cuando se inicie el sistema .
Cuando ejecute este comando:
sudo /usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data
Tengo este error
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 ejecuto este comando sin sudo , todo está bien.
He agregado el usuario "kk" al grupo "www-data", y aquí está el 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
Supongo que tal vez cometí un error en el permiso de archivo. ¿Alguien tiene buena idea? Gracias.
Actualizar:
El documento oficial es correcto, sigo los pasos para implementar el proyecto en otro nuevo VPS, no se produjo ningún error.
Así es como conseguí que el zócalo comience de forma segura. ¿Estás ejecutando en un virtualenv? Recibí el mismo mensaje de error cuando fui enviado a virtualenv con mi aplicación, ya que no hay sudo en el env. Tuve que deactivate el virtualenv para instalar uwsgi globalmente. Después de instalar uWSGI necesitaba descargar el complemento python3 con sudo apt-get install uwsgi-plugin-python3 , y agregar "plugins = python3" a mi archivo ini uWSGI. Después de todo eso pude iniciar uWSGI con sudo / root eq. sudo uwsgi --ini mysite.ini .
En cuanto a la seguridad, se recomienda agregar estas líneas al archivo ini:
uid = www-data
gid = www-data
chmod-socket = 644
# Plus here''s the plugin I mentioned
plugins = python3
Para que estos se cumplan, www-data tiene que poseer el directorio principal donde se creará el archivo mysite.sock, y el comando uwsgi debe iniciarse con sudo. Si alguna de estas opciones está desactivada, el socket se creará como el usuario que ejecutó el comando uwsgi .
Encontré exactamente el mismo problema, luego de resolverlo ejecutando con usuarios y grupos que tienen suficiente permiso para el archivo de socket, me di cuenta de que esto probablemente es un error.
Es muy confuso si puede ejecutarlo en el usuario actual con uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data mientras que una vez que se agrega sudo , obtiene bind(): Permission denied error de bind(): Permission denied .
La única explicación para esto sería cuando lo ejecute sin sudo , de alguna manera --uid www-data --gid www-data part NO FUNCIONA y de hecho lo está ejecutando con el usuario actual que tiene suficiente permiso; y una vez que se agrega sudo , --uid www-data --gid www-data part mágicamente funciona de nuevo, lo que termina con www-data sin tener suficiente permiso para enlazar el archivo de socket.
Estaba teniendo este problema. Ejecutar sin configurar el grupo y los identificadores de usuario resolvieron el problema. Probablemente volveré a visitar esto cuando tenga más tiempo para arreglar los permisos de archivo para el directorio, pero funciona por el momento
/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals
EDITAR He tenido tiempo para revisar esta respuesta y debo decir que no es una buena práctica cuando se ejecuta uwsgi en producción.
El problema con el tutorial como está escrito es que asume que www-data es un usuario y que el usuario y grupo de www-data tiene acceso a todos los archivos que necesita en su servidor; en particular el archivo socket. Reemplace los argumentos apropiados con su usuario y grupo y estará listo (y no dejará un agujero de seguridad en su servidor).
Entonces, el comando correcto (si yo fuera usuario ovangle en grupo ovangle sería):
/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid ovangle --gid ovangle
Sería mejor crear un usuario que tenga los permisos específicos que necesita para ejecutar el servidor correctamente, pero eso queda como un ejercicio para el lector.
Hiciste los permisos al revés.
uwsgi se ejecuta como www-data.
Su socket se encuentra directamente en la página de inicio de kk, que probablemente es propiedad del usuario kk y del grupo kk.
Lo hizo para que kk pueda acceder a todo lo que posee www-data, no para que www-data pueda acceder a lo que kk posee.
Desea agregar los datos de www al grupo de kk. De esta manera, www-data puede llegar al zócalo en la casa de kk.
usermod www-data -aG kk
Confirme con los groups www-data y debería volver a www-data : www-data kk mostrando que www-data ahora está en el grupo principal de kk.
Ahora, siempre que los permisos de la carpeta de inicio de kk tengan al menos ''6'' para el permiso de grupo, www-data puede leer y escribir en el socket según sea necesario. Por ejemplo, chmod 660 /home/kk/XXXXXXX/mysite.sock .
La causa del problema sobre el que está preguntando es que uwsgi está intentando crear un archivo socket de Unix para interactuar con un servidor web a través del protocolo fastCGI en el directorio que configuró / home / kk / XXXXXXX / Debe establecer permisos de escritura para el usuario desde el que ejecuta uwsgi al directorio / home / kk / XXXXXXX /
No sé por qué los permisos no funcionan, pero me encontré con el mismo problema.
¡Una forma rápida de solucionar este problema es mover los sockets a / tmp! (Que es un lugar bastante razonable para guardar sockets de todos modos ...)
solo actualice la configuración de uwsgi con:
socket = /tmp/mysite.sock
y la nginx-config con:
upstream django {
server unix:///tmp/mysite.sock;
}
¡Y empezará a funcionar!
Resucitaba una vieja pregunta, pero me encontré con este problema.
Encontré la solución. Anteriormente había ejecutado uwsgi para probar algo como root. Más tarde intenté ejecutarlo como www-data. Finalmente, descubrí que el servidor de estadísticas /tmp/name.stats.sock un archivo de socket en /tmp/name.stats.sock Esto era propiedad de root y, por lo tanto, colapsaba uwsgi. Acabo de quitar eso y funciona ahora!
Espero que esto ayude a cualquiera que se tropiece con esto.
Si está de acuerdo con el uso de un puerto web (como la primera parte de la demostración) en lugar de los zócalos Unix, puede cambiar esto.
# uwsgi.ini
socket = :8001
y esto..
# 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)
}
y evitarás los problemas de permiso.
También tuve este error. Resultó que mi carpeta tenía el propietario y el grupo equivocado. Los archivos en el interior eran correctos, así que no lo atrapé por un tiempo.