Тип: contract · Статус: сведения требуют сверки с действующей установкой; архитектурные правила сформулированы как целевой контракт.

Раздел: Эксплуатация ShariX Open и наблюдаемость

.env.example описывает имена настроек без секретов. Реальная .env принадлежит экземпляру установки и не копируется в публикационные комплекты.

После правки примера выполняется нормализация окружения штатным инструментом и проверка различий. Подключение каждого модуля и интеграции осуществляется по отдельному контракту с безопасными значениями по умолчанию.

Установка может предоставлять настраиваемые человекочитаемые термины, но не переименовывает идентификаторы моделей и API. Контентные переводы и локализация статического UI также имеют разные источники.

• Терминология, локализация и понятный интерфейс
• Профили подключения к Platform и demo boundary

bin/install.cfg ссылается на conf-real/bin/install.cfg. conf хранит примеры/генераторы, conf-real — реальные данные и локальную историю; root ignore не отменяет самостоятельный repository. Не публиковать secrets. Основные defaults в example (существующее локальное значение не заменяется):

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=0

Пустой home означает /home/$DEPLOY_USER; пустая operators group — DEPLOY_GROUP. Первое — персональный home login/Git/tools, не root приложения; второе — Unix группа доверенных операторов, не путь. Namespace задаёт SYSTEMD_SERVICE_NAME корневого env, существующее имя сохраняется. DEPLOY_JOURNAL_ACCESS=1 даёт чтение журналов всего хоста; значение 0 не отзывает ранее выданное членство. Deploy — доверенный владелец исходников и конфигов. Это эксплуатационное разделение, не защита от злонамеренного deploy, редактирующего потребляемый root config.

В начале физического root/module/handler env, до первого assignment:

# @env.file.web: read

Локальный заголовок важнее example. Если обоих нет — read; root example явно write для первого запуска. Повторный/невалидный заголовок блокирует installer, web writer скрывает файл. Из веба заголовок не меняется. Политика не выдаёт Django/LDAP роль и не расширяет owner allowlist, secret widgets/file-only keys. Hidden не означает «runtime не может прочитать настройки».

Физически: conf-real/env/root/.env, conf-real/env/<module>/.env, conf-real/env/handlers/.env. Рабочие .env и исторические адреса остаются совместимыми ссылками; conf/env/<owner> зеркалит структуру ссылками на actual data/example владельца, а не копирует secrets в Git. Миграция сохраняет байты, backups и конфликтную историю; разные physical copies/foreign symlink не затираются. Canonical env читается первым, runtime не обязан обходить старый закрытый каталог.

First-run/menu/handler selection/source/repository snapshots размещаются в изолированных conf-real/state/<owner>/ с совместимыми адресами. Runtime не получает write ко всему conf-real, systemd, nginx, sudoers или deploy home. Config read, mutable state, media/themes/local_versions, static и logs — разные классы путей. Atomic writers ставят нужные ACL до replace. Backups env: conf-real/backups/env/<owner>/<timestamp>/.env. Не делать chmod 600 после writer: он срежет named runtime ACL mask. Внешние group mode bits — это ACL mask, не полный ответ о фактических правах; проверять getfacl и actual runtime identity.

После смены заголовка из deploy login:

cd /opt/sharix-open-webapp-base &&
./bin/install.sh deploy --strict --use-current-checkouts \
  --permissions=check --deps=check --no-restart

Это обычный deploy, не config-only и не read-only. Он согласует bounded ACL до/после записи; write → read/hidden отзывает запись, не переписывая значения шаблоном. Если новая схема ещё не подготовлена, сначала пройти root bootstrap/activate из основного руководства. Не давать всему conf-real рекурсивный runtime write.

Суперпользователь может посмотреть конкретный обратимо сохранённый секрет конфигурации только после повторного ввода пароля своей учётной записи. При открытии страницы секретные поля пусты; пустой ввод при сохранении не стирает установленное значение. После успешной проверки пароль не хранится в сессии, а значение показывается только в ответе на текущий POST, без кэширования. Необратимые пароли пользователей и значения из .env.example этим способом не раскрываются. Чтение должно уважать режим доступа installation-local файла; неуспешные попытки ограничиваются по частоте. Подготовлен патч для ShariX Open; применение и проверка на сервере пока не подтверждены.

maybe obsolete — ключ не найден в example, а не приказ удалить значение. Generated enable flags могут быть действующими. normalize_env.py –check и module_env_layout.py –root . –check выявляют разные классы расхождений; –write не предлагает интерактивный выбор каждого unknown key. Writer запускать через installer role context, чтобы сохранить owner/ACL/backup contract. Не заменять env файлом example и не переносить вручную чужие токены.

Tracked example содержит универсальные defaults, не домены конкретного сервера. Рабочий bin/install.cfg должен ссылаться на conf-real/bin/install.cfg. Shell синхронизация и добавление недостающих параметров через Sysadmin учитывают обычные KEY=value и существующие export KEY=value. Уже объявленный ключ, в том числе пустой или закомментированный, не заполняется заново из example. Отсутствие завершающего newline не делает последнюю строку отсутствующей. CLI перечисляет имена добавленных параметров без значений.

Это не разрешение выполнять произвольный shell из web editor: его строгая валидация остаётся прежней. Если дубли уже существуют, автоматика не определяет, какая строка была пользовательским выбором. Сначала сравнить приватный backup, затем сохранить одно активное назначение нужного ключа, не восстанавливая весь устаревший cfg поверх актуальных Git URLs/branches.

Примерные nginx-домены или имя site config добавляются только при отсутствии ключа. Изменение default в Git не меняет ранее заданный local upstream. Для обычного TCP BIND выбрать NGINX_UPSTREAM=«auto» осознанно; он вычислит адрес из BIND своей установки. NGINX_ENABLED=0 не включает локальный nginx. При смене 0 → 1 требуется разовый root bootstrap –permissions=repair и root activate; полные команды находятся в nginx runbook.

Быстрая проверка только несекретных ключей, включая export и дубли:

grep -nE '^[[:space:]]*(export[[:space:]]+)?NGINX_(ENABLED|SERVER_NAMES|UPSTREAM|SITE_CONFIG_PATH)[[:space:]]*=' \
  conf-real/bin/install.cfg

Не публиковать весь install.cfg/.env в чат или Wiki. При переносе использовать relocate после mv, сохранив SYSTEMD_SERVICE_NAME/BIND и все independent repositories.

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