Это старая версия документа!
Содержание
Open: необязательный nginx, статика и внешний HTTPS
Раздел: Эксплуатация Open.
Без nginx
NGINX_ENABLED=0: нет требований к nginx binary, worker account/group или
системному site config, нет вопроса/установки nginx. WhiteNoise остаётся fallback
при DEBUG=False. Deploy собирает единый staticfiles из assets модулей;
runtime startup не делает collectstatic и не меняет source/config permissions.
DEBUG=True не является исправлением production статики.
Включение nginx
В conf-real/bin/install.cfg указать actual значения. Пример origin ниже
подходит только если Gunicorn действительно слушает 127.0.0.1:8000.
NGINX_ENABLED=1 NGINX_USER="_nginx" NGINX_GROUP="_nginx" NGINX_SERVER_NAMES="testopen.example.org" NGINX_UPSTREAM="http://127.0.0.1:8000" NGINX_SITE_CONFIG_PATH="/etc/nginx/conf.d/opensharix.conf" NGINX_SERVICE_NAME="nginx"
Домен — явный placeholder, не адрес Testopen. Пользователь/группа должны совпадать
с реальными workers пакета ОС. Не создавать фиктивного nginx-пользователя ради
прохождения проверки и не менять global worker policy всех сайтов.
Site path ниже /etc/nginx обязан попадать в настоящий include, показанный
nginx -T. Нельзя предполагать, что выбранный conf.d/sites-enabled уже читается.
Upstream — один HTTP(S) origin, без завершающего /, пути, credentials/query.
Сверить с BIND своей установки, не брать порт другого сервиса по аналогии.
Если пакет отсутствует
Root bootstrap/activate при nginx=1 до Unix accounts/ownership/ACL предлагает
Установить nginx? [y/N]. y/да разрешает установку; Enter/n/EOF останавливают
проход без package-команд. В non-interactive или без терминала согласия нет:
администратор заранее ставит пакет либо запускает интерактивный root bootstrap.
Существующий nginx не переустанавливается. На ALT/Debian сначала apt-get update,
затем targeted install nginx; есть dnf/yum/zypper. Ошибка остаётся видимой.
Это не полный upgrade ОС. Пакет может создать штатный account и выполнить
post-install действия; helper сам не вызывает start/enable и не настраивает TLS.
Подготовка и запуск
При первом включении nginx в уже имеющейся установке нужен разовый repair, поскольку меняется группа существующей статики. Root:
cd /opt/sharix-open-webapp-base && ./bin/install.sh bootstrap --strict --use-current-checkouts --permissions=repair && ./bin/install.sh activate --strict --use-current-checkouts --permissions=check
Если assets ещё не собраны — сначала пройти deploy из основного руководства, затем activate. При отказе пакета/account/nginx -t остановиться и исправить причину, не продолжать следующую фазу. После успешного activate, проверки include и отсутствия конфликта порта, если nginx ещё не работает:
nginx -t && systemctl enable --now nginx.service
Имя сервиса заменить, если NGINX_SERVICE_NAME другое. Новый deploy login нужен
для изменённого членства в группе. Затем обычный ./bin/install.sh restart
от deploy, если приложение ещё не запущено. Последующие обновления — check.
Где конфигурация
conf/nginx/open.conf.example — tracked рекомендованный шаблон;
conf-real/nginx/open.conf — реальная редактируемая конфигурация.
Working/system paths — ссылки на conf-real. Local правки сохраняются, не
затираются новым example; foreign link/неоднозначное владение останавливает
материализацию. Перед reload проверяется nginx -t; неудачная новая ссылка
откатывается. Рендер существующего local файла не повторяется вслепую:
при смене server_name/upstream править фактический файл и проверять diff.
Статика и внешний proxy
Внутренний vhost слушает HTTP:80, location ^~ /static/ использует
alias /opt/sharix-open-webapp-base/staticfiles/; с завершающим slash.
Остальные запросы проксируются в фактический Gunicorn origin. ^~ не исправляет
права: он запрещает перехват подходящим regex location. Один STATIC_ROOT
сборки не превращается в много nginx alias из-за количества модулей.
Внешний HTTPS proxy должен ходить на внутренний nginx:80, а не обходить его
через порт приложения. Host и корректный X-Forwarded-Proto должны сохраняться;
доверять forwarded headers можно только от доверенного proxy. TLS/firewall и
global nginx policy остаются задачей администратора. Private media публичным
alias не открывается.
Collectstatic делает self-contained файлы (не symlink) с read-доступом runtime/ nginx: каталоги 2750 и файлы 0640. Nginx не получает доступ к secrets или /root. Не применять chmod 777 или рекурсивный доступ nginx ко всему проекту/conf-real.
Проверка по слоям
Подставить фактический домен и origin; пример для localhost:
curl -I -H 'Host: testopen.example.org' http://127.0.0.1:8000/ curl -I -H 'Host: testopen.example.org' http://127.0.0.1/ curl -I -H 'Host: testopen.example.org' \ http://127.0.0.1/static/sharix_admin/css/base.css
Затем проверить внешний HTTPS URL в браузере с DEBUG=False. HTML может дать штатный redirect; CSS должен дать 200 и text/css, не HTML. Картинка гигантского размера или оформленная страница 404 по asset URL не доказывают выдачу файла. 403: путь/traversal/ACL и применимый MAC; 404: collectstatic/alias/include; 502: backend/upstream/listening port и journal. Успешная статика не доказывает запуск приложения.
Проверенная реализация и границы доказательств
Сверено 2026-10-27 по опубликованному Open root
ec9bf2a
и Open config
84597d4.
Проверены исполняемые пути install.sh, install_roles.sh, install_permissions.py,
deploy_control.sh, install_nginx.sh и env/state helpers; не только сообщения Git.
Владелец подтвердил успешный запуск Open после исправлений. Установка nginx
с новым вопросом и повторная независимая проверка Testopen ещё требуют
отдельной host-приёмки. Это не объявление релиза и не подтверждение production.
Редакционный status=review относится к статье, не к наличию реализации.