Раздел: Эксплуатация ShariX Open. Связанные инструкции: роли и фазы, nginx и статика, локальные настройки.
Это разовая 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 для этой установки.
Под root, пока исходные ссылки ещё работают:
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
В вывод не отправлять полную .env или токены. Проверить изменения и
миграции каждого владельца. Корректные локальные migration files сохранить в
истории соответствующей ветки до обновления; не удалять их ради clean status.
Если конфигурация или код отличаются от upstream, сначала разобраться с diff.
Не делать reset/recovery вслепую и не сливать исторические baselines разных тем.
Для чистого root checkout на master с origin нужного проекта:
git -c core.pager=cat pull --ff-only origin master && ./bin/repositories.sh pull && ./bin/install.sh --help
Если фактическая корневая ветка другая, выбирать её осознанно; пример не
переключает её автоматически. Helper обновляет установленные независимые
checkout по их configured branches. Локальный branding deployment branch
не заменяется основной темой. Требуется актуальный режим relocate в help.
Если обновление остановилось, перенос не продолжать.
Ниже namespace читает штатный helper, без запуска Django и старого venv. Работать в одной root-сессии; новый каталог обязан отсутствовать, включая сломанную ссылку на его месте:
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
Glob заключён в кавычки: instances ищет systemctl. Не останавливать глобальные
handler@* без доказательства владельца. Если сохранились работающие legacy
units этой установки, relocate обнаружит их и остановит план; сначала
проверить принадлежность, затем остановить адресно. Старого дерева после mv нет
и для дальнейших действий оно не требуется.
Запускается из нового пути до bootstrap и загрузки dangling install.cfg:
./bin/install.sh relocate --from=/root/sharix-open-webapp-base
Это preview: проверить namespace, old/new root и перечисленные пути. После успешной проверки плана:
./bin/install.sh relocate --from=/root/sharix-open-webapp-base --apply && ./bin/configure_local_configs.sh --sync-install-cfg
Скрипт проверяет остановку и 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 поверх.
Проверить фактический conf-real/bin/install.cfg. Пример имён для одной
установки; существующие корректные имена сохраняются:
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"
Домены 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 не входят.
cd /opt/sharix-open-webapp-base && ./bin/install.sh bootstrap --strict --use-current-checkouts --permissions=repair
Этот явный 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.
Открыть новый login configured deploy user; для имён примера:
su - sharix_open_deploy
После физического mv старый venv с абсолютными shebang/activation paths не
активировать и не переиспользовать. Для диагностики пути есть штатный
python3 bin/utils/venv_paths.py –project .. В новой deploy-сессии:
cd /opt/sharix-open-webapp-base && ./bin/install.sh deploy --strict --use-current-checkouts \ --permissions=check --deps=rebuild --no-restart
Rebuild разрешён только при остановленных main/handlers своего namespace.
Prepared flag не обновляет Git: код уже получен на шаге 1. Deploy всё равно
делает dependency/schema/LDAP/reference/seed/static работу; отвечать на LDAP
prompts по реальной задаче. Это не read-only. Если rebuild уже успешно прошёл,
не повторять его из-за последующей отдельной ошибки; для завершения подготовки
выбирать –deps=install или auto по фактическому состоянию.
Вернуться в root-сессию после успешного deploy:
cd /opt/sharix-open-webapp-base && ./bin/install.sh activate --strict --use-current-checkouts --permissions=check
Фаза материализует systemd и nginx, проверяет runtime identity и точные sudo
grants. Для nginx проверяет синтаксис и фактическое включение сайта, создаёт
ссылки на conf-real/nginx/open.conf, включает boot activation и выполняет
start/reload. Дополнительный ручной systemctl enable –now nginx после
успешной фазы не требуется. Приложение и handlers запускаются отдельно.
Под deploy:
cd /opt/sharix-open-webapp-base && ./bin/install.sh restart --strict --use-current-checkouts --permissions=check && ./bin/check_acceptance.sh --with-runtime-audit
Restart проверяет явное !authenticate для точных команд sudo от root,
запускает основной сервис и настроенные handler modes, подтверждает active и
disabled states, а при nginx=1 проверяет прямой backend и локальный HTTP.
sudo -n -l сам по себе не подтверждает беспарольное выполнение.
Отказ restart не требует повторного полного deploy/migrate/seed.
Под deploy; фактический hostname поставить вместо example:
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
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 приведены в основной инструкции.
Предыдущая source-проверка 2026-10-27 использовала root ec9bf2a и config
84597d4; тогда статья содержала общий checklist без явного relocate-порядка.
Этот исторический срез сохраняется как контекст, а действующая процедура выше
соответствует новым фазам. Успех одного переноса не заменяет приёмку следующего
хоста, внешнего HTTPS и бизнес-сценариев. Это не объявление релиза.
Редакционный status=review относится к статье, а не к наличию реализации.