Не удается запустить uwsgi как root, "bind(): Permission denied"

Ответ 1

У меня была эта проблема. Работа без установки идентификаторов группы и пользователей решила проблему. Я, вероятно, передумаю, когда у меня будет больше времени для исправления прав доступа к каталогу, но он работает на данный момент

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

ИЗМЕНИТЬ У меня было время пересмотреть этот ответ, и я должен сказать, что это не очень хорошая практика при запуске uwsgi в процессе производства.

Проблема с учебником как написано в том, что он предполагает, что www-data является пользователем и что пользователь и группа www-data имеют доступ ко всем файлам, которые ему нужны на вашем сервере; в частности файл сокета. Замените соответствующие аргументы своим пользователем и группой, и вам будет хорошо идти (и не оставит на вашем сервере пробой безопасности).

Итак, правильная команда (если бы я был пользователем ovangle в группе ovangle):

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

Было бы лучше создать пользователя, который имеет конкретные разрешения, необходимые для успешного запуска сервера, но это оставило в качестве упражнения для читателя.

Ответ 2

Я не знаю, почему разрешения не работают, но я столкнулся с той же проблемой.

Один быстрый способ исправить это - переместить сокеты в /tmp, хотя! (Это довольно разумное место для хранения сокетов в любом случае...)

просто обновите конфигурацию uwsgi с помощью

socket          = /tmp/mysite.sock

и nginx-config с:

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

и он начнет работать!

Ответ 3

Если вы согласны с использованием сокета веб-порта (например, первой части демонстрации) вместо unix-сокетов.. вы можете изменить это.

# uwsgi.ini
socket = :8001

и это..

# 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)
}

и вы избежите проблем с разрешением.

Ответ 4

Причиной проблемы, о которой вы спрашиваете, является то, что uwsgi пытается создать файл сокета unix для взаимодействия с веб-сервером по протоколу fastCGI в каталоге, который вы настроили /home/kk/XXXXXXX/ Вы должны установить права на запись для пользователя, запускающего uwsgi из каталога /home/kk/XXXXXXX/

Ответ 5

Перейдем к той же самой проблеме, после ее решения, выполнив работу с пользователями и группами, которые имеют достаточное разрешение для файла сокета, я понял, что это, вероятно, ошибка.

Это очень запутанно, если вы действительно можете запустить его у текущего пользователя с помощью uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data, а после добавления sudo вы получите ошибку bind(): Permission denied.

Единственным объяснением для этого было бы, если вы запустили его без sudo, как-то --uid www-data --gid www-data часть НЕ РАБОТАЕТ, и вы фактически запускаете его с текущим пользователем, который имеет достаточное разрешение; и один раз sudo добавлен, --uid www-data --gid www-data часть волшебным образом снова работает, а заканчивается тем, что www-data не имеет достаточного разрешения для привязки файла сокета.

Ответ 6

Вы сделали разрешения назад.

uwsgi работает как www-data.

Ваш сокет находится непосредственно в kk home, который предположительно принадлежит пользователю kk и группе kk.

Вы сделали это так, чтобы kk мог получить доступ ко всему, что принадлежит www-данным, а не к тому, что www-data может получить доступ к тому, что принадлежит kk.

Вы хотите добавить www-данные в группу kk. Таким образом, www-данные могут попасть в сокет в домашней сети kk.

usermod www-data -aG kk

Подтвердите с помощью groups www-data, и вы должны вернуться www-data : www-data kk, показывая, что www-данные теперь находятся в основной группе kk.

Теперь, если разрешения для домашней папки kk имеют как минимум "6" для разрешения группы, www-данные могут считывать и записывать в сокет при необходимости. Например. chmod 660 /home/kk/XXXXXXX/mysite.sock.