Раздел: Эксплуатация ShariX Open.

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

Сделать штатный 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 и останавливается для его заполнения — это ожидаемо, не окончание установки.

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.

Применённую разработку сначала проверить и опубликовать во всех 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.

После успешной подготовки 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.

После 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/статику и перенос установки.

Для переноса /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 routes/PageHelp применяются к активным владельцам. Смешанные guards сохраняют проверки ядра. Не устанавливать Appointments/Onboarding/Translations лишь ради зелёного теста. Состав берётся из canonical repository catalogue и local_apps resolver; дополнительный реестр состояния не создаётся. Подробности — root README.

Порядок сверён с опубликованным ShariX Open root 4e1fe4c: install.sh, relocate, nginx lifecycle, проверка sudo, сохранение install.cfg и config 84597d4. Проверены тела функций и порядок вызовов, а не только help или сообщения коммитов. Обычные команды не меняют release tags. Код реализован; результат конкретного хоста подтверждают отдельно по runtime, HTTP/XMPP и пользовательскому сценарию. Наличие source-check или status=review не является приёмкой произвольной установки или внешнего HTTPS.

Сверено 2026-10-27 по опубликованному ShariX Open root ec9bf2a и ShariX Open config 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 относится к статье, не к наличию реализации.