{
"id": "ShariXKnowledgeOpenOperationsNginx",
"page": "sharixopen:knowledge:operations:nginx_static",
"area": "open",
"type": "procedure",
"title": "ShariX Open: необязательный nginx, статика и внешний HTTPS",
"status": "review",
"schema_version": 1,
"relations": {
"related_to": [
"ShariXKnowledgeOpenOperationsDeploy",
"ShariXKnowledgeOpenKnowledgeOperationsRuntimehealth"
]
},
"extensions": {
"taxonomy": {
"domain": "operations",
"lifecycle": "implemented",
"parents": [
"ShariXKnowledgeOperations"
],
"terms": []
},
"glossary": []
},
"content_sha256": "338711111bfa5ebaf5009b75b928d4a8593d0dcb8ef809e0422559a98f11690f",
"schema": 1
}
====== ShariX Open: необязательный nginx, статика и внешний HTTPS ======
~~NOCACHE~~
**Раздел:** [[sharixopen:knowledge:operations:start|Эксплуатация ShariX 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'' указать реальные значения. Для стандартного TCP BIND
рекомендуется ''NGINX_UPSTREAM="auto"''; origin вычисляется из конфигурации приложения.
NGINX_ENABLED=1
NGINX_USER="_nginx"
NGINX_GROUP="_nginx"
NGINX_SERVER_NAMES="service.example.org service.example.net"
NGINX_UPSTREAM="auto"
NGINX_SITE_CONFIG_PATH="/etc/nginx/sites-enabled.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 сайт должен быть реально включён в nginx -T,
nginx должен быть persistently enabled и active: installer сам выполняет
enable при необходимости и start/reload. Синтаксически корректный файл,
который не входит в http include, активацию не завершает; новая ссылка при
ошибке откатывается. Дополнительный ручной enable/start не является обычным шагом.
Новый deploy login нужен для изменённого членства в группе. Затем под deploy:
cd /opt/sharix-open-webapp-base &&
./bin/install.sh restart --strict --use-current-checkouts --permissions=check
Этот restart проверит actual backend и локальный HTTP nginx. Он не создаёт
системный site config вместо root activate. В сообщении «run root bootstrap»
слова описывают роль/фазу: выполнять полный bin/install.sh bootstrap с флагами
выше. После разового repair дальнейшие обновления используют 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: service.example.org' http://127.0.0.1:8000/
curl -I -H 'Host: service.example.org' http://127.0.0.1/
curl -I -H 'Host: service.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. Успешная статика не доказывает
запуск приложения.
===== Auto upstream и сохранение настроек =====
Auto читает единственное корректное TCP значение BIND из корневой .env без
загрузки Django. Конкретный bind IP используется как connect address, wildcard
0.0.0.0/:: переводится в соответствующий loopback; поддерживается IPv6 в скобках.
Unix socket, несколько bind или неоднозначный файл требуют явного поддержанного
origin. Сохранённый proxy_pass обязан совпадать с разрешённым upstream; при
расхождении файл сохраняется и активация останавливается для явного решения.
Примерные SERVER_NAMES/SITE_CONFIG_PATH из install.cfg.example — подсказки при
первом добавлении ключей. Уже заданные обычные и export assignments, пустые
значения и последняя строка без newline не перекрываются defaults. Имя добавленного
ключа выводится в CLI, значение не печатается. Исправление не угадывает старые
правильные значения из уже конфликтующих дублей: сравнить private backups и
оставить по одному нужному активному назначению. Перезапись всей конфигурации
старой копией не является восстановлением трёх nginx-параметров.
===== DEBUG=False и внешний 502 =====
Изменение .env применяется после restart приложения. DEBUG=True не исправляет
неверный proxy_pass, недоступный порт или отсутствие локального nginx.
Если backend даёт 200, а внешний HTTPS даёт 502, проверить отдельно локальный
HTTP:80 и затем внешний proxy/error.log. При nginx=0 локальный порт 80 может
не слушаться; успешная source-приёмка не означает создание этого listener.
Не заменять точную диагностику повторным полным installer.
===== Актуальная source-проверка 2026-10-28 =====
Порядок сверён с опубликованным ShariX Open root
[[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/4e1fe4c13b51469b3b40c386bf4e14738a4dc5c5/bin/install.sh|4e1fe4c: install.sh]],
[[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/4e1fe4c13b51469b3b40c386bf4e14738a4dc5c5/bin/utils/installation_relocation.py|relocate]],
[[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/4e1fe4c13b51469b3b40c386bf4e14738a4dc5c5/bin/install_nginx.sh|nginx lifecycle]],
[[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/4e1fe4c13b51469b3b40c386bf4e14738a4dc5c5/bin/utils/deploy_permissions.py|проверка sudo]],
[[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/4e1fe4c13b51469b3b40c386bf4e14738a4dc5c5/bin/configure_local_configs.sh|сохранение install.cfg]]
и config ''84597d4''. Проверены тела функций и порядок вызовов,
а не только help или сообщения коммитов. Обычные команды не меняют release tags.
Код реализован; результат конкретного хоста подтверждают отдельно по runtime,
HTTP/XMPP и пользовательскому сценарию. Наличие source-check или status=review
не является приёмкой произвольной установки или внешнего HTTPS.
===== Историческая source-проверка 2026-10-27 =====
Сверено 2026-10-27 по опубликованному ShariX Open root
[[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/ec9bf2a29a460d4a05025415398b133e09fa1d79/README.md|ec9bf2a]]
и ShariX Open config
[[https://git.sharix-app.org/ShariX_Open/sharix-open-config/src/84597d42b01d5a8c84c3a8c16add77435c62c254/README.md|84597d4]].
Проверены исполняемые пути install.sh, install_roles.sh, install_permissions.py,
deploy_control.sh, install_nginx.sh и env/state helpers; не только сообщения Git.
Владелец подтвердил успешный запуск ShariX Open после исправлений. Установка nginx
с новым вопросом и повторная независимая проверка Testopen ещё требуют
отдельной host-приёмки. Это не объявление релиза и не подтверждение production.
Редакционный ''status=review'' относится к статье, не к наличию реализации.
~~SHARIX_KNOWLEDGE_RELATED~~