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

Сначала backup БД, media, реальных конфигов и независимых Git repositories; зафиксировать namespace/порты. Остановить только main и handlers переносимой установки. Production/соседний сервис не трогать. Ни systemctl status, ни наличие venv не заменяет backup и проверку отсутствия незаписанных изменений.

Дерево допускается в /opt или другом доступном месте, но не под закрытым /root для непривилегированного runtime/nginx. После mv старого дерева может уже не быть: не строить инструкцию на обязательном наличии обеих копий. conf и conf-real — самостоятельные repositories с собственным содержимым; родительский ignore не означает, что их можно удалить. webservice_running также содержит код, не только runtime links. Общий handler runtime — handlers_backend, вкладчики/готовые обработчики — соответствующие modules.

1. Рабочие symlinks .env, bin/install.cfg, module/handler config и state должны вести в новое дерево; старые абсолютные ссылки чинить адресно.
2. Новые canonical env находятся в conf-real/env/<owner>/.env; конфликт разных старых/новых физических файлов — остановка и ручное решение, не copy поверх.
3. Systemd WorkingDirectory/ExecStart и namespaced handler template должны принадлежать новому фактическому root при прежнем SYSTEMD_SERVICE_NAME.
4. Старый namespace не переименовывать для обхода ownership error. Чужой active unit не присваивать. Исторические backups не редактировать как active config.
5. Venv после mv проверить штатным venv_paths.py; если непереносим, использовать явный rebuild при доказанно остановленных main/handlers своего namespace.
6. Nginx alias/upstream, logging path, доступы Unix identities и пути включаемых файлов проверить отдельно.

Не делать массовую замену строк во всём проекте: документация/история/backups могут законно содержать старый root. Не удалять migration history/backup ради зелёной проверки. Конфликт active legacy/namespaced unit требует compare/backup и выбора актуального active owner, автоматическое слияние конфигов запрещено.

Использовать ровно основной порядок: sync-install-cfg → root bootstrap –permissions=repair → новая deploy session → публикация согласованных owner changes → deploy –no-restart (при необходимости –deps=rebuild) → root activate → deploy restart → функциональная приёмка. Рутинный installer не нужно повторять ради отдельного restart/ACL failure. Изменения installation-local настроек и secrets не отправлять в публичный Git.

Deploy имеет home, Bash, понятный prompt с текущим путём и sbin в PATH. Runtime — отдельный locked account с /nonexistent и Bash без создаваемого home. Операторы явно включаются администратором в DEPLOY_OPERATORS_GROUP, а не получают полномочия автоматически из факта наличия персонального SSH login. Пустой DEPLOY_HOME означает /home/$DEPLOY_USER; не задавать /opt или root проекта. Пустой DEPLOY_OPERATORS_GROUP означает DEPLOY_GROUP; это имя группы, не каталог. Новый login обязателен после изменения supplementary groups.

Сверено 2026-10-27 по опубликованному Open root ec9bf2a и Open config 84597d4. Проверены исполняемые пути install.sh, install_roles.sh, install_permissions.py, deploy_control.sh, install_nginx.sh и env/state helpers; не только сообщения Git. Владелец подтвердил успешный запуск Open после исправлений. Установка nginx с новым вопросом и повторная независимая проверка Testopen ещё требуют отдельной host-приёмки. Это не объявление релиза и не подтверждение production. Редакционный status=review относится к статье, не к наличию реализации.