{ "id": "ShariXKnowledgeOpenOperationsDeploy", "page": "sharixopen:knowledge:operations:deploy", "area": "open", "type": "procedure", "title": "Установка и обновление ShariX Open: root, deploy и runtime", "status": "review", "schema_version": 1, "relations": { "related_to": [ "ShariXKnowledgeOpenKnowledgeOperationsRunbook", "ShariXKnowledgeOpenOperationsNginx", "ShariXKnowledgeOpenOperationsInstallationMigration", "ShariXKnowledgeOpenKnowledgeOperationsConfiguration" ] }, "extensions": { "taxonomy": { "domain": "operations", "lifecycle": "implemented", "parents": [ "ShariXKnowledgeOperations" ], "terms": [ "audience_administrator", "audience_operator", "material_howto", "product_sharix_open", "topic_operations_diagnostics", "topic_operations_install" ], "component": "installation" }, "glossary": [], "owner_clarification": { "date": "2026-11-01", "basis": "explicit owner instruction", "scope": "disabled optional modules and immediate subject-documentation updates", "runtime_claim": false }, "classification": { "schema": "sharix.knowledge.classification.v1", "products": [ "sharix_open" ], "audiences": [ "operator", "administrator" ], "material": "howto", "topics": [ "operations/install", "operations/diagnostics" ], "tag_terms": [ "audience_operator", "audience_administrator", "product_sharix_open", "material_howto", "topic_operations_install", "topic_operations_diagnostics" ], "registry_document": "ShariXKnowledgeClassification" }, "acceptance_compatibility": { "date": "2026-11-01", "design_template_sha": "5687c82bc479167d1bd39f7b021e2a4c5404260d", "evidence": "published source and isolated fixtures", "server_runtime_verified": false }, "initial_onboarding_contract": { "agreed_on": "2026-11-01", "basis": "explicit owner correction", "implementation": "published_root_9e77ad2_host_acceptance_incomplete", "previous_prepared_patch": "withdrawn_unapplied", "demo_seed": "mandatory_for_id_0_opt_in_for_positive_id", "onboarding": "recommended_optional", "server_runtime_verified": false, "payment_default_fix": { "prepared_on": "2026-11-02", "patch_sha256": "ca6e6c2bde9351132d8d780e1de786dcfb7e628b8f04dae61fdc63da38d0bb00", "state": "published_root_7003755", "native_alt_runtime_verified": false }, "subscription_lock_fix": { "date": "2026-11-02", "state": "prepared_locally_tested", "payments_base": "8173a87419e9b5ea0dba6f3ec19c08d062c09a59", "patch_sha256": "b9a5cbf7670068f3f5594bb4c2e100b460784317296b0d083d4ed3534c63189c", "database_evidence": "PostgreSQL 17.11, Django 5.2.18, 19 seed scenarios plus two-session category locking", "native_ALT_host_verified": false }, "acceptance_identity_fix": { "date": "2026-11-02", "owner_basis": "SYSTEMD_SERVICE_NAME is configurable; do not require opensharix", "state": "prepared_locally_tested", "root_base": "7003755b8c4dd5fb4e2988e4ee63e2d222e37d2b", "patch_sha256": "2077ca23fbe54c5e38e9055f18a955bffd525ca4fcf7d2ab29579352d1cfbce2", "host_ordinary_install_restart": "passed in owner log", "full_host_acceptance_passed": false } } }, "content_sha256": "266a1cc1f000b2667da4c8212ab1292348b62bda661eed845b904320c7ee78f3", "schema": 1 } ====== Установка и обновление ShariX Open: root, deploy и runtime ====== ===== Установка, Demo-набор и необязательный онбординг: уточнение 01.11.2026 ===== **Согласованное уточнение владельца. Предыдущий подготовленный патч с исключением полного Demo из установки не применён и отозван. Корневой код нового порядка опубликован в 9e77ad2; полная серверная приёмка не завершена. Исправление default payment_method опубликовано в root 7003755; по последнему логу владельца ordinary installation, activate и restart прошли. Оставшийся отказ находится в отдельной acceptance-проверке namespace; дополнительный fix подготовлен, см. уточнения 02.11.2026 ниже.** * При новой установке ShariX Open с ''METASERVICE_ID=0'' полный Demo-набор разворачивается обязательно. Его связи, порядок создания объектов и проверки должны быть валидными с действующими моделями и эксплуатационными defaults. * При положительном ''METASERVICE_ID'' мастер спрашивает, установить ли Demo-набор данных для тестирования. Решение задаёт владелец явно; оно не выводится из наличия модуля Onboarding. При повторе незавершённой установки выбор должен сохраняться, чтобы продолжение не меняло согласованный состав данных. * Для тестовых данных в установке с положительным ID сохраняются её реальный namespace и владелец. Опубликованный seed использует текущий namespace, отдельные технические маркеры и явный выбор тестовых данных; реальный владелец не заменяется Demo-представителем. * Demo seed не должен обнулять ''MIN_*_REQUIREMENTS'', подменять настроенный payment-профиль или обходить обязательные связи, чтобы пройти валидацию. Если значение принадлежит модельному/config default, создание должно использовать этот default. Обязательные связанные объекты создаются в корректном порядке. Условие заполненности nullable-ссылки и назначение технического корневого тикета проверяются по фактическому контракту владельца модели. * Техническая установка должна завершиться до перехода в браузер: службы, конфиги, зависимости, committed migrations, штатные начальные данные, обязательный/выбранный Demo-набор и его проверка, static, запуск и runtime acceptance. Браузерный онбординг не является условием завершения инсталляции. * Модуль ''sharix_onboarding'' рекомендуется для новой установки, но необязателен. Явный отказ/disabled-флаг сохраняется; обычное обновление не включает его самовольно. Если модуль установлен, после завершения инсталляции предлагается браузерная настройка; без него инсталляция также завершается. * Повторный seed должен быть идемпотентным: существующие настройки, пароли, владельцы и пользовательские изменения не заменяются Demo-значениями. Конфликт требует понятного сообщения и решения владельца, а не скрытого сброса. * Блокирующие проверки permissions, миграций, runtime state и source/provenance сохраняются. Локальная проверка кода и прохождение отдельного fixture-теста не означают подтверждённую установку на ALT Linux или успешный браузерный онбординг. Этот раздел заменяет прежнее ошибочное толкование, по которому namespace 0 не требовал полного Demo-каталога. Корневое исправление полного seed опубликовано в [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/9e77ad2102f8f3725ea3886082172c2029a26e2f|9e77ad2]]; успешное завершение конкретного host подтверждается отдельно. Прежний неприменённый patch, исключавший полный Demo, остаётся отозванным. ===== Default payment_method до валидации: исправление 02.11.2026 ===== **Статус:** дефект воспроизведён на root 9e77ad2, исправление опубликовано в [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/7003755b8c4dd5fb4e2988e4ee63e2d222e37d2b|7003755]]. Следующий traceback владельца проходит создание Метасервиса и останавливается позднее в payments; полная host-приёмка ещё не завершена. ''PAYMENT_PROCESSING_MODE'' остаётся источником истины для оплаты. ''Metaservice.payment_method'' — исторический integer snapshot; ''save()'' уже получает его через shared ''get_legacy_payment_method_code()''. Callable default до сохранения ошибочно читал устаревший ''PAYMENT_METHOD''. При отсутствии этого env-параметра новый объект имел NULL, и ''full_clean()'' останавливал seed до ''save()''. Подготовленное исправление меняет общий ''sharix_admin.model_defaults.default_payment_method'': создание использует тот же shared resolver, что сохранение. Никакого отдельного Demo-значения/ветки не добавляется. Не нужно задавать legacy PAYMENT_METHOD, менять configured payment mode, ослаблять NULL-валидацию или разрешать поле в exclude. Путь сериализованного callable сохранён; новой migration нет. Сам default не обновляет существующие строки или конфигурацию. Предыдущая локальная fixture задавала PAYMENT_METHOD=1 и скрывала этот дефект. Новая воспроизводит NULL на старом коде, затем проверяет отсутствие legacy-атрибута и противоречащие старые коды для service/platform/free. После fix прошли 19 изолированных real-model сценариев: полный seed пустой БД и повтор, configured requirements, optional contributions, положительный namespace, operator edits, collision и transaction rollback. Patch из двух root-файлов применён на чистой базе без fuzz. Это SQLite/settings/transport fixture; PostgreSQL/PostGIS, native ALT services/ACL и браузерный вход не проверены локально. Применение: обычный root patch сначала проверяется и публикуется owning repository с основного ShariX Open. CS получает опубликованный root через ''repositories.sh pull --repo .'', затем root повторяет ''./bin/install.sh initial --strict'' с сохранением исправных настроек служб и завершением этапа 2. Не пересоздавать БД/LDAP/venv, не удалять checkpoints и не выполнять Demo reset из-за этой ошибки. Обычные обновления продолжают использовать deploy/restart/acceptance. Shared/optional код этим дополнительным fix не меняется; Platform не получает Open root patch. ===== PostgreSQL и блокировка подписочной категории: 02.11.2026 ===== **Статус:** по следующему traceback владельца воспроизведён ''FOR UPDATE cannot be applied to the nullable side of an outer join''. Дополнительный patch payments подготовлен и локально проверен; Git-публикация и серверная приёмка этого fix ещё не выполнены. ''enable_subscription_category()'' загружает nullable ''subscription_service'' через select_related и одновременно запрашивал блокировку всех таблиц join. Такой SQL PostgreSQL отвергает. Та же ошибка есть в ''disable_subscription_category()'', в том числе когда связь уже заполнена: join остаётся outer по схеме поля. Подготовленный fix явно задаёт ''select_for_update(of=("self",))'' в обеих операциях. Блокируется строка категории, которая сериализует её настройку/привязку; transaction.atomic, проверки доступа и доменные ограничения сохраняются. Не нужно менять isolation level, отключать подписки или обнулять requirements. Это общий payments service для Demo и обычной настройки. Контракт: [[https://docs.djangoproject.com/en/5.2/ref/models/querysets/#select-for-update|Django 5.2]], [[https://www.postgresql.org/docs/17/sql-select.html#SQL-FOR-UPDATE-SHARE|PostgreSQL row locks]]. База payments — [[https://git.sharix-app.org/ShariX_Open/sharix-open-payments/src/commit/8173a87419e9b5ea0dba6f3ec19c08d062c09a59|8173a87]], проверенный root — 7003755. Меняются только service и README payments. После публикации с основного ShariX Open потребители получают общий код через repositories.sh; незавершённая CS initial продолжается с сохранением исправных служб и checkpoints. Shared payments также получает Platform. Миграций, env, переводов и зависимостей в fix нет. Раньше seed проверялся на SQLite, которая это ограничение не выявляет. Для нового fix поднят отдельный локальный PostgreSQL 17.11 с psycopg2 2.9.10 и Django 5.2.18. Старый SQL воспроизвёл именно присланную ошибку. После fix прошли 19 native PostgreSQL вариантов полного core seed и повтора: payment modes, отсутствующий/NULL/устаревший legacy payment input, strict defaults, optional contributions, положительный namespace, operator edits, отключённая подписка, collision и post-audit rollback. Дополнительно проверены обычное включение/изменение цены/повторное включение с сохранением ID, отключение NULL-связи, отказ гостю и настоящий конфликт row lock со второй сессией NOWAIT. После commit та же строка доступна второй сессии. Повторный Demo seed сохранил ручные изменения. Проверка повторена на чистой копии после применения поставляемого patch без fuzz; compileall и diff checks пройдены. Временный PostgreSQL остановлен. Это real-model test schema с обычными auth migrations, изолированными settings/AppConfig и transport; полный migration graph, GIS-запросы/PostGIS, native ALT packages, LDAP/XMPP/systemd/ACL, browser и production assembly startup локально не воспроизведены. Эти границы остаются отдельной host-приёмкой; source/provenance/permissions/runtime guards не ослаблены. ===== Acceptance и настраиваемый SYSTEMD_SERVICE_NAME: 02.11.2026 ===== **Уточнение владельца:** имя сервиса является настраиваемым параметром. Проверки не должны требовать конкретный namespace из примера. Источник — фактический ''SYSTEMD_SERVICE_NAME'' этой установки; ''opensharix'' не является обязательным именем каждого сервера. В новом логе CS ordinary installation, root activate и deploy restart завершились; main и configured handler modes проверены. Nginx отдал HTML/CSS. Один upstream HTTP timeout корректно оставлен advisory WARNING. Далее runtime acceptance прошла до handler-health unittest и остановилась exit=1 без сообщения. Полная установка ещё не объявляется принятой. Следующий по порядку ''runtime_identity_direct_source.sh'' содержал literal ожидания opensharix. Он правильно получал configured start из .env, затем сравнивал с чужим фиксированным именем и молча отказывал. Дефект воспроизведён на изолированной установке start. Также воспроизведены ложные отказы двух соседних synthetic runtime guards при унаследованном shell SYSTEMD_SERVICE_NAME. Подготовленный root patch из пяти файлов переносит direct-source проверку на временные копии текущего helper и собственные конфиги с разными namespace. Live .env не читается/не переписывается этой fixture. В S.4/Stage 19.5 fixtures унаследованный namespace очищается только внутри тестов их собственных установок; production helpers не меняются. Duplicate/invalid/foreign identity и чужие units остаются fail-visible. Wrapper acceptance сохраняет исходный exit code и печатает раздел/строку без командных аргументов/секретных env-значений; Stage 19.2 использует выбранный PYTHON. Локально прошли configurable-name cases, проверка неизменности конфигов, отрицательная проверка с намеренно сломанным resolver, шесть вариантов соседних guards (unset/start/foreign), 54 installer contracts и 16 optional acceptance tests. На чистой базе patch применён без fuzz; целевой guard и wrapper-flow harness повторены. Harness подменяет остальные guards и проверяет orchestration/сохранение exit=17; он не является полной assembled/runtime-приёмкой. После reviewed Git-публикации root на основном ShariX Open CS получает его через repositories.sh pull --repo . и под deploy повторяет только ./bin/check_acceptance.sh --with-runtime-audit. Для изменения проверок не нужны повторные initial/deploy/migrations/seed/restart/activate, перенастройка служб или смена start на opensharix. Shared код/Platform root этим patch не меняются; выключенные optional modules не включаются ради приёмки. Прежний initial checkpoint после ошибки acceptance сам не стал complete. Отдельная команда приёмки его не изменяет; не редактировать и не удалять checkpoint вручную. Это исправление checks не добавляет режим завершения initial. Итоговый host/runtime acceptance и браузерный вход подтверждаются отдельно после получения кода. ~~NOCACHE~~ **Назначение:** [[sharixopen:knowledge:classification:materials|Практическое руководство]]. **Продукт:** [[sharixopen:knowledge:classification:products|ShariX Open]]. **Для кого:** [[sharixopen:knowledge:classification:audiences|Оператор развёртывания, администратор]]. **Темы:** [[sharixopen:knowledge:classification:topics|Эксплуатация: установка и диагностика]]. **Раздел:** [[sharixopen:knowledge:operations:start|Эксплуатация ShariX Open]]. ===== Как выбрать сценарий ===== Руководство автономно: для ShariX 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'' по [[sharixopen:knowledge:operations:configuration|справочнику настроек]]. 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 отдельно запускает или перечитывает включённый nginx после проверки синтаксиса и фактического include сайта. Основное приложение и handlers запускаются следующей фазой restart. Nginx=0 эту интеграцию не выполняет. Затем в новом 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 цикл. См. [[sharixopen:knowledge:operations:runtime_health|диагностику]], [[sharixopen:knowledge:operations:nginx_static|nginx/статику]] и [[sharixopen:knowledge:operations:installation_migration|перенос установки]]. ===== Практические уточнения текущего установщика ===== Для [[sharixopen:knowledge:operations:installation_migration|переноса /root → /opt с nginx]] использовать отдельную пошаговую процедуру: update до mv → остановка namespace → mv всего дерева → relocate preview/apply → bootstrap repair → deploy rebuild без restart → activate → restart. Нельзя сначала загрузить сломанные старые ссылки или исправлять их массовым sed. При первом включении nginx меняется static group. Сообщение «run root bootstrap» означает полный вызов, **под 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 Буквальных команд ''root bootstrap'' или ''bootstrap'' нет. В дальнейшем использовать check, без повторного полного repair. Deploy restart продолжать только после успешного системного этапа. Регистрация и deploy preflight проверяют подробное sudo-правило для точной команды с явным target root и ''Options: !authenticate''. Успех ''sudo -n -l'' показывает разрешение, но не доказывает NOPASSWD: просмотр списка имеет отдельную семантику listpw. Скрипт использует абсолютные пути из регистрации. Пример без выполнения команды, с собственным фактическим namespace: # Заменить example.service сервисом своей установки. LC_ALL=C /usr/bin/sudo -n -ll -u root -- /usr/bin/systemctl restart example.service Неоднозначный ответ или отсутствие явного passwordless-правила останавливают preflight до restart; неудачная регистрация откатывает управляемое правило. Это не расширение sudo-доступа и не доказательство успешного запуска сервиса. ===== Приёмка опциональных модулей ===== Отсутствующий и не включённый модуль получает NOT APPLICABLE. Включённый без исходников и отсутствующее ядро остаются ошибкой. Отключённые опциональные модули исключаются из проверок целиком: исходники, шаблоны, переводы, зависимости и runtime не проверяются и не исправляются. Проверяются активные владельцы и обязательное ядро. Смешанные guards сохраняют проверки ядра. Не устанавливать Appointments/Onboarding/Translations лишь ради зелёного теста. Состав берётся из canonical repository catalogue и local_apps resolver; дополнительный реестр состояния не создаётся. Подробности — root README. ===== Актуальная 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'' относится к статье, не к наличию реализации. ===== Применимость приёмки: уточнение владельца 01.11.2026 ===== Отключённый опциональный модуль находится вне приёмки целиком. Не проверять, не компилировать и не исправлять его исходники, шаблоны, переводы, зависимости или runtime ради прохождения приёмки. Не устанавливать и не включать его для получения зелёного результата. Наличие checkout не делает модуль активным. Активный состав определяется штатным resolver по конфигурации установки. Отключённая или неподключённая опциональная часть получает NOT APPLICABLE. Обязательное ядро, активные модули и ошибки определения состава остаются блокирующими; смешанный guard сохраняет обязательную часть, исключая отключённую опциональную. Это действующее требование владельца и замена прежнего указания проверять исходники и переводы выключенного модуля. Оно не означает, что все подготовленные исправления приёмки уже применены на серверах. Результат конкретной установки подтверждается отдельно. ===== Совместимость shared-инструментов приёмки (01.11.2026) ===== Перед запуском обновлённого корневого wrapper получить все shared-зависимости, от которых зависит его контракт вызова. Для текущей приёмки это dbsynce и design_template: одной передачи dbsynce недостаточно. ./bin/repositories.sh status --repo dbsynce --repo design_template ./bin/repositories.sh pull --shared --repo dbsynce --repo design_template ./venv/bin/python bin/checks/ui_reliability.py Команды исходников выполнять от назначенного deploy login в каталоге своей установки, после проверки чистоты checkout и сохранения исходных SHA. При конфликте, ошибке pull или неподходящей configured branch остановиться; не делать reset и не переключать ветку вручную ради приёмки. Корневой UI wrapper передаёт include_path для исключения отключённых модулей. Совместимый опубликованный design_template — [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-design-template/src/commit/5687c82bc479167d1bd39f7b021e2a4c5404260d/ui_reliability_audit.py|5687c82: ui_reliability_audit.py]]; main(argv) сохраняется, include_path добавлен как необязательный keyword argument. Старый audit вызывает TypeError. Не устранять ошибку удалением фильтра или повторным запуском без него: это возвращает проверку отключённых модулей. При изменении результата resolver обязательно актуализировать все существующие тесты его контракта и после последней правки повторить полный затронутый набор. Для Translations различаются absent (не подключён), disabled (подключён, но выключен) и enabled; первые два состояния не читают исходники опционального модуля. Отсутствующие исходники или guards активного модуля остаются ошибкой. Эта запись подтверждена опубликованным shared-кодом и изолированными fixture-проверками. Исправление двух ожиданий installer-теста подготовлено локально; полный набор из 54 тестов прошёл локально. Применение патча и полная приёмка конкретных серверов подтверждаются отдельно. Эта правка теста и инструмента приёмки не требует миграций или restart; изменение бизнес-кода проходит обычные фазы deploy/restart. ~~SHARIX_KNOWLEDGE_RELATED~~