Инструменты пользователя

Инструменты сайта


sharixopen:knowledge:operations:installation_migration

Различия

Показаны различия между двумя версиями страницы.

Ссылка на это сравнение

sharixopen:knowledge:operations:installation_migration [2026/10/27 08:03] – [sharixknowledge] approved package sx_knowledge_api_opensharixopen:knowledge:operations:installation_migration [2026/10/28 15:00] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
Строка 5: Строка 5:
     "area": "open",     "area": "open",
     "type": "procedure",     "type": "procedure",
-    "title": "Open: перенос установки и разовая настройка пользователей",+    "title": "ShariX Open: перенос из /root в /opt и переход на nginx",
     "status": "review",     "status": "review",
     "schema_version": 1,     "schema_version": 1,
Строка 26: Строка 26:
         "glossary": []         "glossary": []
     },     },
-    "content_sha256": "16399939168b12265c838db78e358d8c840abbc91a5da2158801d076c8901612",+    "content_sha256": "b36caee30e1bb8f1fc2087b08cccb2f0f86b62429d981b24956ba1b10c3eb716",
     "schema": 1     "schema": 1
 } }
 </sharix-knowledge-meta> </sharix-knowledge-meta>
-====== Open: перенос установки и разовая настройка пользователей ======+====== ShariX Open: перенос из /root в /opt и переход на nginx ======
 ~~NOCACHE~~ ~~NOCACHE~~
  
-**Раздел:** [[sharixopen:knowledge:operations:start|Эксплуатация Open]].+**Раздел:** [[sharixopen:knowledge:operations:start|Эксплуатация ShariX Open]]. 
 +Связанные инструкции: [[sharixopen:knowledge:operations:deploy|роли и фазы]], 
 +[[sharixopen:knowledge:operations:nginx_static|nginx и статика]], 
 +[[sharixopen:knowledge:operations:configuration|локальные настройки]].
  
-===== Это maintenance, не обычное обновление ===== +===== Область сценария ===== 
-Сначала backup БД, media, реальных конфигов и независимых Git repositories; +Это разовая maintenance-процедура существующей установки ShariX Open. Она 
-зафиксировать namespace/порты. Остановить только main и handlers переносимой +перемещает всё дерево из ''/root/sharix-open-webapp-base'' в 
-установки. Production/соседний сервис не трогать. Ни systemctl status, ни наличие +''/opt/sharix-open-webapp-base'', исправляет принадлежащие ему ссылки, переводит 
-venv не заменяет backup и проверку отсутствия незаписанных изменений.+работу на deploy/runtime и включает необязательный локальный nginx. 
 +Другой путь допустим; в командах нужно последовательно использовать его. 
 +Пример не задаёт hostname, namespace, BIND или роли по имени каталога.
  
-Дерево допускается в /opt или другом доступном месте, но не под закрытым /root +Подтвердить наличие актуального штатного backup БД, media и конфигурации; 
-для непривилегированного runtime/nginx. После mv старого дерева может уже не быть: +уже сделанную пригодную копию БД не требуется повторять из-за самого ''mv''. 
-не строить инструкцию на обязательном наличии обеих копий. +Назначить окно остановки. Соседние установки и production этим сценарием не 
-''conf'' и ''conf-real'' — самостоятельные repositories с собственным содержимым; +останавливаются. ''conf'', ''conf-real'', ''webservice_running'' и другие 
-родительский ignore не означает, что их можно удалить. ''webservice_running'' +independent nested Git repositories перемещаются целиком, даже если родитель 
-также содержит код, не только runtime links. Общий handler runtime — +показывает их как ignored. Они содержат код и настройки, а не только ссылки. 
-''handlers_backend'', вкладчики/готовые обработчики — соответствующие modules.+Общий runtime обработчиков принадлежит ''handlers_backend''; не создавать 
 +отдельный runtime для этой установки.
  
-===== Что проверить после перемещения ===== +===== 1. Проверить и обновить код до переноса ===== 
-  - Рабочие symlinks .env, bin/install.cfg, module/handler config и state должны вести в новое дерево; старые абсолютные ссылки чинить адресно. +Под root, пока исходные ссылки ещё работают: 
-  - Новые canonical env находятся в conf-real/env/<owner>/.env; конфликт разных старых/новых физических файлов — остановка и ручное решение, не copy поверх. +<code bash> 
-  - Systemd WorkingDirectory/ExecStart и namespaced handler template должны принадлежать новому фактическому root при прежнем SYSTEMD_SERVICE_NAME. +cd /root/sharix-open-webapp-base 
-  - Старый namespace не переименовывать для обхода ownership error. Чужой active unit не присваивать. Исторические backups не редактировать как active config. +pwd 
-  - Venv после mv проверить штатным venv_paths.py; если непереносим, использовать явный rebuild при доказанно остановленных main/handlers своего namespace. +git status --short --branch 
-  - Nginx alias/upstream, logging path, доступы Unix identities и пути включаемых файлов проверить отдельно.+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 разных тем.
  
