Комментарии 3
Всё плохо.
опытным путём установлено, что 666 — минимально рабочий.
А нужно не опыты ставить, а понимать, как права в юниксах устроены. У меня всё и с 660 отлично работает. И вообще если разобраться в правах, то запускать uwsgi от имени root становится без надобности
chown-socket = nginx:nginx
Раз прописаны права 666, то это делать бессмысленно
uid = developer
Запускать сайт под пользователем с правами администратора — хоть и не root, но тоже так себе идея
ExecStartPost — команда, которая выполняется после запуска сервиса. В нашем случае она требуется для корректной передачи запросов от сервера nginx к uwsgi-серверу.
Опять же, если разобраться в правах, то в подобных костылях нет необходимости
socket = /tmp/uwsgi/myproject.sock
Хранить сокеты в /tmp — плохой тон, для сокетов изобрели /run
PrivateTmp=false
Как следствие предыдущего, это тоже плохой тон
mkdir -p /tmp/uwsgi
Для этого изобрели systemd-tmpfiles
cd /opt/myproject
А для этого изобрели опцию WorkingDirectory
«Development Tools» и «Development Libraries» необходимы для корректного запуска виртуальной среды.
Почему?
перезагрузим демонов командой systemctl daemon-reload
Чепуха написана
Автор, ничего личного, но в вашей статье больше вреда чем пользы. Абсолютное непонимание как работает Linux и systemd.
ExecStartPost=/usr/bin/bash -c 'setenforce 0'
1. Не пишите руководство, в котором одним из шагов — обязательный выстрел в ногу.
… source myprojectenv/bin/activate; uwsgi --ini myproject.ini'
2. Вместо WSGI есть две альтернативы которые умеют удобно работать с VirtualEnv — Nginx Unit и Gunicorn. Если очень хочется uwsgi — ключ "-H $envpath" позволяет работать с venv.
/usr/bin/bash -c 'cd /opt/myproject...
3. У задач systemd-unit можно указать WorkingDirectory (и ограниченного пользователя отличного от root)
Подготовка сервера для публикации web-app на Python