ShariX Open Docs

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
<sharix-knowledge-meta>
{
    "id": "ShariXKnowledgeOpenOperationsInstallationMigration",
    "page": "sharixopen:knowledge:operations:installation_migration",
    "area": "open",
    "type": "procedure",
    "title": "ShariX Open: перенос из /root в /opt и переход на nginx",
    "status": "review",
    "schema_version": 1,
    "relations": {
        "related_to": [
            "ShariXKnowledgeOpenOperationsDeploy",
            "ShariXKnowledgeOpenOperationsNginx",
            "ShariXKnowledgeOpenKnowledgeOperationsConfiguration"
        ]
    },
    "extensions": {
        "taxonomy": {
            "domain": "operations",
            "lifecycle": "implemented",
            "parents": [
                "ShariXKnowledgeOperations"
            ],
            "terms": []
        },
        "glossary": []
    },
    "content_sha256": "b36caee30e1bb8f1fc2087b08cccb2f0f86b62429d981b24956ba1b10c3eb716",
    "schema": 1
}
</sharix-knowledge-meta>
====== ShariX Open: перенос из /root в /opt и переход на nginx ======
~~NOCACHE~~

**Раздел:** [[sharixopen:knowledge:operations:start|Эксплуатация ShariX Open]].
Связанные инструкции: [[sharixopen:knowledge:operations:deploy|роли и фазы]],
[[sharixopen:knowledge:operations:nginx_static|nginx и статика]],
[[sharixopen:knowledge:operations:configuration|локальные настройки]].

===== Область сценария =====
Это разовая maintenance-процедура существующей установки ShariX Open. Она
перемещает всё дерево из ''/root/sharix-open-webapp-base'' в
''/opt/sharix-open-webapp-base'', исправляет принадлежащие ему ссылки, переводит
работу на deploy/runtime и включает необязательный локальный nginx.
Другой путь допустим; в командах нужно последовательно использовать его.
Пример не задаёт hostname, namespace, BIND или роли по имени каталога.

Подтвердить наличие актуального штатного backup БД, media и конфигурации;
уже сделанную пригодную копию БД не требуется повторять из-за самого ''mv''.
Назначить окно остановки. Соседние установки и production этим сценарием не
останавливаются. ''conf'', ''conf-real'', ''webservice_running'' и другие
independent nested Git repositories перемещаются целиком, даже если родитель
показывает их как ignored. Они содержат код и настройки, а не только ссылки.
Общий runtime обработчиков принадлежит ''handlers_backend''; не создавать
отдельный runtime для этой установки.

===== 1. Проверить и обновить код до переноса =====
Под root, пока исходные ссылки ещё работают:
<code bash>
cd /root/sharix-open-webapp-base
pwd
git status --short --branch
git -c core.pager=cat log -1 --oneline
ls -ld conf conf-real
ls -l .env bin/install.cfg
grep -E '^[[:space:]]*(BIND|SYSTEMD_SERVICE_NAME)[[:space:]]*=' .env
</code>
В вывод не отправлять полную ''.env'' или токены. Проверить изменения и
миграции каждого владельца. Корректные локальные migration files сохранить в
истории соответствующей ветки до обновления; не удалять их ради clean status.
Если конфигурация или код отличаются от upstream, сначала разобраться с diff.
Не делать reset/recovery вслепую и не сливать исторические baselines разных тем.

Для чистого root checkout на ''master'' с origin нужного проекта:
<code bash>
git -c core.pager=cat pull --ff-only origin master &&
./bin/repositories.sh pull &&
./bin/install.sh --help
</code>
Если фактическая корневая ветка другая, выбирать её осознанно; пример не
переключает её автоматически. Helper обновляет установленные независимые
checkout по их configured branches. Локальный branding deployment branch
не заменяется основной темой. Требуется актуальный режим ''relocate'' в help.
Если обновление остановилось, перенос не продолжать.

===== 2. Остановить только эту установку и выполнить mv =====
Ниже namespace читает штатный helper, без запуска Django и старого venv.
Работать в одной root-сессии; новый каталог обязан отсутствовать, включая
сломанную ссылку на его месте:
<code bash>
cd /root/sharix-open-webapp-base &&
source bin/utils/runtime_update.sh &&
SX_SERVICE="$(sharix_runtime_validate_installation_identity "$PWD/.env")" &&
systemctl stop "$SX_SERVICE.service" "$SX_SERVICE-handler@*.service" &&
test ! -e /opt/sharix-open-webapp-base &&
test ! -L /opt/sharix-open-webapp-base &&
mv -- /root/sharix-open-webapp-base /opt/sharix-open-webapp-base &&
cd /opt/sharix-open-webapp-base
</code>
Glob заключён в кавычки: instances ищет systemctl. Не останавливать глобальные
''handler@*'' без доказательства владельца. Если сохранились работающие legacy
units этой установки, ''relocate'' обнаружит их и остановит план; сначала
проверить принадлежность, затем остановить адресно. Старого дерева после mv нет
и для дальнейших действий оно не требуется.

