ShariX Open Docs

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

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

Вы посетили: • execution_configuration • promocodes • roadmap • moodle • platform_profiles • calendar • tickets • moodle_setup • offline_integration • operations
sharixopen:knowledge:operations:start

Содержание

Эксплуатация ShariX Open

Назначение: Указатель раздела. Продукт: ShariX Open.

Для кого: Оператор развёртывания · Администратор · Нейросеть.

Темы: Эксплуатация → Установка · Эксплуатация → Диагностика.

Это указатель эксплуатационных процедур: какую установку проверять, где искать её состояние и какую подробную инструкцию открыть. Команды выполняют в фактическом корне нужной установки под предусмотренным пользователем. Наличие похожего checkout на том же сервере не делает его тем же приложением.

Сначала установить контекст

Перед изменением зафиксировать:

  • фактический каталог установки;
  • её installation identity и настроенные службы;
  • назначенных deploy/runtime пользователей;
  • версии и ветки корневого проекта и затронутых модулей;
  • фактически включённые компоненты;
  • последнее успешное действие и точное сообщение сбоя.

Имена служб берут из действующей конфигурации установки, а не вычисляют из hostname. Секреты и полный env не вставляют в отчёт. Рабочие конфиги и их связи с conf-real проверяют по manifest конфигурации; example не подменяет локальные значения.

Какие команды относятся к какому результату

Для чтения состояния репозиториев из корня установки: 

./bin/repositories.sh status

У вложенных Git-репозиториев собственные ветки и изменения. Чистое состояние корня не подтверждает чистоту всех модулей. Выбор –shared показывает роль репозитория в сборке, а не его лицензию и не разрешение публиковать весь выбранный код.

Задача Что подтверждает нужный этап Где читать подробности
Выяснить требования до установки Наличие поддерживаемой среды и зависимостей по актуальному коду. Требования к установке.
Применить подготовленный исходный код Файлы применены к правильной базе, опубликованы, связанные версии согласованы. Передача патча оператору и Git-порядок.
Подготовить существующую установку Deploy подготовил зависимости, конфигурацию, схему и данные в рамках процедуры. При –no-restart новая версия ещё не запущена. Роли и фазы установки.
Запустить подготовленную версию Отдельный restart проверил права и состояние предусмотренных служб. Порядок перезапуска.
Проверить работу установки Приёмка и runtime audit, затем затронутый пользовательский сценарий. Проверки и их границы.
Найти причину сбоя Состояние нужного процесса, журнал, конфигурация и зависимость, на которой остановилась операция. Runtime health.

Полный установщик не запускают заново ради каждого сбоя. Root bootstrap/activate решают системную подготовку и регистрацию; обычное обновление выполняется фазами deploy и restart. Когда действительно нужна дополнительная системная подготовка, её определяют по конкретной ошибке и действующему runbook.

После предусмотренного обновления

Из фактического корня подготовленной установки под назначенным deploy login: 

./venv/bin/python manage.py check
./bin/check_acceptance.sh --with-runtime-audit

Это проверки, а не команды установки или исправления. manage.py check не подтверждает доставку XMPP, а runtime audit не заменяет воспроизведения изменённого пользовательского действия. Если до проверки нужен restart, сначала выполняют его по процедуре обновления.

Фиксируют отдельно:

  • результат подготовки исходников и deploy;
  • результат restart и проверки служб;
  • результат приёмки;
  • результат конкретного пользовательского действия;
  • предупреждения и то, что проверить не удалось.

Как различать ошибки

  • Permissions или service state: этап останавливается; требуется установить конкретную причину.
  • Source/provenance guard: источник или происхождение кода не подтверждены; нельзя пропускать проверку ради запуска.
  • HTTP-диагностика после restart: рекомендательная; таймаут, сетевой отказ и HTTP-код сохраняются как WARNING и исследуются отдельно. Они не меняют уже установленный результат перезапуска служб и не доказывают доступность сайта.
  • systemd active у handler: подтверждает состояние процесса, но не достаточную функциональную готовность XMPP и обработки заявок.

При Restart permissions are not installed или Runtime state needs its managed isolated directory сверяют штатную процедуру root activate. После необходимой подготовки выполняют новый deploy login и повторяют только restart. Ручной chmod, симлинки, рекурсивный repair и повтор полного deploy не назначают без основания.

Куда перейти по конкретной проблеме

Диагностика должна сохранять рабочую конфигурацию и данные. Свободная память сама по себе не доказывает работоспособность DNS, посредника или внешнего сервиса. При неизвестном исходе записи сначала выясняют сохранённое состояние; повтор не назначают по одному факту таймаута.

Публичная процедура относится к ShariX Open. Внутренние службы и порядок Platform находятся в intrawiki. Общие изменения после публикации передают её ответственному по порядку shared-изменений.

Граф знаний ShariX

Фильтруйте по разделам и выбирайте узлы, чтобы перейти к документам.

Текстовая навигация по документам

Каталог знаний

Исходники, сверенные 31.10.2026

Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение версии, конфигурации или выполнения сценария на сервере.

Связанные материалы

sharixopen/knowledge/operations/start.txt · Последнее изменение: — sx_knowledge_api_open
© 2022 ShariX