-Не делать массовую замену строк во всём проекте: документация/история/backups +Для чистого root checkout на ''master'' с origin нужного проекта: 
-могут законно содержать старый root. Не удалять migration history/backup ради +<code bash> 
-зелёной проверки. Конфликт active legacy/namespaced unit требует compare/backup +git -c core.pager=cat pull --ff-only origin master && 
-и выбора актуального active owner, автоматическое слияние конфигов запрещено.+./bin/repositories.sh pull && 
 +./bin/install.sh --help 
 +</code> 
 +Если фактическая корневая ветка другая, выбирать её осознанно; пример не 
 +переключает её автоматически. Helper обновляет установленные независимые 
 +checkout по их configured branches. Локальный branding deployment branch 
 +не заменяется основной темой. Требуется актуальный режим ''relocate'' в help. 
 +Если обновление остановилось, перенос не продолжать.
  
-===== Порядок восстановления ===== +===== 2. Остановить только эту установку и выполнить mv ===== 
-Использовать ровно [[sharixopen:knowledge:operations:deploy|основной порядок]]: +Ниже namespace читает штатный helper, без запуска Django и старого venv. 
-sync-install-cfg → root bootstrap --permissions=repair → новая deploy session → +Работать в одной root-сессии; новый каталог обязан отсутствовать, включая 
-публикация согласованных owner changes → deploy --no-restart (при необходимости +сломанную ссылку на его месте: 
---deps=rebuild) → root activate → deploy restart → функциональная приёмка. +<code bash> 
-Рутинный installer не нужно повторять ради отдельного restart/ACL failure. +cd /root/sharix-open-webapp-base && 
-Изменения installation-local настроек и secrets не отправлять в публичный Git.+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 ===== 
-Deploy имеет home, Bash, понятный prompt с текущим путём и sbin в PATH. +Запускается из нового пути **до** bootstrap и загрузки dangling install.cfg: 
-Runtime — отдельный locked account с /nonexistent и Bash без создаваемого home. +<code bash> 
-Операторы явно включаются администратором в DEPLOY_OPERATORS_GROUP, а не получают +./bin/install.sh relocate --from=/root/sharix-open-webapp-base 
-полномочия автоматически из факта наличия персонального SSH login. +</code> 
-Пустой DEPLOY_HOME означает /home/$DEPLOY_USER; не задавать /opt или root проекта. +Это preview: проверить namespace, old/new root и перечисленные пути. После 
-Пустой DEPLOY_OPERATORS_GROUP означает DEPLOY_GROUP; это имя группы, не каталог. +успешной проверки плана: 
-Новый login обязателен после изменения supplementary groups.+<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, 
-Сверено 2026-10-27 по опубликованному Open root +домены, пароли, Git URLs/branches, не восстанавливает venv, не делает migrations, 
-[[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/ec9bf2a29a460d4a05025415398b133e09fa1d79/README.md|ec9bf2a]] +не запускает сервисы и не обновляет код. Исторические backup/migration-legacy 
-и Open config +могут законно содержать старый root. Массовый sed по всему дереву запрещён. 
-[[https://git.sharix-app.org/ShariX_Open/sharix-open-config/src/84597d42b01d5a8c84c3a8c16add77435c62c254/README.md|84597d4]]. +Конфликт старых/новых физических env или active legacy/namespaced units 
-Проверены исполняемые пути install.sh, install_roles.sh, install_permissions.py, +требует сравнения и явного решения, а не копирования example поверх. 
-deploy_control.sh, install_nginx.sh и env/state helpers; не только сообщения Git. + 
-Владелец подтвердил успешный запуск Open после исправлений. Установка nginx +===== 4. Настроить роли и nginx ===== 
-с новым вопросом и повторная независимая проверка Testopen ещё требуют +Проверить фактический ''conf-real/bin/install.cfg''. Пример имён для одной 
-отдельной host-приёмки. Это не объявление релиза и не подтверждение production. +установки; существующие корректные имена сохраняются: 
-Редакционный ''status=review'' относится к статье, не к наличию реализации.+<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~~ ~~SHARIX_KNOWLEDGE_RELATED~~
  
sharixopen/knowledge/operations/installation_migration.1793088196.txt.gz · Последнее изменение: — sx_knowledge_api_open

© 2022 ShariX