===== 3. Восстановить ссылки штатным relocate =====
Запускается из нового пути **до** bootstrap и загрузки dangling install.cfg:
<code bash>
./bin/install.sh relocate --from=/root/sharix-open-webapp-base
</code>
Это preview: проверить namespace, old/new root и перечисленные пути. После
успешной проверки плана:
<code bash>
./bin/install.sh relocate --from=/root/sharix-open-webapp-base --apply &&
./bin/configure_local_configs.sh --sync-install-cfg
</code>
Скрипт проверяет остановку и ownership, исправляет точные old-root links
root/module/handler configs, effective units/drop-ins, template, instance links
и их ''.wants''/''.requires''. Regular installation-owned unit переносится в
''conf-real'' с сохранением custom directives. Стабильные systemd links
сохраняются; чужие или конфликтующие определения не присваиваются по имени.
Создаётся приватная копия изменяемого, выполняется daemon-reload.

''relocate'' не переименовывает ''SYSTEMD_SERVICE_NAME'', не меняет BIND,
домены, пароли, Git URLs/branches, не восстанавливает venv, не делает migrations,
не запускает сервисы и не обновляет код. Исторические backup/migration-legacy
могут законно содержать старый root. Массовый sed по всему дереву запрещён.
Конфликт старых/новых физических env или active legacy/namespaced units
требует сравнения и явного решения, а не копирования example поверх.

===== 4. Настроить роли и nginx =====
Проверить фактический ''conf-real/bin/install.cfg''. Пример имён для одной
установки; существующие корректные имена сохраняются:
<code bash>
DEPLOY_USER="sharix_open_deploy"
DEPLOY_GROUP="sharix_open_deploy"
RUNTIME_USER="sharix_open"
RUNTIME_GROUP="sharix_open"
DEPLOY_HOME=""
DEPLOY_OPERATORS_GROUP=""
DEPLOY_JOURNAL_ACCESS=1
NGINX_ENABLED=1
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"
</code>
Домены example заменить реальными, допустимыми в ''ALLOWED_HOSTS'' этой
установки. Site path должен попадать в настоящий http include nginx; ALT и
другие дистрибутивы могут использовать разные каталоги. Worker user/group
в ''NGINX_USER''/''NGINX_GROUP'' должны существовать у пакета ОС. Не создавать
фиктивного worker и не менять глобального пользователя всех сайтов.
''auto'' вычисляет origin из фактического ''.env'' ''BIND'', а не предполагает
''127.0.0.1:8000''. В файле оставить одно нужное активное назначение ключа.
Existing values, ''export KEY=value'', comments и пустые настройки не заменяются
defaults. Если до исправления уже появились конфликтующие дубли, сравнить
backup и исправить только нужные параметры; не восстанавливать весь старый cfg
поверх актуальных URL/branches.

Runtime имеет locked account, ''/nonexistent'' и Bash без создаваемого home.
Deploy имеет отдельный home, Bash, Git identity и prompt с текущим каталогом.
Пустой ''DEPLOY_HOME'' означает ''/home/$DEPLOY_USER'', а не ''/opt'' или root
проекта. Operators group — имя Unix-группы; по умолчанию ''DEPLOY_GROUP''.
Администратор явно включает доверенных людей в эту группу. Journal opt-in даёт
чтение журнала всего хоста; для применения supplementary groups нужен новый login.

В ''.env'' сохранить namespace/BIND своей установки; проверить ''DEBUG=False''
и реальные ''ALLOWED_HOSTS''. Изменение ''.env'' начинает действовать при новом
запуске приложения. Секреты и installation-local файлы в публичный Git не входят.

===== 5. Разовый root bootstrap с repair =====
<code bash>
cd /opt/sharix-open-webapp-base &&
./bin/install.sh bootstrap --strict --use-current-checkouts --permissions=repair
</code>
Этот явный repair нужен после root-owned установки и смены static group при
первом ''NGINX_ENABLED=1''. Он может обойти большое дерево Git/venv/static;
START/DONE/WAIT отражают фазу, второй installer параллельно не запускать.
Обычный ''--permissions=check'' не заменяет эту разовую подготовку.
Сообщение «run root bootstrap» означает полный вызов выше, не команды
''root bootstrap'' или ''bootstrap''.

