Установка и обновление Open: root, deploy и runtime

Как выбрать сценарий

Руководство автономно: для Open не требуются закрытая wiki или исходники другого продукта. Пример installation root — /opt/sharix-open-webapp-base; допустим другой доступный путь. Имена Unix-пользователей и systemd namespace берутся из конфигурации, не из hostname или названия каталога.

Фаза	Кто запускает	Что происходит
`bootstrap`	root	Системные prerequisites, Unix identities/home, необходимые ACL и каталоги; полный обход только при явном repair.
`deploy`	DEPLOY_USER	Git, конфигурация, зависимости, штатные schema/migrations/seed/static; затем проверяемый restart, если не указан –no-restart.
`activate`	root	Материализация systemd/nginx и точных grants; manage.py check именно под runtime identity. Нет pip/migrate/seed и неявного старта приложения/handlers.
`restart`	DEPLOY_USER	Только зарегистрированные действия своего namespace и проверка результата; без повторной установки.
`full` / без фазы	root	Оркестрация bootstrap → deploy без restart → activate → restart от deploy. Не обычная команда личного оператора.

1. Перед первоначальным включением

Сделать штатный backup БД, media и installation-local конфигурации. Зафиксировать root, ветки/SHA, actual SYSTEMD_SERVICE_NAME, bind/port и пользователей. Не переносить namespace/секреты другой установки. Прочитать diff/status всех owners. Обновлять известные исходники через Git; уже опубликованные изменения не применять вторым патчем. Патч новой разработки пользователь размещает в /tmp, проверяет git apply –check и применяет как владелец checkout; не продолжать после ошибки. При первом переходе env storage остановить main именно этой установки, исключив одновременное веб-сохранение. Соседние сайты не останавливать.

Под root, из фактического root:

cd /opt/sharix-open-webapp-base &&
./bin/configure_local_configs.sh --sync-install-cfg

Проверить conf-real/bin/install.cfg по справочнику настроек. Sync добавляет отсутствующие параметры, не затирает заданные локальные значения. На совсем новой установке первый запуск создаёт install.cfg и останавливается для его заполнения — это ожидаемо, не окончание установки.

2. Разовая подготовка root

cd /opt/sharix-open-webapp-base &&
./bin/install.sh bootstrap --strict --use-current-checkouts --permissions=repair

Явный repair нужен при принятии старого root-owned дерева/переезде или смене nginx-группы. Он может быть долгим: обходит существующие файлы, включая Git/venv. Обычные последующие проверки не повторяют этот обход. Если требуемых checkout ещё нет, не использовать –use-current-checkouts для их получения. Для nginx=1 возможен отдельный вопрос об установке пакета — см. nginx-руководство.

При отсутствии Git identity предлагаются значения из example: ShariX Developer и info@sharix-app.org. y — добавить только недостающие поля, e — свои, Enter/N — пропустить; non-interactive не предполагает согласия. Это author metadata, не пароль Git. Настроенные значения не заменяются, root credentials не копируются. После групп/ACL выполнить новый вход: su - sharix_open_deploy для example.

3. Подготовка от deploy

Применённую разработку сначала проверить и опубликовать во всех owning repositories. Нельзя отключать source-publication guard ради dirty/unpublished source.

cd /opt/sharix-open-webapp-base &&
./bin/install.sh deploy --strict --use-current-checkouts \
  --permissions=check --deps=auto --no-restart

–use-current-checkouts исключает clone/fetch/checkout/pull: он нужен после явно подготовленного Git-среза. Он НЕ исключает dependencies, LDAP, migrations, seed, collectstatic или запись конфигурации. –no-restart также не делает проход read-only и не означает безопасную онлайн-миграцию любой схемы. На вопрос о LDAP отвечать по реальной задаче. Отказ от sync не доказывает работоспособность XMPP-аккаунтов и не исправляется бессмысленным restart.

4. Системное завершение root и запуск deploy

После успешной подготовки root:

cd /opt/sharix-open-webapp-base &&
./bin/install.sh activate --strict --use-current-checkouts --permissions=check

Activate сверяет настоящее runtime-чтение конфигов, source/Git context и запись нужных output/logs; проверка только от root/deploy этого не заменяет. Фактический activate materializes без старта приложения. Старая строка help «materialization and restart» не является указанием на автоматический запуск: канонический порядок явно заканчивается отдельным restart. Затем в новом deploy login:

cd /opt/sharix-open-webapp-base &&
./bin/install.sh restart

Запускаются main и настроенные handler modes своего namespace; отключённые не включать ради зелёного списка. При изменении каталога/units/grants снова нужен root activate. Deploy не получает произвольный root shell или общий sudo на installer/nginx/daemon-reload.

Обычное последующее обновление

У подготовленной установки, под deploy:

cd /opt/sharix-open-webapp-base &&
./bin/install.sh deploy --strict --permissions=check --deps=auto

Без prepared flag скрипт пытается обновить Git штатно. При ручном подготовленном pull/релизном срезе добавить –use-current-checkouts осознанно. Root bootstrap не нужен на каждое обновление. Команда deploy может менять schema/data; для релизов сохраняется отдельный утверждённый backup/rehearsal/update contract.

Права, зависимости и длительность

Опция	Реальная семантика
`–permissions=check`	Bounded preparation/check обязательных путей; это не исключительно read-only, но и не рекурсивный chown всего дерева.
`–permissions=repair`	Явный root-only repair существующих файлов; не повседневный deploy.
`–deps=auto`	Переиспользование только подтверждённой среды по manifests/Python/package state и pip check; иначе штатная установка.
`–deps=check`	Проверить запись/дрейф; ничего не устанавливать.
`–deps=install`	Явная constrained pip-транзакция без очистки venv.
`–deps=rebuild`	Пересоздать venv только после остановки main и handlers данной установки; чужие сервисы не трогать.

После mv старый venv не считается переносимым. Проверка без установки: python3 bin/utils/venv_paths.py –project .. Не пересоздавать уже исправный venv повторно из-за старой ошибки валидатора. START/DONE/FAILED и периодический WAIT показывают фазу; WAIT не доказывает прогресс I/O. Не запускать второй installer и не удалять lock ради обхода активного процесса. Не включать общий shell xtrace.

Проверка результата

Из deploy login, после успешного запуска:

./venv/bin/python manage.py check
./bin/check_acceptance.sh --with-runtime-audit

Проверить main journal, действительный listening port, HTML и CSS с DEBUG=False, реальный вход и нужный бизнес-сценарий, функциональную health обработчиков/XMPP. systemctl active не заменяет эту проверку. При отказе restart читать причину и повторять только ./bin/install.sh restart, не весь migrate/seed/pip цикл. См. диагностику, nginx/статику и перенос установки.

Проверенная реализация и границы доказательств

Сверено 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 относится к статье, не к наличию реализации.

Содержание