Страница помогает человеку подготовить установку и понять границы ответственности. Она описывает категории требований и согласованные пожелания к удобству. Точные версии, пакеты и включённые зависимости определяются актуальным кодом выбранной сборки. Эта страница не заменяет фазовую процедуру установки и не утверждает, что любой сервер уже готов.

Не поддерживать здесь вторую копию длинного списка пакетов: она быстро расходится с исходниками. Наличие библиотеки в Git или пакета в ОС не доказывает, что её использует нужный venv и runtime. Актуальные значения секретов не являются частью документации.

• Какой продукт и версия устанавливаются; точные ОС/дистрибутив, архитектура и фактический каталог.
• Новая ли это среда или обновление с существующими данными; где резервная копия и кто отвечает за восстановление.
• Какие Unix identities используются для личного входа, deploy и runtime; кто имеет необходимые системные полномочия.
• Какие БД и внешние службы уже подготовлены, где они размещены и кто выдаёт параметры подключения.
• Какие модули включаются; нужны ли для них LDAP, XMPP, хранилища, почта или другие интеграции.
• Доменные имена, bind/порт, статические файлы и внешний HTTPS; кто отвечает за сетевую часть.

Ресурсы сервера выбираются по составу модулей, данным, фоновым задачам и нагрузке. Универсальные численные минимумы без измерений не задаются. Возможность открыть терминал и доступность Git не подтверждают готовность этих зависимостей.

Установщик приложения может ожидать подготовленные БД и каталог пользователей. Установка LDAP-клиентских инструментов не создаёт LDAP-сервер и структуру каталога. Получение параметров БД не означает, что уже созданы нужная база, учётная запись и разрешения. Область автоматической подготовки определяется текущими фазами и выбранными опциями, а не ожиданием «всё с нуля».

При отсутствии необходимых сведений сохранить последний успешный шаг и запросить конкретные параметры у ответственного. Не придумывать адреса/имена служб, не пробовать чужие доступы и не выполнять серию случайных команд. Неудавшееся прохождение планёрки — источник вопросов к удобству, не подтверждённый успешный runbook.

Это согласованные направления развития удобства, а не перечень уже реализованных возможностей.

• Сначала объяснить предполагаемое исходное состояние и различие новой установки и обновления.
• Для каждого параметра показать назначение, источник и безопасный пример. Сгенерировать допустимое случайное значение там, где это уместно; адрес чужой службы и полномочия генерацией не заменяются.
• Использовать уже введённые значения в следующих шагах, не заставляя переносить их повторно вручную. Явно показать, куда значение сохраняется и кем используется, не выводя секрет в отчёт.
• Различать личный вход, deploy и runtime; рядом с действием указывать, от чьего имени оно выполняется.
• Объяснять последствия выбора, включая диагностический режим и сетевую доступность. DEBUG=True не является способом исправления production-статики.
• Перед записью показывать существенные изменения; сохранять существующие локальные значения, обозначать требуемые согласования и ожидаемые остановки.
• После сбоя сообщать, что подтверждено и как продолжить с нужной фазы. Не предлагать полный повтор установки вместо адресной диагностики.

Проверить сценарий с заявленным исходным состоянием на предназначенной тестовой среде. Убедиться, что введённые значения доходят до нужной конфигурации, отсутствующая зависимость объясняется, локальные значения сохраняются и путь можно продолжить после остановки. Различать подготовку исходников, системную регистрацию, запуск и пользовательский результат.

Фактические команды и полномочия — в процедуре установки, локальные значения — в конфигурации, статика — в nginx/статика, основания проверки — в критериях приёмки.

Сверены опубликованные исходники. Это анализ кода, а не подтверждение успешной установки на конкретном сервере.

• sharix-open-webapp-base: requirements.txt.
• sharix-open-webapp-base: constraints.txt.
• sharix-open-webapp-base: bin/install.sh.
• sharix-open-webapp-base: bin/install_system_dependencies.sh.
• sharix-open-webapp-base: bin/utils/assembly_requirements.sh.
• sharix-open-webapp-base: bin/check_acceptance.sh.