При отсутствии nginx скрипт спрашивает об установке пакета. Существующий пакет
не переустанавливается. Отказ/ошибка останавливают проход. Missing apt packages
устанавливаются после apt-get update, без полного upgrade ОС. При первом Git
identity предлагаются данные example или собственные; это авторство коммитов,
не Git password и не копирование credentials root. Проверить назначенные роли,
права конфигов/логов, static, health/state и writable outputs.

===== 6. Воссоздать venv и подготовить приложение от deploy =====
Открыть новый login configured deploy user; для имён примера:
<code bash>
su - sharix_open_deploy
</code>
После физического mv старый venv с абсолютными shebang/activation paths не
активировать и не переиспользовать. Для диагностики пути есть штатный
''python3 bin/utils/venv_paths.py --project .''. В новой deploy-сессии:
<code bash>
cd /opt/sharix-open-webapp-base &&
./bin/install.sh deploy --strict --use-current-checkouts \
  --permissions=check --deps=rebuild --no-restart
</code>
Rebuild разрешён только при остановленных main/handlers своего namespace.
Prepared flag не обновляет Git: код уже получен на шаге 1. Deploy всё равно
делает dependency/schema/LDAP/reference/seed/static работу; отвечать на LDAP
prompts по реальной задаче. Это не read-only. Если rebuild уже успешно прошёл,
не повторять его из-за последующей отдельной ошибки; для завершения подготовки
выбирать ''--deps=install'' или ''auto'' по фактическому состоянию.

===== 7. Root activate, затем deploy restart =====
Вернуться в root-сессию после успешного deploy:
<code bash>
cd /opt/sharix-open-webapp-base &&
./bin/install.sh activate --strict --use-current-checkouts --permissions=check
</code>
Фаза материализует systemd и nginx, проверяет runtime identity и точные sudo
grants. Для nginx проверяет синтаксис и фактическое включение сайта, создаёт
ссылки на ''conf-real/nginx/open.conf'', включает boot activation и выполняет
start/reload. Дополнительный ручной ''systemctl enable --now nginx'' после
успешной фазы не требуется. Приложение и handlers запускаются отдельно.

Под deploy:
<code bash>
cd /opt/sharix-open-webapp-base &&
./bin/install.sh restart --strict --use-current-checkouts --permissions=check &&
./bin/check_acceptance.sh --with-runtime-audit
</code>
Restart проверяет явное ''!authenticate'' для точных команд sudo от root,
запускает основной сервис и настроенные handler modes, подтверждает active и
disabled states, а при nginx=1 проверяет прямой backend и локальный HTTP.
''sudo -n -l'' сам по себе не подтверждает беспарольное выполнение.
Отказ restart не требует повторного полного deploy/migrate/seed.

===== 8. Проверить доступность по слоям =====
Под deploy; фактический hostname поставить вместо example:
<code bash>
SX_HOST="service.example.org"
SX_UPSTREAM="$(./venv/bin/python bin/utils/nginx_site.py upstream --root . --value auto)" &&
curl --noproxy '*' -I --max-time 10 -H "Host: $SX_HOST" "$SX_UPSTREAM/" &&
curl --noproxy '*' -I --max-time 10 -H "Host: $SX_HOST" http://127.0.0.1/ &&
curl --noproxy '*' -I --max-time 10 -H "Host: $SX_HOST" \
  http://127.0.0.1/static/sharix_admin/css/base.css
</code>
HTML допускает штатный redirect, CSS должен дать 200 и ''text/css''. Проверить
внешний HTTPS, вход, нужный бизнес-сценарий и functional health XMPP handlers.
В схеме HTTPS proxy → nginx установки → Gunicorn внешний proxy обращается
к доступному адресу nginx установки на HTTP:80, сохраняя Host и корректную
proxy-chain схему. Его TLS/upstream/firewall проверяются отдельно. Backend 200
не доказывает доступность порта 80; внешний 502 не лечится сменой DEBUG.
''NGINX_ENABLED=0'' вообще не материализует локальный nginx.

===== Границы доказательств и история =====
Порядок сверён 2026-10-28 с опубликованным кодом ShariX Open: актуальные ссылки
и SHA приведены в [[sharixopen:knowledge:operations:deploy|основной инструкции]].
Предыдущая source-проверка 2026-10-27 использовала root ''ec9bf2a'' и config
''84597d4''; тогда статья содержала общий checklist без явного relocate-порядка.
Этот исторический срез сохраняется как контекст, а действующая процедура выше
соответствует новым фазам. Успех одного переноса не заменяет приёмку следующего
хоста, внешнего HTTPS и бизнес-сценариев. Это не объявление релиза.
Редакционный ''status=review'' относится к статье, а не к наличию реализации.

~~SHARIX_KNOWLEDGE_RELATED~~